date:20150205

On 02/05/2015 07:01 AM, Alexandre Levine wrote:
 Davanum,
 
 We've added the devstack support. It's in our stackforge repository.
 https://github.com/stackforge/ec2-api/tree/master/contrib/devstack
 
 Best regards,
   Alex Levine

I've converted it to a devstack external plugin structure in this review
- https://review.openstack.org/#/c/153206/

so that will make using this as simple as

enable_plugin ec2-api https://github.com/stackforge/ec2-api

Once that merges.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0043] glibc 'GHOST' vulnerability can allow remote code execution

2015-02-05 Thread Nathan Kinder

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

glibc 'GHOST' vulnerability can allow remote code execution
- ---

### Summary ###
A serious vulnerability in the GNU C library (glibc) gethostbyname*
functions can allow an attacker to perform remote code execution with
the privileges of the application that calls the gethostbyname*
function. The vulnerable functions are used by a vast number of
programs, effectively any time a network socket is used in a linux
system, so the full exploitability of this vulnerability will not
become known immediately.

The publishers of this vulnerability, Qualys, have announced a proof of
concept exploit for the Exim mail server, which bypasses operating
system protections such as ASLR and DEP.


### Affected Services / Software ###
All versions running on Linux installations with a vulnerable glibc
library.

### Discussion ###
The GNU C library (glibc), from versions 2.2 to 2.17 inclusive, has
a group of vulnerable functions for hostname/address resolution. There
is a buffer overflow in the __nss_hostname_digits_dots() function which
is used by the gethostbyname*() group of functions. The maximum amount
of memory that can be overwritten is sizeof(char *), i.e. 4 bytes on
typical 32-bit systems and 8 bytes on typical 64-bit systems.

These low-level functions are linked by many other C/C++ programs and
interpreted languages like Python, Perl and Bash, so this vulnerability
is insidious and will appear in cases where it would not at first seem
obvious. There are many cases in a typical Linux installation where
these functions will be used, generally wherever a hostname is resolved
to an IP address, although in newer applications an IPv6 compatible
function, getaddinfo() may be used instead.

This vulnerability could let an attacker remotely execute code in cases
where they control the input to a function that performs hostname
resolution. There are no currently-known OpenStack-specific
exploitation paths associated with this vulnerability. However, the
Python socket library presents a gethostbyname() wrapper around the
glibc function, and there are various ways in which this could be
exposed.

### Recommended Actions ###
The glibc library is loaded into memory when a process that uses it
starts up, so to fix the vulnerability, glibc should be updated to a
non-vulnerable version (2.18 or newer) and all services which use glibc
should be restarted to replace the version in memory. Due to the number
of places where these vulnerable functions are used, this effectively
means that vulnerable systems must be restarted after updating glibc.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0043
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1415416
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2015-0235
Source advisory:
https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU02eRAAoJEJa+6E7Ri+EVXu8IAIDuL3LbQKtSvLiyleAqF3nd
WUTiqdAIRc6cf7xJdMyVm8W0ISOE88YpscSeT55xbiaPVL7joro0vVP7CLhFg5E3
wRzT9W+abAj62EFU7SOjLGiKEWbIHa+Aa3W+r/bPXCJACP3V1XCEnZya+g6GuXT7
JbV9EYYeprAGWQNvSEA8g49YYq44aIxuGqDd6ti6pye3wTgf5e0emGP1BIS/i3TI
htQfp4F+zGtRukjWdg3HVoLOKtZYqLHEJT0EUEcq4hzTFKEFhk6x93zYIrRhil+d
+Jm70OeeKosS64Ebe+06sc2g1jTVNryvozxl95MYR09axkfgd2myjxDZMB5Ak+o=
=NlVl
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Attila Fazekas

- Original Message -
 From: Matthew Booth mbo...@redhat.com
 To: openstack-dev@lists.openstack.org
 Sent: Thursday, February 5, 2015 12:32:33 PM
 Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody 
 should know about Galera

 On 05/02/15 11:01, Attila Fazekas wrote:
  I have a question related to deadlock handling as well.

  Why the DBDeadlock exception is not caught generally for all api/rpc
  request ?

  The mysql recommendation regarding to Deadlocks [1]:
  Normally, you must write your applications so that they are always
   prepared to re-issue a transaction if it gets rolled back because of a
   deadlock.

 This is evil imho, although it may well be pragmatic. A deadlock (a real
 deadlock, that is) occurs because of a preventable bug in code. It
 occurs because 2 transactions have attempted to take multiple locks in a
 different order. Getting this right is hard, but it is achievable. The
 solution to real deadlocks is to fix the bugs.

 Galera 'deadlocks' on the other hand are not deadlocks, despite being
 reported as such (sounds as though this is due to an implementation
 quirk?). They don't involve 2 transactions holding mutual locks, and
 there is never any doubt about how to proceed. They involve 2
 transactions holding the same lock, and 1 of them committed first. In a
 real deadlock they wouldn't get as far as commit. This isn't any kind of
 bug: it's normal behaviour in this environment and you just have to
 handle it.

  Now the services are just handling the DBDeadlock in several places.
  We have some logstash hits for other places even without galera.

 I haven't had much success with logstash. Could you post a query which
 would return these? This would be extremely interesting.

Just use this:
message: DBDeadlock

If you would like to exclude the lock wait timeout ones:
message: Deadlock found when trying to get lock

  Instead of throwing 503 to the end user, the request could be repeated
  `silently`.

  The users would be able repeat the request himself,
  so the automated repeat should not cause unexpected new problem.

 Good point: we could argue 'no worse than now', even if it's buggy.

  The retry limit might be configurable, the exception needs to be watched
  before
  anything sent to the db on behalf of the transaction or request.

  Considering all request handler as potential deadlock thrower seams much
  easier than,
  deciding case by case.

 Well this happens at the transaction level, and we don't quite have a
 1:1 request:transaction relationship. We're moving towards it, but
 potentially long running requests will always have to use multiple
 transactions.

 However, I take your point. I think retry on transaction failure is
 something which would benefit from standard handling in a library.

 Matt
 --
 Matthew Booth
 Red Hat Engineering, Virtualisation Team

 Phone: +442070094448 (UK)
 GPG ID:  D33C3490
 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack Foundation] Finding people to work on the EC2 API in Nova

2015-02-05 Thread Jeremy Stanley

On 2015-02-02 14:45:53 +0300 (+0300), Alexandre Levine wrote:
 On 2/2/15 12:58 PM, Daniel P. Berrange wrote:
[...]
  We need to at least discuss  iterate on this a few times
  online, so that we can take advantage of the f2f time for any
  remaining harder parts of the discussion.
[...]
 how do you usually do those online discussions? I mean what is the
 tooling?

You're doing it right now.

But also, comments on review.openstack.org for your proposed spec,
ad hoc discussions in appropriate IRC channels[1] and possibly more
officially in weekly IRC meetings[2].

[1] https://wiki.openstack.org/wiki/IRC
[2] https://wiki.openstack.org/wiki/Meetings
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Murano] Translation usage suggestion

2015-02-05 Thread Ekaterina Chernova

Hi all!

Recently we have discussed the log and exception translations and have not
come to a decision.

I've made some research and found a useful documents:


   - https://wiki.openstack.org/wiki/LoggingStandards#Log_Translation
   - https://wiki.openstack.org/wiki/Translations


Here two main points, that I can highlight

* *Exception text should **not** be marked for translation,*
because if an exception occurs there is no guarantee that the
translation machinery will be functional.

** Debug level log messages are not translated*

Some projects do not follow these rules, but I suggest to take them into
consideration and perform the following actions:

   - First of all, we should remove gettext utils usage and replace it with
   oslo.i18n;
   - Remove exception messages translation;
   - Add log translation to info, warn and error log level (and
   log.exception which creates log.error message).

Note, that different log levels can be separated to different files. It's
also supported to have different log files for different languages.

What do you think?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

On 04/02/15 19:04, Jay Pipes wrote:
 On 02/04/2015 12:05 PM, Sahid Orentino Ferdjaoui wrote:
 On Wed, Feb 04, 2015 at 04:30:32PM +, Matthew Booth wrote:
 I've spent a few hours today reading about Galera, a clustering solution
 for MySQL. Galera provides multi-master 'virtually synchronous'
 replication between multiple mysql nodes. i.e. I can create a cluster of
 3 mysql dbs and read and write from any of them with certain consistency
 guarantees.

 I am no expert[1], but this is a TL;DR of a couple of things which I
 didn't know, but feel I should have done. The semantics are important to
 application design, which is why we should all be aware of them.


 * Commit will fail if there is a replication conflict

 foo is a table with a single field, which is its primary key.

 A: start transaction;
 B: start transaction;
 A: insert into foo values(1);
 B: insert into foo values(1); -- 'regular' DB would block here, and
report an error on A's commit
 A: commit; -- success
 B: commit; -- KABOOM

 Confusingly, Galera will report a 'deadlock' to node B, despite this not
 being a deadlock by any definition I'm familiar with.
 
 It is a failure to certify the writeset, which bubbles up as an InnoDB
 deadlock error. See my article here:
 
 http://www.joinfu.com/2015/01/understanding-reservations-concurrency-locking-in-nova/
 
 
 Which explains this.
 
 Yes ! and if I can add more information and I hope I do not make
 mistake I think it's a know issue which comes from MySQL, that is why
 we have a decorator to do a retry and so handle this case here:

   
 http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n177

 
 It's not an issue with MySQL. It's an issue with any database code that
 is highly contentious.
 
 Almost all highly distributed or concurrent applications need to handle
 deadlock issues, and the most common way to handle deadlock issues on
 database records is using a retry technique. There's nothing new about
 that with Galera.
 
 The issue with our use of the @_retry_on_deadlock decorator is *not*
 that the retry decorator is not needed, but rather it is used too
 frequently. The compare-and-swap technique I describe in the article
 above dramatically* reduces the number of deadlocks that occur (and need
 to be handled by the @_retry_on_deadlock decorator) and dramatically
 reduces the contention over critical database sections.

I'm still confused as to how this code got there, though. We shouldn't
be hitting Galera lock contention (reported as deadlocks) if we're using
a single master, which I thought we were. Does this mean either:

A. There are deployments using multi-master?
B. These are really deadlocks?

If A, is this something we need to continue to support?

Thanks,

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

2015-02-05 Thread Ioram Schechtman Sette

Hi Thai,

I agree with Anton that the names are not intuitive for users.

I would use something like:
- Local authentication (for local credentials)
- ?? (I also have no idea of what is a Default protocol)
- Authenticate using name of IdPs or federation (something which is easy
to the user understand that he could use or not - this is for the discovery
service or remote IdP)

Here in the University of Kent we used another approach.
Instead of selecting the method using a list/combo box, we present all
the options in a single screen.
I think it's not beautiful, but functional.
I think it would be easier to the user if they could have all the options
in a single interface, since it doesn't become too much loaded (visually
polluted).

[image: Imagem inline 1]
Regards,
Ioram


2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:

 Hi,

 I guess Credentials is login and password. I have no idea what is
 Default Protocol or Discovery Service.
 The proposed UI is rather embarrassing.

 Anton

 On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:

 Hi all,

 I have been helping with the websso effort and wanted to get some
 feedback.
 Basically, users are presented with a login screen where they can select:
 credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it works today.
 If user selects default protocol or discovery service, they can choose to
 be redirected to those pages.

 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/

 I have attached the files and present them below:





 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

On 05/02/15 11:11, Sahid Orentino Ferdjaoui wrote:
 I'm still confused as to how this code got there, though. We shouldn't
 be hitting Galera lock contention (reported as deadlocks) if we're using
 a single master, which I thought we were. Does this mean either:
 
 I guess we can hit a lock contention even in single master.

I don't think so, but you can certainly still have real deadlocks.
They're bugs, though.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Peter Stachowski

Hi Nikhil et al.,

Thanks for the nomination!  I’m more than happy to join the core team and do 
all I can to help improve Trove and the community.  Also a +1 for the other 
nominations and sincere thanks for all the work hub_cap and grapex have done 
over the years.  Let’s keep the momentum going!

Thanks all!
Peter

From: Nikhil Manchanda [mailto:slick...@gmail.com]
Sent: February-05-15 8:27 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Trove] Core reviewer update

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

Thanks,
Nikhil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Edmond Kotowski

Everyone,
   I am honored for the nomination to be part of the Trove-Core
reviewers and am ready and willing to take on the responsibility.

Thanks,
   Eddie






 *From:* Nikhil Manchanda [mailto:slick...@gmail.com]
 *Sent:* February-05-15 8:27 AM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [Trove] Core reviewer update



 Hello Trove folks:

 Keeping in line with other OpenStack projects, and attempting to keep
 the momentum of reviews in Trove going, we need to keep our core-team up
 to date -- folks who are regularly doing good reviews on the code should
 be brought in to core and folks whose involvement is dropping off should
 be considered for removal since they lose context over time, not being
 as involved.

 For this update I'm proposing the following changes:
 - Adding Peter Stachowski (peterstac) to trove-core
 - Adding Victoria Martinez De La Cruz (vkmc) to trove-core
 - Adding Edmond Kotowski (edmondk) to trove-core
 - Removing Michael Basnight (hub_cap) from trove-core
 - Removing Tim Simpson (grapex) from trove-core

 For context on Trove reviews and who has been active, please see
 Russell's stats for Trove at:
 - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
 - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

 Trove-core members -- please reply with your vote on each of these
 proposed changes to the core team. Peter, Victoria and Eddie -- please
 let me know of your willingness to be in trove-core. Michael, and Tim --
 if you are planning on being substantially active on Trove in the near
 term, also please do let me know.

 Thanks,
 Nikhil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Add extraroutes support to neutron routers

2015-02-05 Thread Zane Bitter


On 05/02/15 12:23, James Denton wrote:

Hello all,

Regarding
https://blueprints.launchpad.net/heat/+spec/router-properties-object

Does anyone know if there are plans to implement this functionality in
an upcoming release?


Unlikely - unfortunately the Neutron API for extra routes makes it 
impossible to implement correctly. That said, Kevin's code did land in 
/contrib, so the plugin is there if you need it:


http://git.openstack.org/cgit/openstack/heat/tree/contrib/extraroute

cheers,
Zane.


Our use case meets the one described by Kevin, but
rather than trying to route traffic to an outside resource, we are
routing to another instance off the router.

Thanks!

—
James Denton


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] devstack unable to install SQLAlchemy

2015-02-05 Thread Roman Mashak

Hello,

OS - Fedora 20.

I'm in the process of integrating DPDK-accelerated Open vSwitch with
OpenStack, according to the following document
https://01.org/sites/default/files/page/accelerating_openstack_networking_with_intel_architecture_rev008.pdf

% git clone https://github.com/openstack-dev/devstack.git
% cd devstack
% git checkout 7eac0c927ca95fe3f6457b52d701a010a7e65123
% git clone https://github.com/openstack/nova.git
% cd nova
% git checkout b7738bfb6c2f271d047e8f20c0b74ef647367111

Then both nova and devstack must be patched with patches to support DPDK.

However I'm getting the following error when running stack.sh:

2015-02-05 20:06:21.284 | Collecting
SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
nova===2014.2.1.dev1.gb7738bf)
2015-02-05 20:06:21.767 |   Could not find a version that satisfies
the requirement SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
nova===2014.2.1.dev1.gb7738bf) (from versions: 0.4.2p3, 0.4.7p1,
0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6,
0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8,
0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9,
0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6,
0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6,
0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3,
0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7,
0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5,
0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5,
0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1, 0.8.2,
0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4,
0.9.5, 0.9.6, 0.9.7, 0.9.8)
2015-02-05 20:06:21.770 |   No distributions matching the version for
SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
nova===2014.2.1.dev1.gb7738bf)

I tried manually remove sqlalchemy with 'pip uninstall', as well as
remove SQLAlchemy RPM package that might conflict. This didn't help
though.

This is string from /opt/stack/requirements/global-requirements.txt:

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

I also completely removed /opt/stack/requirements/, then unstack.sh
and stack.sh again -- didn't help either.

What else I'm missing?
Thanks.

-- 
Roman Mashak

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

2015-02-05 Thread Matt Riedemann




On 2/5/2015 10:54 AM, Sean Dague wrote:

On 02/05/2015 11:50 AM, Daniel P. Berrange wrote:

On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 09:02 AM, Alexis Lee wrote:


May I suggest stricter moderation? EG a short phase to propose
items, then work through them 1 by 1. Or, we take items one by one
according to who shouts fastest but ask people not to interrupt.


Or how about going through the ones listed on the agenda, rather than
having a free-for-all shouting match?


Indeed, I thought that was the whole point of putting them in the
agenda in the first place :-)


Agreed, I think it just got away from us today with lots of first time
attendees. We'll just have to be a little clearer next time.

-Sean



Lots of first time attendees on the day of feature freeze? Weird...

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

2015-02-05 Thread Marek Denis


Thai,

We could also add an option in the Horizon's settings that automatically 
chooses one authentication workflow. At CERN we are trying to use websso 
with use of the SAML2 protocols as much as we can. That's said we 
automatically make users to use websso when they want to access their 
accounts via the dashboard.


Hint: This is being done by automatic redirect to predefined Keystone 
endpoint once user hits our dashboard's URL).


Marek


On 05.02.2015 20:15, Thai Q Tran wrote:

Hi Ioram,
Thanks for the feedback. I agree that the names are hard to follow, 
they can change to something more intuitive. Or we can even provide a 
tooltip for more information.
As for the look and feel, I don't agree that its easier if all the 
options are listed. Image if you had 5 different ways for users to log 
in and they are all shown at once. That's a lot to take in.
This approach keep things simply, it's really not that hard to pick 
from a list.


Hi Anton,
I'm just building on top of the visuals we already have without 
changing things too drastically. If you have a better idea, I would 
love to see it.


-Ioram Schechtman Sette i...@cin.ufpe.br wrote: -
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org

From: Ioram Schechtman Sette i...@cin.ufpe.br
Date: 02/05/2015 03:15AM
Subject: Re: [openstack-dev] [horizon][keystone]

Hi Thai,

I agree with Anton that the names are not intuitive for users.

I would use something like:
- Local authentication (for local credentials)
- ?? (I also have no idea of what is a Default protocol)
- Authenticate using name of IdPs or federation (something which is 
easy to the user understand that he could use or not - this is for the 
discovery service or remote IdP)


Here in the University of Kent we used another approach.
Instead of selecting the method using a list/combo box, we present 
all the options in a single screen.

I think it's not beautiful, but functional.
I think it would be easier to the user if they could have all the 
options in a single interface, since it doesn't become too much loaded 
(visually polluted).


Imagem inline 1
Regards,
Ioram


2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com 
mailto:azemlya...@mirantis.com:


Hi,

I guess Credentials is login and password. I have no idea what
is Default Protocol or Discovery Service.
The proposed UI is rather embarrassing.

Anton

On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com
mailto:tqt...@us.ibm.com wrote:

Hi all,

I have been helping with the websso effort and wanted to get
some feedback.
Basically, users are presented with a login screen where they
can select: credentials, default protocol, or discovery service.
If user selects credentials, it works exactly the same way it
works today.
If user selects default protocol or discovery service, they
can choose to be redirected to those pages.

Keep in mind that this is a prototype, early feedback will be
good.
Here are the relevant patches:
https://review.openstack.org/#/c/136177/
https://review.openstack.org/#/c/136178/
https://review.openstack.org/#/c/151842/

I have attached the files and present them below:






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Marek Denis
[marek.de...@cern.ch]

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] debtcollector 0.1.0 released

2015-02-05 Thread Joshua Harlow


The Oslo team is pleased to announce the *initial* release of:

debtcollector 0.1.0: A collection of python patterns that help you
collect your technical debt in a non-destructive manner.

For more details, please see the git log history below and:

http://launchpad.net/debtcollector/+milestone/0.1

Please report issues through launchpad:

http://bugs.launchpad.net/debtcollector

Changes in debtcollector 2c4e7d58ddec0058f..0.1.0
-

b078a94 Upper case python
9f0f114 Fix up the docs into reasonable shape
3173337 Add a moved *instance* method deprecation pattern
b833207 Initial import of renames/moves + tests
493c200 Add a .gitreview file with correct values
715f46f Adjust summary of project

Diffstat (except docs and test files)
-

.gitreview|   4 +
README.rst|  16 ++--
debtcollector/__init__.py |   2 +-
debtcollector/_utils.py   |  61 
debtcollector/moves.py| 119 
debtcollector/renames.py  |  45 +
requirements.txt  |   4 +-
setup.py  |   2 +-
test-requirements.txt |   2 +-
18 files changed, 442 insertions(+), 65 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index bc7131e..7cc0111 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6,3 @@ pbr=0.6,!=0.7,1.0
-Babel=1.3
\ No newline at end of file
+Babel=1.3
+six=1.7.0
+oslo.utils=1.2.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 7b79352..d494076 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -15 +15 @@ testscenarios=0.4
-testtools=0.9.34
\ No newline at end of file
+testtools=0.9.34


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack]Cannot install devstack on CI slave

Yes, we flipped to neutron default around that time, which appears to
have been premature. That's since been reverted -
https://review.openstack.org/#/c/153208/ and we'll make sure that it
works out of the box before it goes default again.

On 02/05/2015 07:20 AM, Eduard Matei wrote:
 Hi, 
 For two days i've been trying to install devstack.
 It keeps failing at configuring neutron, i figured out that it needs two
 new params in localrc: PUBLIC_NETWORK_GATEWAY and NETWORK_GATEWAY
 On my dev machine i managed to install it manually with these params,
 but on the CI slave it fails with error:
 
 2015-02-05 12:05:39.329 | + sudo route add -net 10.150.11.0/16 
 http://10.150.11.0/16 gw 10.140.0.1
 2015-02-05 12:05:39.440 | route: netmask doesn't match route address
 
 
 Localrc:
 
 [[local|localrc]]
 HOST_IP=10.140.0.2
 FLAT_INTERFACE=eth0
 FIXED_RANGE=10.150.11.0/16 http://10.150.11.0/16 
 FIXED_NETWORK_SIZE=255
 FLOATING_RANGE=10.140.0.0/16 http://10.140.0.0/16 
 PUBLIC_NETWORK_GATEWAY=10.140.0.2
 NETWORK_GATEWAY=10.150.11.1
 MULTI_HOST=0
 SYSLOG=False
 SCREEN_LOGDIR=/opt/stack/logs/screen-logs
 LOGFILE=/opt/stack/logs/stack.sh.log
 ADMIN_PASSWORD=*
 MYSQL_PASSWORD=*
 RABBIT_PASSWORD=*
 SERVICE_PASSWORD=*
 SERVICE_TOKEN=*
 
 
 Anyone seen this error or has any idea what i should put in the config?
 
 
 Similar log (different values for localrc):
 
 http://packages.cloudfounders.com/ci_logs/33/130733/40/check/openvstorage-cinder-functionality/ad97bc5/console.html
 
 
 Thanks,
 
 Eduard
 
 
 PS. Why did nobody report this issue so far? Either i'm doing something wrong 
 in the localrc or nobody is installing the latest devstack. 
 https://bugs.launchpad.net/devstack/+bug/1417635
 
 
 -- 
 
 *Eduard Biceri Matei, Senior Software Developer*
 www.cloudfounders.com http://www.cloudfounders.com/
  | eduard.ma...@cloudfounders.com mailto:eduard.ma...@cloudfounders.com
 __ __
 
 __ __
 *CloudFounders, The Private Cloud Software Company*
 __ __
 Disclaimer:
 This email and any files transmitted with it are confidential and
 intended solely for the use of the individual or entity to whom they are
 addressed.
 If you are not the named addressee or an employee or agent responsible
 for delivering this message to the named addressee, you are hereby
 notified that you are not authorized to read, print, retain, copy or
 disseminate this message or any part of it. If you have received this
 email in error we request you to notify us by reply e-mail and to delete
 all electronic files of the message. If you are not the intended
 recipient you are notified that disclosing, copying, distributing or
 taking any action in reliance on the contents of this information is
 strictly prohibited. 
 E-mail transmission cannot be guaranteed to be secure or error free as
 information could be intercepted, corrupted, lost, destroyed, arrive
 late or incomplete, or contain viruses. The sender therefore does not
 accept liability for any errors or omissions in the content of this
 message, and shall have no liability for any loss or damage suffered by
 the user, which arise as a result of e-mail transmission.
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] devstack unable to install SQLAlchemy

On 02/05/2015 04:05 PM, Roman Mashak wrote:
 Hello,
 
 OS - Fedora 20.
 
 I'm in the process of integrating DPDK-accelerated Open vSwitch with
 OpenStack, according to the following document
 https://01.org/sites/default/files/page/accelerating_openstack_networking_with_intel_architecture_rev008.pdf
 
 % git clone https://github.com/openstack-dev/devstack.git
 % cd devstack
 % git checkout 7eac0c927ca95fe3f6457b52d701a010a7e65123
 % git clone https://github.com/openstack/nova.git
 % cd nova
 % git checkout b7738bfb6c2f271d047e8f20c0b74ef647367111
 
 Then both nova and devstack must be patched with patches to support DPDK.

Any set of instructions that require specific git SHA then patch them of
both devstack and nova are fragile beyond all repair. Perhaps someone
from Intel can explain why that's the prefered install method.

The issue you are hitting is due to pip upgrades that happened over
Christmas, you have to be on the latest code to get past them (there
were a number of fixes that had to be pulled together), which means the
Intel instructions are incompatible with a working installation at this
time.

 
 However I'm getting the following error when running stack.sh:
 
 2015-02-05 20:06:21.284 | Collecting
 SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 nova===2014.2.1.dev1.gb7738bf)
 2015-02-05 20:06:21.767 |   Could not find a version that satisfies
 the requirement SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 nova===2014.2.1.dev1.gb7738bf) (from versions: 0.4.2p3, 0.4.7p1,
 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6,
 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8,
 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9,
 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6,
 0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6,
 0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3,
 0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7,
 0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5,
 0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5,
 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1, 0.8.2,
 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4,
 0.9.5, 0.9.6, 0.9.7, 0.9.8)
 2015-02-05 20:06:21.770 |   No distributions matching the version for
 SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 nova===2014.2.1.dev1.gb7738bf)
 
 I tried manually remove sqlalchemy with 'pip uninstall', as well as
 remove SQLAlchemy RPM package that might conflict. This didn't help
 though.
 
 This is string from /opt/stack/requirements/global-requirements.txt:
 
 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
 
 I also completely removed /opt/stack/requirements/, then unstack.sh
 and stack.sh again -- didn't help either.
 
 What else I'm missing?
 Thanks.
 


-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

2015-02-05 Thread Marek Denis


Hi,

I am more leaning towards layout Ioram suggested, but with 
protocols/other metods (Kerberos for instance) in the dropdown box.



On 05.02.2015 17:16, Steve Martinelli wrote:

Thanks Ioram,

From the keystone side: the one issue with listing IdPs is that some may
be private, so we're now looking to exploit the apache plugin data in the
environment (https://review.openstack.org/#/c/142743/), thus from the
horizon side the only data they need to send over would be the protocol
that the IdP uses.

What i'm taking away from some of the comments is to preserve the usual
(username and password) flow, and maybe it'll be easier to just list off
the protocols in a separate drop down (SAML and OpenID Connect).

Steve

Ioram Schechtman Sette i...@cin.ufpe.br wrote on 02/05/2015 06:04:36 AM:

 From: Ioram Schechtman Sette i...@cin.ufpe.br
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 02/05/2015 06:14 AM
 Subject: Re: [openstack-dev] [horizon][keystone]

 Hi Thai,

 I agree with Anton that the names are not intuitive for users.

 I would use something like:
 - Local authentication (for local credentials)
 - ?? (I also have no idea of what is a Default protocol)
 - Authenticate using name of IdPs or federation (something which
 is easy to the user understand that he could use or not - this is
 for the discovery service or remote IdP)

 Here in the University of Kent we used another approach.
 Instead of selecting the method using a list/combo box, we present
 all the options in a single screen.
 I think it's not beautiful, but functional.
 I think it would be easier to the user if they could have all the
 options in a single interface, since it doesn't become too much
 loaded (visually polluted).

 [image removed]
 Regards,
 Ioram

 2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:
 Hi,

 I guess Credentials is login and password. I have no idea what is
 Default Protocol or Discovery Service.
 The proposed UI is rather embarrassing.

 Anton

 On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:
 Hi all,

 I have been helping with the websso effort and wanted to get some 
feedback.

 Basically, users are presented with a login screen where they can
 select: credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it works 
today.

 If user selects default protocol or discovery service, they can
 choose to be redirected to those pages.

 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/

 I have attached the files and present them below:

 [image removed] [image removed] [image removed] [image removed]



 
__

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 
__

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
__

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Marek Denis
[marek.de...@cern.ch]

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] Passthrough of PF's from SR-IOV capable devices.

2015-02-05 Thread Steve Gordon

- Original Message -
 From: Przemyslaw Czesnowicz przemyslaw.czesnow...@intel.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org

 Hi

  1) If the device is a normal PCI device, but is a network card, am I
  still able to
  take advantage of the advanced syntax added circa Juno to define the
  relationship between that card and a given physical network so that the
  scheduler can place accordingly (and does this still use the ML2 mech
  drvier for
  SR-IOV even though it's a normal device.

 Actually libvirt won't allow using normal PCI devices for network
 interfaces into VM.
 Following error is thrown by libvirt 1.2.9.1:
 libvirtError: unsupported configuration: Interface type hostdev is currently
 supported on SR-IOV Virtual Functions only

 I don't know why libvirt prohibits that. But we should prohibit that on
 Openstack side as well.

This is true for hostdev style configuration, normal PCI devices are still 
valid in Libvirt for passthrough using hostdev though. The former having been 
specifically created for handling passthrough of VFs, the latter being the more 
generic passthrough functionality and what was used with the original PCI 
passthrough functionality introduced circa Havana.

I guess what I'm really asking in this particular question is what is the 
intersection of these two implementations - if any, as on face value it seems 
that to passthrough a physical PCI device I must use the older syntax and thus 
can't have the scheduler be aware of its external network connectivity.

  2) There is no functional reason from a Libvirt/Qemu perspective that I
  couldn't
  pass through a PF to a guest, and some users have expressed surprise to me
  when they have run into this check in the Nova driver. I assume in the
  initial
  implementation this was prevented to avoid a whole heap of fun additional
  logic
  that is required if this is allowed (e.g. check that no VFs from the PF
  being
  requested are already in use, remove all the associated VFs from the pool
  when
  assigning the PF, who gets allowed to use PFs versus VFs etc.). Am I
  correct here
  or is there another reason that this would be undesirable to allow in
  future -
  assuming such checks can also be designed - that I am missing?

 I think that is correct. But even if the additional logic was implemented  it
 wouldn't work because of how libvirt behaves currently.

Again though, in the code we have a distinction between a physical device (as I 
was asking about in Q1) and a physical function (as I am asking about in Q2) 
and similarly whether libvirt allows or not depends on how you configure in the 
guest XML. Though I wouldn't be surprised on the PF case if it is in fact not 
allowed in Libvirt (even with hostdev) it is again important to consider this 
distinctly separate from passing through the physical device case which we DO 
allow currently in the code I'm asking about.

-Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Request non-priority feature freeze exception for Add ability to inject routes in interfaces.template

2015-02-05 Thread Mathieu Gagné


Hi,

I am requesting the exception for the feature Add ability to inject 
routes in interfaces.template.


The potential changes in Nova are limited as the feature is opt-in.
The default interfaces.template is not changed for the reasons now 
explained in the new commit message. No comment were made so far 
requiring code refactoring, only ones about procedural technicalities. 
Furthermore, this code has been running in a production environment for 
months without any issue.


The blueprint:


https://blueprints.launchpad.net/nova/+spec/network-template-routes-injection

The change:

  https://review.openstack.org/#/c/115409/

Thanks

--
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

2015-02-05 Thread Thai Q Tran

Hi Ioram,Thanks for the feedback. I agree that the names are hard to follow, they can change to something more intuitive. Or we can even provide a tooltip for more information.As for the look and feel, I don't agree that its easier if all the options are listed. Image if you had 5 different ways for users to log in and they are all shown at once. That's a lot to take in.This approach keep things simply, it's really not that hard to pick from a list.Hi Anton,I'm just building on top of the visuals we already have without changing things too drastically. If you have a better idea, I would love to see it.-Ioram Schechtman Sette i...@cin.ufpe.br wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Ioram Schechtman Sette i...@cin.ufpe.brDate: 02/05/2015 03:15AMSubject: Re: [openstack-dev] [horizon][keystone]Hi Thai,I agree with Anton that the names are not intuitive for users.I would use something like:- Local authentication (for local credentials)- ?? (I also have no idea of what is a Default protocol)- Authenticate using name of IdPs or federation (something which is easy to the user understand that he could use or not - this is for the discovery service or remote IdP)Here in the University of Kent we used another approach.Instead of selecting the method using a "list/combo" box, we present all the options in a single screen.I think it's not beautiful, but functional.I think it would be easier to the user if they could have all the options in a single interface, since it doesn't become too much loaded (visually polluted).Regards,Ioram2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:Hi,I guess "Credentials" is login and password. I have no idea what is "Default Protocol" or "Discovery Service".The proposed UI is rather embarrassing.AntonOn Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:Hi all,I have been helping with the websso effort and wanted to get some feedback.Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service.If user selects credentials, it works exactly the same way it works today.If user selects default protocol or discovery service, they can choose to be redirected to those pages.Keep in mind that this is a prototype, early feedback will be good.Here are the relevant patches:https://review.openstack.org/#/c/136177/https://review.openstack.org/#/c/136178/https://review.openstack.org/#/c/151842/I have attached the files and present them below:__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Victoria Martínez de la Cruz

Hi all,

I'm glad to be nominated to Trove core and of course I'm willing to join
you guys. Looking forward to keep up with more and stronger contributions.

Thanks a lot!

Victoria

2015-02-05 14:17 GMT-03:00 Vipul Sabhaya vip...@gmail.com:

 +1 to all the nominations.  Many thanks to the departing cores for their
 contributions and bringing Trove to where it is today.


 On Feb 5, 2015, at 9:02 AM, Craig Vyvial cp16...@gmail.com wrote:

 +1 +1 +1
 I think these nominations will help grow the trove community.

 -Craig

 On Thu, Feb 5, 2015 at 10:48 AM, Amrith Kumar amr...@tesora.com wrote:

  Nikhil,



 Regarding your nomination of Victoria, Peter and Edmond to core, here is
 my vote (here are my votes).



 Victoria: +1

 Peter: +1

 Edmond: +1



 My thanks to all of you for your contributions to the project thus far,
 and I look forward to working with all of you moving forward.



 Also, my sincere thanks to Michael (Bas) Basnight and Tim (grapex)
 Simpson. It has been awesome working with both of you and look forward to
 working together again!



 Thanks,



 -amrith





 --



 Amrith Kumar, CTO Tesora (www.tesora.com)



 Twitter: @amrithkumar

 IRC: amrith @freenode











 *From:* Nikhil Manchanda [mailto:slick...@gmail.com]
 *Sent:* Thursday, February 05, 2015 11:27 AM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [Trove] Core reviewer update



 Hello Trove folks:

 Keeping in line with other OpenStack projects, and attempting to keep
 the momentum of reviews in Trove going, we need to keep our core-team up
 to date -- folks who are regularly doing good reviews on the code should
 be brought in to core and folks whose involvement is dropping off should
 be considered for removal since they lose context over time, not being
 as involved.

 For this update I'm proposing the following changes:
 - Adding Peter Stachowski (peterstac) to trove-core
 - Adding Victoria Martinez De La Cruz (vkmc) to trove-core
 - Adding Edmond Kotowski (edmondk) to trove-core
 - Removing Michael Basnight (hub_cap) from trove-core
 - Removing Tim Simpson (grapex) from trove-core

 For context on Trove reviews and who has been active, please see
 Russell's stats for Trove at:
 - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
 - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

 Trove-core members -- please reply with your vote on each of these
 proposed changes to the core team. Peter, Victoria and Eddie -- please
 let me know of your willingness to be in trove-core. Michael, and Tim --
 if you are planning on being substantially active on Trove in the near
 term, also please do let me know.

 Thanks,
 Nikhil

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] JavaScript docs?

2015-02-05 Thread Aaron D Sahlin

I agree with points made by both Matt and Radomir. 

We have guidelines for documenting code.   Any code.  (* I need to go see 
what our guidelines actually say)   But the goal is to have comments that 
are useful and make the code
easier to understand, follow and use. Comments should focus on what 
and why vs how.Some files are trivial, but I always appreciated 
having file level comments describing
the purpose of this file.   Then having method level comments for 
non-trivial methods, and so forth down to code blocks. This is how 
projects I have worked on in the past have commented 
so fellow team members could pick up the code and quickly get caught up to 
speed and contribute by just reading the code. 

Now that I am done rambling on comment content   As far as structure 
it would be nice to follow convention and use JSDoc or ngDoc for 
JavaScript files. 


Aaron D. Sahlin
IBMUSM07(asahlin)
Dept. X2WA
Phone 507-253-7349 Tie 553-7349




From:   Matthew Farina m...@mattfarina.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Date:   02/05/2015 11:29 AM
Subject:Re: [openstack-dev] [horizon] JavaScript docs?



I'd like to step back for a moment as to the purpose of different kinds of 
documentation. Sphinx is great and it provides some forms of 
documentation. But, why do we document methods, classes, or functions in 
python? Should we drop that and rely on Sphinx? I don't think anyone would 
argue for that.

Some documentation has a different purpose. For example, text editors and 
IDEs can introspect comments and help as we're writing the code. Or, say 
you have a bit of bit of code like the reusable wizard being written 
JavaScript. If someone is going to use it there should be a code comment 
about it. Just like you'd have for the tables class in Python because 
people are going to use it.

JavaScript is a programming language just as much as Python is. If we 
should have comments in Python we should have comments in JavaScript. It's 
no different.

JSDoc is the common format for JavaScript. It will help with text editors 
and IDEs. If we are going to move into an API docs site (which we don't 
have now) using ngDoc would be helpful. I think documenting in a useful 
manner is a different piece of scope from using that documentation to 
generate a site.

Ideally, we would document JavaScript in a useful manner no matter if we 
are creating html docs from it or not. To document in a useful manner we 
should likely use JSDoc (or ngDoc) for the useful tools rather than do it 
our own way. We should use the wheel everyone else is using rather than do 
it our own way.

Just my 2 cents.


On Thu, Feb 5, 2015 at 1:56 AM, Pavel Karikh pkar...@mirantis.com wrote:
On 02/05/2015 11:04 AM, Radomir Dopieralski wrote:
 Plus, the documentation generator that we are using already, Sphinx,
 supports JavaScript perfectly fine, so I see no reason to add another 
tool.

I agree with Radomir, why we can't just use Sphinx? 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] fixed ip info shown for port even when dhcp is disabled

2015-02-05 Thread John Belamaric

The pluggable IPAM [1] is intended to support the scenario you described below. 
That is, a fixed IP is provided for the port by IPAM, and then the DHCP server 
is programmed to return that IP for that MAC or DUID (for IPv6). If I 
understand correctly, your concern then is:

1) The DHCP server may not allow such programming;
2) The DHCP server may not be able to provide an IP allocation via any means 
other than DHCP (ie, no API to pre-allocate the IP)

I would think then, what you are asking for is the ability to attach an 
interface to a layer 2 network without also giving it an IP in any subnet(s) 
that are on that network. Seems like a reasonable request, but I am not sure 
what would be involved in implementing that.

Additionally, we would need some mechanism to update the port with the IP after 
it is allocated via the DHCP server. Otherwise, I don't think all the iptables 
rules and such will be properly configured, so you probably won't be able to 
pass traffic beyond the local subnet. Not sure on that though.


[1] - 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html



From: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com
Reply-To: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com
Date: Thursday, February 5, 2015 at 1:47 AM
To: John Belamaric jbelama...@infoblox.commailto:jbelama...@infoblox.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when 
dhcp is disabled

Hi John,
Sure, this may not be in the scope of IPAM as originally proposed in [1]. Am 
just trying to see if there can be a solution for this scenario using IPAM.

What I had in mind is also a centrally managed IPAM and not each VM allocating 
its own IP address. Let me clarify.

It's not an uncommon requirement to use a commercial DHCP server in an 
enterprise/DC. I am referring to it as external DHCP server from Openstack's 
perspective.
One scenario of deployment is when IPAM is done through Openstack and in which 
case, the MAC, IP, optionally segment can be programmed in the external DHCP 
server, assuming they have standard API's for that. Then, the VM will get the 
openstack assigned IP address from the DHCP server when it boots up. You also 
suggested this and sure, it's not a problem here.

Now, another scenario and that's of interest is when IPAM itself is done 
directly using the commercial DHCP server for various reasons. I am just trying 
to see how this model will work (or can be extended to work) for this case. 
What's the role of pluggable IPAM [1] in this scenario? If at all there's a way 
to tell the external DHCP server, do your own allocation and return an IP 
address for me for this MAC, segment, then this IP address can be returned 
during the allocate_ip API by the pluggable IPAM? But, I am not sure, an 
external DHCP server will have this flexibility.
Then, in such scenarios, the only way is to not allocate an IP address during 
create_port. When the VM comes up and sends a DHCP request the commercial DHCP 
server responds with an address. The pluggable IPAM then can use its own 
method, and when it discovers the IP address of the VM, it can call to 
update_port with the IP address.
Any other way?

[1] - 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html

Thanks,
Paddu


On Tuesday, February 3, 2015 8:57 AM, John Belamaric 
jbelama...@infoblox.commailto:jbelama...@infoblox.com wrote:


Hi Paddu,

I think this is less an issue of the pluggable IPAM than it is the Neutron 
management layer, which requires an IP for a port, as far as I know. If the 
management layer is updated to allow a port to exist without a known IP, then 
an additional IP request type could be added to represent the placeholder you 
describing.

However, doing so leaves IPAM out of the hands of Neutron and out of the hands 
of the external (presumably authoritative) IPAM system. This could lead to 
duplicate IP issues since each VM is deciding its own IP without any 
centralized coordination. I wouldn't recommend this approach to managing your 
IP space.

John

From: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com
Reply-To: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com
Date: Wednesday, January 28, 2015 at 4:58 PM
To: John Belamaric jbelama...@infoblox.commailto:jbelama...@infoblox.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when 
dhcp is disabled

Some follow up questions on this.

In 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

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

2015-02-05 Thread Alexis Lee

Sean Dague said on Wed, Feb 04, 2015 at 09:51:30AM -0500:
 As there has been a bunch of concern around patches getting lost or
 stuck, I wanted to re-announce the fact that we've got a dedicated slot
 at the weekly Nova meeting for just those sorts of things.

The slot turned into everyone talking at once fairly quickly this week.
That led to several patches not getting a real discussion.

May I suggest stricter moderation? EG a short phase to propose items,
then work through them 1 by 1. Or, we take items one by one according to
who shouts fastest but ask people not to interrupt.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] memory reporting for huge pages

2015-02-05 Thread Alexis Lee

Chris Friesen said on Wed, Feb 04, 2015 at 05:35:55PM -0600:
 it can be very difficult to determine whether
 a given flavor/image is bootable within the network

This implies to me that what you'd really like is to be able to ask the
scheduler whether a given flavor/image is bootable. The Gantt team are
working on breaking the scheduler out of Nova, as part of this it will
become a consultant rather than part of the chain-of-command for booting
instances (IE, a proxy). That should make such a query relatively easy
to support.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Kilo-2 development milestone available

2015-02-05 Thread Thierry Carrez

Hi everyone,

The second milestone of the Kilo development cycle, kilo-2 is now
reached for the Kilo integrated release projects, Keystone, Glance,
Nova, Horizon, Neutron, Cinder, Ceilometer, Heat, Trove, Sahara, and
Ironic ! It contains all the new features and bugfixes that have been
added since the the Christmas holiday break.

You can find the full list of new features and fixed bugs, as well as
tarball downloads, at:

https://launchpad.net/keystone/kilo/kilo-2
https://launchpad.net/glance/kilo/kilo-2
https://launchpad.net/nova/kilo/kilo-2
https://launchpad.net/horizon/kilo/kilo-2
https://launchpad.net/neutron/kilo/kilo-2
https://launchpad.net/cinder/kilo/kilo-2
https://launchpad.net/ceilometer/kilo/kilo-2
https://launchpad.net/heat/kilo/kilo-2
https://launchpad.net/trove/kilo/kilo-2
https://launchpad.net/sahara/kilo/kilo-2
https://launchpad.net/ironic/kilo/kilo-2

84 blueprints were implemented and no less than 708 bugs were fixed
during this milestone (not including fixes that landed in Oslo libraries).

The next development milestone, kilo-3, is scheduled for March 19th, and
will coincide with the final feature freeze for integrated projects in
the Kilo cycle.

You can further track upcoming features and Kilo release cycle status
at: http://status.openstack.org/release/

Regards,

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] devstack unable to install SQLAlchemy

2015-02-05 Thread Roman Mashak

Thanks for response.
I have pip 6.0.8, is it too old? What version should I install to move
on with installation?

2015-02-05 16:44 GMT-05:00 Sean Dague s...@dague.net:
 On 02/05/2015 04:05 PM, Roman Mashak wrote:
 Hello,

 OS - Fedora 20.

 I'm in the process of integrating DPDK-accelerated Open vSwitch with
 OpenStack, according to the following document
 https://01.org/sites/default/files/page/accelerating_openstack_networking_with_intel_architecture_rev008.pdf

 % git clone https://github.com/openstack-dev/devstack.git
 % cd devstack
 % git checkout 7eac0c927ca95fe3f6457b52d701a010a7e65123
 % git clone https://github.com/openstack/nova.git
 % cd nova
 % git checkout b7738bfb6c2f271d047e8f20c0b74ef647367111

 Then both nova and devstack must be patched with patches to support DPDK.

 Any set of instructions that require specific git SHA then patch them of
 both devstack and nova are fragile beyond all repair. Perhaps someone
 from Intel can explain why that's the prefered install method.

 The issue you are hitting is due to pip upgrades that happened over
 Christmas, you have to be on the latest code to get past them (there
 were a number of fixes that had to be pulled together), which means the
 Intel instructions are incompatible with a working installation at this
 time.


 However I'm getting the following error when running stack.sh:

 2015-02-05 20:06:21.284 | Collecting
 SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 nova===2014.2.1.dev1.gb7738bf)
 2015-02-05 20:06:21.767 |   Could not find a version that satisfies
 the requirement SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 nova===2014.2.1.dev1.gb7738bf) (from versions: 0.4.2p3, 0.4.7p1,
 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6,
 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8,
 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9,
 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6,
 0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6,
 0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3,
 0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7,
 0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5,
 0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5,
 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1, 0.8.2,
 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4,
 0.9.5, 0.9.6, 0.9.7, 0.9.8)
 2015-02-05 20:06:21.770 |   No distributions matching the version for
 SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 nova===2014.2.1.dev1.gb7738bf)

 I tried manually remove sqlalchemy with 'pip uninstall', as well as
 remove SQLAlchemy RPM package that might conflict. This didn't help
 though.

 This is string from /opt/stack/requirements/global-requirements.txt:

 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

 I also completely removed /opt/stack/requirements/, then unstack.sh
 and stack.sh again -- didn't help either.

 What else I'm missing?
 Thanks.



 --
 Sean Dague
 http://dague.net


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Roman Mashak

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread McReynolds, Auston

+1

welcome aboard peter + victoria + edmond!

From: Nikhil Manchanda slick...@gmail.commailto:slick...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, February 5, 2015 at 8:26 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Trove] Core reviewer update

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

Thanks,
Nikhil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] devstack unable to install SQLAlchemy

No, it's too new. Devstack in master is fixed to address those issues.

Supporting instructions that include out of tree patches in the
instructions are beyond what should be expected of from the development
list. The Intel folks that built these instructions and patches are the
ones you should be asking for support.

-Sean

On 02/05/2015 05:26 PM, Roman Mashak wrote:
 Thanks for response.
 I have pip 6.0.8, is it too old? What version should I install to move
 on with installation?
 
 2015-02-05 16:44 GMT-05:00 Sean Dague s...@dague.net:
 On 02/05/2015 04:05 PM, Roman Mashak wrote:
 Hello,

 OS - Fedora 20.

 I'm in the process of integrating DPDK-accelerated Open vSwitch with
 OpenStack, according to the following document
 https://01.org/sites/default/files/page/accelerating_openstack_networking_with_intel_architecture_rev008.pdf

 % git clone https://github.com/openstack-dev/devstack.git
 % cd devstack
 % git checkout 7eac0c927ca95fe3f6457b52d701a010a7e65123
 % git clone https://github.com/openstack/nova.git
 % cd nova
 % git checkout b7738bfb6c2f271d047e8f20c0b74ef647367111

 Then both nova and devstack must be patched with patches to support DPDK.

 Any set of instructions that require specific git SHA then patch them of
 both devstack and nova are fragile beyond all repair. Perhaps someone
 from Intel can explain why that's the prefered install method.

 The issue you are hitting is due to pip upgrades that happened over
 Christmas, you have to be on the latest code to get past them (there
 were a number of fixes that had to be pulled together), which means the
 Intel instructions are incompatible with a working installation at this
 time.


 However I'm getting the following error when running stack.sh:

 2015-02-05 20:06:21.284 | Collecting
 SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 nova===2014.2.1.dev1.gb7738bf)
 2015-02-05 20:06:21.767 |   Could not find a version that satisfies
 the requirement SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 nova===2014.2.1.dev1.gb7738bf) (from versions: 0.4.2p3, 0.4.7p1,
 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6,
 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8,
 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9,
 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6,
 0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6,
 0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3,
 0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7,
 0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5,
 0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5,
 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1, 0.8.2,
 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4,
 0.9.5, 0.9.6, 0.9.7, 0.9.8)
 2015-02-05 20:06:21.770 |   No distributions matching the version for
 SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 nova===2014.2.1.dev1.gb7738bf)

 I tried manually remove sqlalchemy with 'pip uninstall', as well as
 remove SQLAlchemy RPM package that might conflict. This didn't help
 though.

 This is string from /opt/stack/requirements/global-requirements.txt:

 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

 I also completely removed /opt/stack/requirements/, then unstack.sh
 and stack.sh again -- didn't help either.

 What else I'm missing?
 Thanks.



 --
 Sean Dague
 http://dague.net


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
 
 


-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

2015-02-05 Thread Thai Q Tran

Marek,Yep, that makes a lot of sense. Can definitely add that.-Marek Denis marek.de...@cern.ch wrote: -To: openstack-dev@lists.openstack.orgFrom: Marek Denis marek.de...@cern.chDate: 02/05/2015 01:35PMSubject: Re: [openstack-dev] [horizon][keystone]
  

  
  
Thai,
  
  We could also add an option in the Horizon's settings that
  automatically chooses one authentication workflow. At CERN we are
  trying to use websso with use of the SAML2 protocols as much as we
  can. That's said we automatically make users to use websso when
  they want to access their accounts via the dashboard. 
  
  Hint: This is being done by automatic redirect to predefined
  Keystone endpoint once user hits our dashboard's URL).
  
  Marek
  
  
  On 05.02.2015 20:15, Thai Q Tran wrote:


  
  Hi Ioram,
Thanks for the feedback. I agree that the names are hard to
follow, they can change to something more intuitive. Or we can
even provide a tooltip for more information.
As for the look and feel, I don't agree that its easier if all
the options are listed. Image if you had 5 different ways for
users to log in and they are all shown at once. That's a lot to
take in.
This approach keep things simply, it's really not that hard to
pick from a list.

Hi Anton,
I'm just building on top of the visuals we already have without
changing things too drastically. If you have a better idea, I
would love to see it.

-Ioram Schechtman Sette
  i...@cin.ufpe.br wrote: -

  To: "OpenStack Development Mailing List (not for
usage questions)" openstack-dev@lists.openstack.org
From: Ioram Schechtman Sette i...@cin.ufpe.br
Date: 02/05/2015 03:15AM
Subject: Re: [openstack-dev] [horizon][keystone]


  

  

  

  
Hi Thai,
  
  I agree with Anton that the names are not
  intuitive for users.
  

I would use something like:
  
  - Local authentication (for local credentials)

- ?? (I also have no idea of what is a Default
protocol)
  
  - Authenticate using name of IdPs or
  federation (something which is easy to the
  user understand that he could use or not - this is
  for the discovery service or remote IdP)
  

Here in the University of Kent we used another
approach.
  
  Instead of selecting the method using a "list/combo"
  box, we present all the options in a single screen.

I think it's not beautiful, but functional.
  
  I think it would be easier to the user if they could have
  all the options in a single interface, since it doesn't
  become too much loaded (visually polluted).
  
  
  

  
Regards,
  Ioram


  

  

  

  

  2015-02-05
9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:

  Hi,


I guess "Credentials"
  is login and password. I
  have no idea what is
  "Default Protocol" or
  "Discovery Service".
The proposed UI is
  rather embarrassing.


Anton

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

2015-02-05 Thread Tony Breeds

On Thu, Feb 05, 2015 at 11:13:50PM +0100, Sylvain Bauza wrote:

 I was always considering stuck reviews as reviews where 2 or more cores were
 disagreeing between themselves so that it was needing a debate discussion
 during the meeting.

I was under the same impression.

Stuck reviews were for reviewws were there was strong disagreement (amongst
cores)
Other reviews can be discussed as part of Open discussion

Yours Tony.


pgpCYUA7Vi0Mh.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] looking for status of an old wiki page work item

2015-02-05 Thread Ryan Moats



I've run into a set of use cases where it would really be useful to be able
to restrict which external networks a particular tenant can access, along
the lines of the wiki page [1] talks about..

When I checked for neutron blueprints, the only thing I found was [2] and
that isn't really close.

So, I'm wondering if there is a blueprint that I missed when I went
searching or if there are folks that would be interested in seeing along
the lines of [1] getting implemented...

Thanks in advance,
Ryan Moats

[1]
https://wiki.openstack.org/wiki/Neutron/sharing-model-for-external-networks
[2]
https://blueprints.launchpad.net/neutron/+spec/external-shared-net-ext-for-nuage-plugin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

2015-02-05 Thread Davanum Srinivas

LOL :)

-- dims

On Thu, Feb 5, 2015 at 4:22 PM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:


 On 2/5/2015 10:54 AM, Sean Dague wrote:

 On 02/05/2015 11:50 AM, Daniel P. Berrange wrote:

 On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 02/05/2015 09:02 AM, Alexis Lee wrote:

 May I suggest stricter moderation? EG a short phase to propose
 items, then work through them 1 by 1. Or, we take items one by one
 according to who shouts fastest but ask people not to interrupt.


 Or how about going through the ones listed on the agenda, rather than
 having a free-for-all shouting match?


 Indeed, I thought that was the whole point of putting them in the
 agenda in the first place :-)


 Agreed, I think it just got away from us today with lots of first time
 attendees. We'll just have to be a little clearer next time.

 -Sean


 Lots of first time attendees on the day of feature freeze? Weird...

 --

 Thanks,

 Matt Riedemann


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

2015-02-05 Thread Sylvain Bauza



Le 05/02/2015 17:54, Sean Dague a écrit :

On 02/05/2015 11:50 AM, Daniel P. Berrange wrote:

On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 09:02 AM, Alexis Lee wrote:


May I suggest stricter moderation? EG a short phase to propose
items, then work through them 1 by 1. Or, we take items one by one
according to who shouts fastest but ask people not to interrupt.

Or how about going through the ones listed on the agenda, rather than
having a free-for-all shouting match?

Indeed, I thought that was the whole point of putting them in the
agenda in the first place :-)

Agreed, I think it just got away from us today with lots of first time
attendees. We'll just have to be a little clearer next time.

-Sean




I was always considering stuck reviews as reviews where 2 or more cores 
were disagreeing between themselves so that it was needing a debate 
discussion during the meeting.


If we're only saying that 'stuck' means a review which hasn't been 
reviewed since a certain amount of time, then we will be having lots of 
people jumping in to ask for a review, so it would be counterproductive.


-Sylvain


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

2015-02-05 Thread Kurt Taylor

On Thu, Feb 5, 2015 at 10:46 AM, Daniel P. Berrange berra...@redhat.com
wrote:

 On Thu, Feb 05, 2015 at 10:24:24AM -0600, Kurt Taylor wrote:
  On Thu, Feb 5, 2015 at 4:31 AM, Daniel P. Berrange berra...@redhat.com
  wrote:
 
   Hi Team Nova,
  
   This is a message to alert everyone to the fact that the old hypervisor
   support matrix on the wiki[1], should really be considered obsolete.
  
   The canonical location for it going forward will be
  
  http://docs.openstack.org/developer/nova/support-matrix.html
  
   That URL shows current GIT snapshot, releases will get their own URL
   when the time comes.
  
   The source for this document is part of Nova GIT in the path
  
  doc/source/support-matrix.ini
  
   The docs are auto-generated from that ini file using a sphinx extension
  
  doc/ext/support_matrix.py
  
   The CSS styling is in
  
  doc/source/_static/support-matrix.css
  
   Some things to note here
  
- The new doc was populated based on the contents of the old wiki page
   from
  about two months ago, so if there have been additions to the wiki in
   that
  time, they might not all have been captured - depends how good I
 was at
  figuring out changes.
  
- Improvements to the content and/or HTML styling should obviously be
 sent
  as patches to Nova GIT in the files mentioned above, via normal
 Gerrit
  review practice.
  
- Since it is in GIT, the support matrix is now able to record
 information
  per release branch of Nova. So users can be clear about what
 features
  their release of Nova supports, as opposed to playing guessing
 games.
  
- The in-tree document only covers features of the in-tree Nova
 drivers.
  As such it does not include information about Docker or PowerKVM or
  the (now deleted) BareMetal drivers. My currently suggestion is that
  people maintaining out of tree drivers, should reuse the sphinx
   extension
  to format their own support matrix ini file in their local GIT repo.
  
 
  I think that maybe you have confused PowerKVM with PowerVM.  The PowerVM
  driver was removed, but PowerKVM support is in tree with libvirt.

 Ok, so the wiki page was indeed referring to the libvirt impl. That wasn't
 obvious since it didn't mention libvirt in the heading as all the other
 libvirt columns did ! Sorry for not copying across your data then.

 Regards,
 Daniel


No problem at all, here's the patch to add it:

https://review.openstack.org/#/c/153342/

Kurt Taylor (krtaylor)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][tripleo] Update on Kolla

2015-02-05 Thread Steven Dake (stdake)

Angus,

I think the appropriate place would be the openstack list, possibly with the 
[container] flag or [kolla] flag.

Regards
-steve


From: Angus Lees g...@inodes.orgmailto:g...@inodes.org
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, February 5, 2015 at 4:02 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla][tripleo] Update on Kolla

Without taking anything away from this fine and sensible direction, where 
_would_ be a good place to discuss more radical container-based deployments?
(I'm fine if the answer is use ad-hoc communication channels for now)

On Fri Feb 06 2015 at 7:24:12 AM Steven Dake (stdake) 
std...@cisco.commailto:std...@cisco.com wrote:

On 2/5/15, 10:41 AM, Paul Bourke 
paul.bou...@oracle.commailto:paul.bou...@oracle.com wrote:

Hi Steve,

Thanks for the update.  For those interested in Kolla development and
discussion, where is the best place to go?

Regards,
-Paul

Paul,

We hang out in the irc channel #tripleo on freenode.

We use launchpad at http://launchpad.net/kolla

We use the openstack-dev mailing list with the tag [kolla]

Regards,
-steve




On 05/02/15 17:25, Steven Dake (stdake) wrote:
 Hey folks,

 I wanted to provide a brief update on where we are headed with Kolla.
   Initially Kolla began as a POC to show that containers could be used
 to deploy OpenStack with the long term plan of integrating that
 functionality into TripleO.  That goal has not changed.

 The tripleo community wants baby steps not outright replacement of the
 infrastructure as was proposed by using Kubernetes in Kolla as a
 dependency in this review [1].   Our first step in this process will be
 to create three new container types.  We will create a controller node,
 a storage node, and a compute node.  We have proven that compute can be
 used.[2]  Further, one of our community members is working on a DIB
 elements-container tool here [3] and we plan to use this along with our
 other RD in the area to integrate container tech into tripleo.

 I¹m not quite sure how it will all come together, but after numerous
 discussions with folks from the tripleo and heat teams, I believe we can
 find a path forward.

 Regards
 -steve


 [1] https://review.openstack.org/#/c/144199/
 [2]

http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-openstack-comput
e-nodes/
 _[3] _https://review.openstack.org/#/c/152017/



_
_
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][tripleo] Update on Kolla

2015-02-05 Thread Angus Lees

Without taking anything away from this fine and sensible direction, where
_would_ be a good place to discuss more radical container-based deployments?
(I'm fine if the answer is use ad-hoc communication channels for now)

On Fri Feb 06 2015 at 7:24:12 AM Steven Dake (stdake) std...@cisco.com
wrote:


 On 2/5/15, 10:41 AM, Paul Bourke paul.bou...@oracle.com wrote:

 Hi Steve,
 
 Thanks for the update.  For those interested in Kolla development and
 discussion, where is the best place to go?
 
 Regards,
 -Paul

 Paul,

 We hang out in the irc channel #tripleo on freenode.

 We use launchpad at http://launchpad.net/kolla

 We use the openstack-dev mailing list with the tag [kolla]

 Regards,
 -steve



 
 On 05/02/15 17:25, Steven Dake (stdake) wrote:
  Hey folks,
 
  I wanted to provide a brief update on where we are headed with Kolla.
Initially Kolla began as a POC to show that containers could be used
  to deploy OpenStack with the long term plan of integrating that
  functionality into TripleO.  That goal has not changed.
 
  The tripleo community wants baby steps not outright replacement of the
  infrastructure as was proposed by using Kubernetes in Kolla as a
  dependency in this review [1].   Our first step in this process will be
  to create three new container types.  We will create a controller node,
  a storage node, and a compute node.  We have proven that compute can be
  used.[2]  Further, one of our community members is working on a DIB
  elements-container tool here [3] and we plan to use this along with our
  other RD in the area to integrate container tech into tripleo.
 
  I¹m not quite sure how it will all come together, but after numerous
  discussions with folks from the tripleo and heat teams, I believe we can
  find a path forward.
 
  Regards
  -steve
 
 
  [1] https://review.openstack.org/#/c/144199/
  [2]
 
 http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-
 openstack-comput
 e-nodes/
  _[3] _https://review.openstack.org/#/c/152017/
 
 
 
 __
 ___
 _
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 ___
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
 unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] FFE request for https://review.openstack.org/#/c/141012 https://blueprints.launchpad.net/openstack/?searchtext=pass-flavor-capabilities-to-ironic-virt-driver

2015-02-05 Thread Nisha Agarwal

Hi,

FFE request for the patch https://review.openstack.org/#/c/141012.

This is required by other items in ironic namely:
https://review.openstack.org/#/c/135228/6/specs/kilo/uefi-secure-boot.rst.


Regards
Nisha
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] looking for status of an old wiki page work item

2015-02-05 Thread Salvatore Orlando

I reckon the blueprint [1] supersedes the one in the old wiki page you
found.
It lies in abandoned status as it did not make the release plan for Kilo. I
am sure the author and the other contributors working on it will resume it
for the next release.

Salvatore

[1] https://review.openstack.org/#/c/132661/

On 5 February 2015 at 22:52, Ryan Moats rmo...@us.ibm.com wrote:

 I've run into a set of use cases where it would really be useful to be
 able to restrict which external networks a particular tenant can access,
 along the lines of the wiki page [1] talks about..

 When I checked for neutron blueprints, the only thing I found was [2] and
 that isn't really close.

 So, I'm wondering if there is a blueprint that I missed when I went
 searching or if there are folks that would be interested in seeing along
 the lines of [1] getting implemented...

 Thanks in advance,
 Ryan Moats

 [1]
 https://wiki.openstack.org/wiki/Neutron/sharing-model-for-external-networks
 [2]
 https://blueprints.launchpad.net/neutron/+spec/external-shared-net-ext-for-nuage-plugin


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [congress] sprinting towards Kilo2

2015-02-05 Thread sean roberts

started congress sprint hangout
https://plus.google.com/hangouts/_/gwspatjycr3rore6smdkganufua
and / or join on the #congress channel

On Wed, Feb 4, 2015 at 4:59 PM, sean roberts seanrobert...@gmail.com
wrote:

 Join the Congress team to push your code over the milestone line. The
 Congress team will be online from 9am to 5pm over the next two days. Reach
 out through the #congress IRC channel. We will start a google hangout and
 post the URL in the #congress channel.

 See you there!


 On Tuesday, February 3, 2015, sean roberts seanrobert...@gmail.com
 wrote:

 Over the last couple of meetings, we have discussed holding a hackathon
 this Thursday and Friday. You each have some code you are working on. Let’s
 each pick a 3-4 hour block of time to intensively collaborate. We can use
 the #congress IRC channel and google hangout.

 Reply to this thread, so we can allocate people’s time.

 ~ sean



 --
 ~sean




-- 

~ sean
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Clint Byrum

Excerpts from Angus Lees's message of 2015-02-04 16:59:31 -0800:
 On Thu Feb 05 2015 at 9:02:49 AM Robert Collins robe...@robertcollins.net
 wrote:
 
  On 5 February 2015 at 10:24, Joshua Harlow harlo...@outlook.com wrote:
   How interesting,
  
   Why are people using galera if it behaves like this? :-/
 
  Because its actually fairly normal. In fact its an instance of point 7
  on https://wiki.openstack.org/wiki/BasicDesignTenets - one of our
  oldest wiki pages :).
 
  In more detail, consider what happens in full isolation when you have
  the A and B example given, but B starts its transaction before A.
 
  B BEGIN
  A BEGIN
  A INSERT foo
  A COMMIT
  B SELECT foo - NULL
 
 
 Note that this still makes sense from each of A and B's individual view of
 the world.
 
 If I understood correctly, the big change with Galera that Matthew is
 highlighting is that read-after-write may not be consistent from the pov of
 a single thread.
 

No that's not a complete picture.

What Matthew is highlighting is that after a commit, a new transaction
may not see the write if it is done on a separate node in the cluster.

In a single thread, using a single database session, then a read after
successful commit is guaranteed to read a version of the database
that existed after that commit. What it may not be consistent with is
subsequent writes which may have happened after the commit on other
servers, unless you use the sync wait.

 Not have read-after-write is *really* hard to code to (see for example x86
 SMP cache coherency, C++ threading semantics, etc which all provide
 read-after-write for this reason).  This is particularly true when the
 affected operations are hidden behind an ORM - it isn't clear what might
 involve a database call and sequencers (or logical clocks, etc) aren't made
 explicit in the API.
 
 I strongly suggest just enabling wsrep_casual_reads on all galera sessions,
 unless you can guarantee that the high-level task is purely read-only, and
 then moving on to something else ;)  If we choose performance over
 correctness here then we're just signing up for lots of debugging of hard
 to reproduce race conditions, and the fixes are going to look like what
 wsrep_casual_reads does anyway.
 
 (Mind you, exposing sequencers at every API interaction would be awesome,
 and I look forward to a future framework and toolchain that makes that easy
 to do correctly)
 

I'd like to see actual examples where that will matter. Meanwhile making
all selects wait for the cluster will basically just ruin responsiveness
and waste tons of time, so we should be careful to think this through
before making any blanket policy.

I'd also like to see consideration given to systems that handle
distributed consistency in a more active manner. etcd and Zookeeper are
both such systems, and might serve as efficient guards for critical
sections without raising latency.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Clint Byrum

Excerpts from Avishay Traeger's message of 2015-02-04 22:19:53 -0800:
 On Wed, Feb 4, 2015 at 11:00 PM, Robert Collins robe...@robertcollins.net
 wrote:
 
  On 5 February 2015 at 10:24, Joshua Harlow harlo...@outlook.com wrote:
   How interesting,
  
   Why are people using galera if it behaves like this? :-/
 
  Because its actually fairly normal. In fact its an instance of point 7
  on https://wiki.openstack.org/wiki/BasicDesignTenets - one of our
  oldest wiki pages :).
 
 
 When I hear MySQL I don't exactly think of eventual consistency (#7),
 scalability (#1), horizontal scalability (#4), etc.
 For the past few months I have been advocating implementing an alternative
 to db/sqlalchemy, but of course it's a huge undertaking.  NoSQL (or even
 distributed key-value stores) should be considered IMO.  Just some food for
 thought :)
 

I know it is popular to think that MySQL* == old slow and low-scale, but
that is only popular with those who have not actually tried to scale
MySQL. You may want to have a chat with the people running MySQL at
Google, Facebook, and a long tail of not quite as big sites but still
massively bigger than most clouds. Note that many of the people who
helped those companies scale up are involved directly with OpenStack.

The NoSQL bits that are popular out there make the easy part easy. There
is no magic bullet for the hard part, which is when you need to do both
synchronous and asynchronous. Factor in its maturity and the breadth of
talent available, and I'll choose MySQL for this task every time.

* Please let's also give a nod to our friends working on MariaDB, a
  MySQL-compatible fork that many find preferrable and for the purposes
  of this discussion, equivalent.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Vipul Sabhaya

+1 to all the nominations.  Many thanks to the departing cores for their 
contributions and bringing Trove to where it is today.


 On Feb 5, 2015, at 9:02 AM, Craig Vyvial cp16...@gmail.com wrote:
 
 +1 +1 +1
 I think these nominations will help grow the trove community. 
 
 -Craig
 
 On Thu, Feb 5, 2015 at 10:48 AM, Amrith Kumar amr...@tesora.com wrote:
 Nikhil,
 
  
 
 Regarding your nomination of Victoria, Peter and Edmond to core, here is my 
 vote (here are my votes).
 
  
 
 Victoria: +1
 
 Peter: +1
 
 Edmond: +1
 
  
 
 My thanks to all of you for your contributions to the project thus far, and 
 I look forward to working with all of you moving forward.
 
  
 
 Also, my sincere thanks to Michael (Bas) Basnight and Tim (grapex) Simpson. 
 It has been awesome working with both of you and look forward to working 
 together again!
 
  
 
 Thanks,
 
  
 
 -amrith
 
  
 
  
 
 --
 
  
 
 Amrith Kumar, CTO Tesora (www.tesora.com)
 
  
 
 Twitter: @amrithkumar 
 
 IRC: amrith @freenode
 
  
 
  
 
  
 
  
 
  
 
 From: Nikhil Manchanda [mailto:slick...@gmail.com] 
 Sent: Thursday, February 05, 2015 11:27 AM
 To: OpenStack Development Mailing List
 Subject: [openstack-dev] [Trove] Core reviewer update
 
  
 
 Hello Trove folks:
 
 Keeping in line with other OpenStack projects, and attempting to keep
 the momentum of reviews in Trove going, we need to keep our core-team up
 to date -- folks who are regularly doing good reviews on the code should
 be brought in to core and folks whose involvement is dropping off should
 be considered for removal since they lose context over time, not being
 as involved.
 
 For this update I'm proposing the following changes:
 - Adding Peter Stachowski (peterstac) to trove-core
 - Adding Victoria Martinez De La Cruz (vkmc) to trove-core
 - Adding Edmond Kotowski (edmondk) to trove-core
 - Removing Michael Basnight (hub_cap) from trove-core
 - Removing Tim Simpson (grapex) from trove-core
 
 For context on Trove reviews and who has been active, please see
 Russell's stats for Trove at:
 - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
 - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt
 
 Trove-core members -- please reply with your vote on each of these
 proposed changes to the core team. Peter, Victoria and Eddie -- please
 let me know of your willingness to be in trove-core. Michael, and Tim --
 if you are planning on being substantially active on Trove in the near
 term, also please do let me know.
 
 Thanks,
 Nikhil
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python-cinderclient] Return request ID to caller

2015-02-05 Thread Joe Gordon

On Wed, Feb 4, 2015 at 11:23 PM, Malawade, Abhijeet 
abhijeet.malaw...@nttdata.com wrote:

  Hi,



 I have submitted patch for cinder-client [1] to 'Return tuple containing
 header and body from client' instead of just response.

 Also cinder spec for the same is under review [2].



 This change will break OpenStack services which are using cinder-client.
 To do not break services which are using cinder-client,

 we need to first make changes in those projects to check return type of
 cinder-client. We are working on doing cinder-client return

 type check changes in OpenStack services like nova, glance_store, heat,
 trove, manila etc.

 We have already submitted patch for same against nova :
 https://review.openstack.org/#/c/152820/



 [1] https://review.openstack.org/#/c/152075/

 [2] https://review.openstack.org/#/c/132161/


This sounds like a backwards incompatible change to the python client, that
will break downstream consumers of python-cinderclient. This change should
be done in a way that allows us to deprecate the old usage without breaking
it right away.




 I want to seek early feedback from the community members on the above
 patches, so please give your thoughts on the same.



 Thanks,

 Abhijeet Malawade

 __
 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.

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] JavaScript docs?

2015-02-05 Thread Matthew Farina

I'd like to step back for a moment as to the purpose of different kinds of
documentation. Sphinx is great and it provides some forms of documentation.
But, why do we document methods, classes, or functions in python? Should we
drop that and rely on Sphinx? I don't think anyone would argue for that.

Some documentation has a different purpose. For example, text editors and
IDEs can introspect comments and help as we're writing the code. Or, say
you have a bit of bit of code like the reusable wizard being written
JavaScript. If someone is going to use it there should be a code comment
about it. Just like you'd have for the tables class in Python because
people are going to use it.

JavaScript is a programming language just as much as Python is. If we
should have comments in Python we should have comments in JavaScript. It's
no different.

JSDoc is the common format for JavaScript. It will help with text editors
and IDEs. If we are going to move into an API docs site (which we don't
have now) using ngDoc would be helpful. I think documenting in a useful
manner is a different piece of scope from using that documentation to
generate a site.

Ideally, we would document JavaScript in a useful manner no matter if we
are creating html docs from it or not. To document in a useful manner we
should likely use JSDoc (or ngDoc) for the useful tools rather than do it
our own way. We should use the wheel everyone else is using rather than do
it our own way.

Just my 2 cents.


On Thu, Feb 5, 2015 at 1:56 AM, Pavel Karikh pkar...@mirantis.com wrote:

 On 02/05/2015 11:04 AM, Radomir Dopieralski wrote:
  Plus, the documentation generator that we are using already, Sphinx,
  supports JavaScript perfectly fine, so I see no reason to add another
 tool.

 I agree with Radomir, why we can't just use Sphinx?

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Heat] Add extraroutes support to neutron routers

2015-02-05 Thread James Denton

Hello all,

Regarding https://blueprints.launchpad.net/heat/+spec/router-properties-object

Does anyone know if there are plans to implement this functionality in an 
upcoming release? Our use case meets the one described by Kevin, but rather 
than trying to route traffic to an outside resource, we are routing to another 
instance off the router.

Thanks!

—
James Denton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla][tripleo] Update on Kolla

2015-02-05 Thread Steven Dake (stdake)

Hey folks,

I wanted to provide a brief update on where we are headed with Kolla.  
Initially Kolla began as a POC to show that containers could be used to deploy 
OpenStack with the long term plan of integrating that functionality into 
TripleO.  That goal has not changed.

The tripleo community wants baby steps not outright replacement of the 
infrastructure as was proposed by using Kubernetes in Kolla as a dependency in 
this review [1].   Our first step in this process will be to create three new 
container types.  We will create a controller node, a storage node, and a 
compute node.  We have proven that compute can be used.[2]  Further, one of our 
community members is working on a DIB elements-container tool here [3] and we 
plan to use this along with our other RD in the area to integrate container 
tech into tripleo.

I’m not quite sure how it will all come together, but after numerous 
discussions with folks from the tripleo and heat teams, I believe we can find a 
path forward.

Regards
-steve



[1] https://review.openstack.org/#/c/144199/
[2] 
http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-openstack-compute-nodes/
[3] https://review.openstack.org/#/c/152017/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

2015-02-05 Thread Matt Riedemann




On 2/5/2015 4:49 AM, Daniel P. Berrange wrote:

On Thu, Feb 05, 2015 at 11:40:46AM +0100, Andreas Jaeger wrote:

On 02/05/2015 11:31 AM, Daniel P. Berrange wrote:

This is a message to alert everyone to the fact that the old hypervisor
support matrix on the wiki[1], should really be considered obsolete
[...]


In that case, I suggest to remove it's contents and just leave a pointer
to the new location,


See my point about it being the only place with info about the out of
tree Docker  PowerKVM drivers. I want to give them time to setup a
support matrix in their own GIT repo before removing the only source
of info about them.

I will be updating the wiki page to warn people about the new location
though.

Regards,
Daniel



There might be some confusion on PowerKVM here, the pKVM support is in 
tree in the libvirt driver, that's what the PowerKVM third party CI is 
running against.


The new as of last week PowerVM driver in stackforge [1] (and older 
PowerVC driver in stackforge [2]) are different and shouldn't be in the 
hypervisor support matrix wiki or the in-tree hypervisor support table.


I can't wait for the day when there will be one power driver to rule 
them all and Frodo will have to destroy it in Mount Doom to avoid confusion.


The only thing I'd say about the pKVM support in the in-tree matrix is 
what it's distro support is, i.e. if I have latest Fedora ppc64 will 
nova libvirt/qemu work with it?  How about Ubuntu?


[1] http://git.openstack.org/cgit/stackforge/nova-powervm/
[2] http://git.openstack.org/cgit/stackforge/powervc-driver/

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

2015-02-05 Thread Kurt Taylor

On Thu, Feb 5, 2015 at 4:31 AM, Daniel P. Berrange berra...@redhat.com
wrote:

 Hi Team Nova,

 This is a message to alert everyone to the fact that the old hypervisor
 support matrix on the wiki[1], should really be considered obsolete.

 The canonical location for it going forward will be

http://docs.openstack.org/developer/nova/support-matrix.html

 That URL shows current GIT snapshot, releases will get their own URL
 when the time comes.

 The source for this document is part of Nova GIT in the path

doc/source/support-matrix.ini

 The docs are auto-generated from that ini file using a sphinx extension

doc/ext/support_matrix.py

 The CSS styling is in

doc/source/_static/support-matrix.css

 Some things to note here

  - The new doc was populated based on the contents of the old wiki page
 from
about two months ago, so if there have been additions to the wiki in
 that
time, they might not all have been captured - depends how good I was at
figuring out changes.

  - Improvements to the content and/or HTML styling should obviously be sent
as patches to Nova GIT in the files mentioned above, via normal Gerrit
review practice.

  - Since it is in GIT, the support matrix is now able to record information
per release branch of Nova. So users can be clear about what features
their release of Nova supports, as opposed to playing guessing games.

  - The in-tree document only covers features of the in-tree Nova drivers.
As such it does not include information about Docker or PowerKVM or
the (now deleted) BareMetal drivers. My currently suggestion is that
people maintaining out of tree drivers, should reuse the sphinx
 extension
to format their own support matrix ini file in their local GIT repo.


I think that maybe you have confused PowerKVM with PowerVM.  The PowerVM
driver was removed, but PowerKVM support is in tree with libvirt.



I've not deleted the wiki page, since in the short term it is the
only place with info about Docker/PowerKVM.

  - When submitting a new virt driver for merge in Nova, you should add
it to the docs/source/support-matrix.ini file. This clearly shows
reviewers what feature set your initial code submission supports

For example, the Parallels team who have been adding Parallels support
to Libvirt for Kilo should submit a patch to update this matrix prior
to Kilo release.

Likewise people working on making libvirt KVM run on Arm and PPC
should update the matrix, since it only records x86 support status
for Libvirt currently.


I will push a patch to update the matrix shortly.



  - When adding support for new APIs to existing drivers, rememeber to
update the docs/source/support-matrix.ini file to list the new
capability for the driver you changed.

  - If adding new public API features, consider whether to add a new
feature line item to the docs/source/support-matrix.ini if it is
likely users need to know about support status across drivers.

  - Against each line item feature, there is note about whether the
feature is considered mandatory to support in all drivers. The
current support matrix only lists 2 features as mandatory - start
and stop of instances. Everything else was left as optional on the
basis that at least one existing in-tree driver doesn't support
the feature.

It is very important to note that this is a *tentative* list. The
decision about mandatory vs optional features is subject to change
as it has *not* undergone detailed critique by Nova core team at
this time. IOW, we might make more features mandatory to support
in the future. TBD.

  - There is clear scope for making the existing feature list more
fine grained. For example there are many different ways to configure
block storage for guests and only a few of them are captured in the
current support matrix. Likewise for networking, and many other
aspects of guest configuration.


 Sean has added the support matrix as a discussion item for today's
 Nova meeting, to evaluate what if any changes we need to make to it
 in the near term to better capture the current thoughts of Nova team
 about support status.

   https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting

 So either send questions in this thread or join the IRC meeting

 Regards,
 Daniel

 [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix
 --
 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
 :|
 |: http://libvirt.org  -o- http://virt-manager.org
 :|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
 :|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
 :|

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

2015-02-05 Thread Kurt Taylor

On Thu, Feb 5, 2015 at 10:22 AM, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:



 On 2/5/2015 4:49 AM, Daniel P. Berrange wrote:

 On Thu, Feb 05, 2015 at 11:40:46AM +0100, Andreas Jaeger wrote:

 On 02/05/2015 11:31 AM, Daniel P. Berrange wrote:

 This is a message to alert everyone to the fact that the old hypervisor
 support matrix on the wiki[1], should really be considered obsolete
 [...]


 In that case, I suggest to remove it's contents and just leave a pointer
 to the new location,


 See my point about it being the only place with info about the out of
 tree Docker  PowerKVM drivers. I want to give them time to setup a
 support matrix in their own GIT repo before removing the only source
 of info about them.

 I will be updating the wiki page to warn people about the new location
 though.

 Regards,
 Daniel


 There might be some confusion on PowerKVM here, the pKVM support is in
 tree in the libvirt driver, that's what the PowerKVM third party CI is
 running against.

 The new as of last week PowerVM driver in stackforge [1] (and older
 PowerVC driver in stackforge [2]) are different and shouldn't be in the
 hypervisor support matrix wiki or the in-tree hypervisor support table.

 I can't wait for the day when there will be one power driver to rule them
 all and Frodo will have to destroy it in Mount Doom to avoid confusion.

 The only thing I'd say about the pKVM support in the in-tree matrix is
 what it's distro support is, i.e. if I have latest Fedora ppc64 will nova
 libvirt/qemu work with it?  How about Ubuntu?

 [1] http://git.openstack.org/cgit/stackforge/nova-powervm/
 [2] http://git.openstack.org/cgit/stackforge/powervc-driver/

 --

 Thanks,

 Matt Riedemann



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Thanks Matt, I'll include that in the patch.

Kurt Taylor (krtaylor)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] JavaScript docs?

2015-02-05 Thread Jeremy Stanley

On 2015-02-05 09:20:35 -0800 (-0800), Matthew Farina wrote:
[...]
 But, why do we document methods, classes, or functions in python?
 Should we drop that and rely on Sphinx? I don't think anyone would
 argue for that.
[...]

Particularly since Sphinx collects the method/class/function
docstrings from the source code to assemble them into
documentation[1]. I see that as its primary reason for existing in
fact. Why do you seem to think those choices are at odds with one
another?

[1] http://docs.openstack.org/developer/nova/api/nova.api.validator.html
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][tripleo] Update on Kolla

2015-02-05 Thread Paul Bourke


Hi Steve,

Thanks for the update.  For those interested in Kolla development and 
discussion, where is the best place to go?


Regards,
-Paul

On 05/02/15 17:25, Steven Dake (stdake) wrote:

Hey folks,

I wanted to provide a brief update on where we are headed with Kolla.
  Initially Kolla began as a POC to show that containers could be used
to deploy OpenStack with the long term plan of integrating that
functionality into TripleO.  That goal has not changed.

The tripleo community wants baby steps not outright replacement of the
infrastructure as was proposed by using Kubernetes in Kolla as a
dependency in this review [1].   Our first step in this process will be
to create three new container types.  We will create a controller node,
a storage node, and a compute node.  We have proven that compute can be
used.[2]  Further, one of our community members is working on a DIB
elements-container tool here [3] and we plan to use this along with our
other RD in the area to integrate container tech into tripleo.

I’m not quite sure how it will all come together, but after numerous
discussions with folks from the tripleo and heat teams, I believe we can
find a path forward.

Regards
-steve


[1] https://review.openstack.org/#/c/144199/
[2]
http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-openstack-compute-nodes/
_[3] _https://review.openstack.org/#/c/152017/


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] system information panel, update with heat-engine status

2015-02-05 Thread Manickam, Kanagaraj

Hello Horizon Cores,

In K-2, Heat is enabled with new REST API to report the running heat-engine 
status, This is in-line with how nova reports nova-compute running status.
To report this feature in horizon under 'System information panel', a new 
blueprint is created at 
https://blueprints.launchpad.net/horizon/+spec/heat-engine-status-report

Can one of you kindly approve it to target in K release, so that admin can view 
the currently running Heat-engine's status from horizon.

Thanks.

Regards
Kanagaraj M
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Denis Makogon

+1

Congratulations Peter, Victoria and Edmond.


On Thu, Feb 5, 2015 at 6:26 PM, Nikhil Manchanda slick...@gmail.com wrote:

 Hello Trove folks:

 Keeping in line with other OpenStack projects, and attempting to keep
 the momentum of reviews in Trove going, we need to keep our core-team up
 to date -- folks who are regularly doing good reviews on the code should
 be brought in to core and folks whose involvement is dropping off should
 be considered for removal since they lose context over time, not being
 as involved.

 For this update I'm proposing the following changes:
 - Adding Peter Stachowski (peterstac) to trove-core
 - Adding Victoria Martinez De La Cruz (vkmc) to trove-core
 - Adding Edmond Kotowski (edmondk) to trove-core
 - Removing Michael Basnight (hub_cap) from trove-core
 - Removing Tim Simpson (grapex) from trove-core

 For context on Trove reviews and who has been active, please see
 Russell's stats for Trove at:
 - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
 - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

 Trove-core members -- please reply with your vote on each of these
 proposed changes to the core team. Peter, Victoria and Eddie -- please
 let me know of your willingness to be in trove-core. Michael, and Tim --
 if you are planning on being substantially active on Trove in the near
 term, also please do let me know.

 Thanks,
 Nikhil

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

On 02/05/2015 11:50 AM, Daniel P. Berrange wrote:
 On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 02/05/2015 09:02 AM, Alexis Lee wrote:

 May I suggest stricter moderation? EG a short phase to propose
 items, then work through them 1 by 1. Or, we take items one by one
 according to who shouts fastest but ask people not to interrupt.

 Or how about going through the ones listed on the agenda, rather than
 having a free-for-all shouting match?
 
 Indeed, I thought that was the whole point of putting them in the
 agenda in the first place :-)

Agreed, I think it just got away from us today with lots of first time
attendees. We'll just have to be a little clearer next time.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone]

2015-02-05 Thread Steve Martinelli

Thanks Ioram,

From the keystone side: the one issue with listing IdPs is that some may
be private, so we're now looking to exploit the apache plugin data in the
environment (https://review.openstack.org/#/c/142743/), thus from the
horizon side the only data they need to send over would be the protocol
that the IdP uses.

What i'm taking away from some of the comments is to preserve the usual
(username and password) flow, and maybe it'll be easier to just list off
the protocols in a separate drop down (SAML and OpenID Connect).

Steve

Ioram Schechtman Sette i...@cin.ufpe.br wrote on 02/05/2015 06:04:36 AM:

 From: Ioram Schechtman Sette i...@cin.ufpe.br
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 02/05/2015 06:14 AM
 Subject: Re: [openstack-dev] [horizon][keystone]
 
 Hi Thai,
 
 I agree with Anton that the names are not intuitive for users.

 I would use something like:
 - Local authentication (for local credentials)
 - ?? (I also have no idea of what is a Default protocol)
 - Authenticate using name of IdPs or federation (something which 
 is easy to the user understand that he could use or not - this is 
 for the discovery service or remote IdP)

 Here in the University of Kent we used another approach.
 Instead of selecting the method using a list/combo box, we present
 all the options in a single screen.
 I think it's not beautiful, but functional.
 I think it would be easier to the user if they could have all the 
 options in a single interface, since it doesn't become too much 
 loaded (visually polluted).
 
 [image removed] 
 Regards,
 Ioram
 
 2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com:
 Hi,
 
 I guess Credentials is login and password. I have no idea what is 
 Default Protocol or Discovery Service.
 The proposed UI is rather embarrassing.
 
 Anton
 
 On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:
 Hi all,
 
 I have been helping with the websso effort and wanted to get some 
feedback.
 Basically, users are presented with a login screen where they can 
 select: credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it works 
today.
 If user selects default protocol or discovery service, they can 
 choose to be redirected to those pages.
 
 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/
 
 I have attached the files and present them below:
 
 [image removed] [image removed] [image removed] [image removed] 
 
 

 
__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
 
 
__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][neutron] Passthrough of PF's from SR-IOV capable devices.

2015-02-05 Thread Steve Gordon

Hi all,

In the current SR-IOV implementation there is a check in Nova (specifically 
_get_device_type in nova/virt/libvirt/driver.py) that determines if a given PCI 
device is:

- a normal PCI device,
- an SR-IOV physical function (PF); or
- an SR-IOV virtual function (VF).

If it's a normal PCI device or a virtual function it's considered fair game for 
passthrough, if it's a PF it's not (considered to be owned by the host). There 
are two things I am a little unclear on and was hoping someone might be able to 
help me understand:

1) If the device is a normal PCI device, but is a network card, am I still 
able to take advantage of the advanced syntax added circa Juno to define the 
relationship between that card and a given physical network so that the 
scheduler can place accordingly (and does this still use the ML2 mech drvier 
for SR-IOV even though it's a normal device.

2) There is no functional reason from a Libvirt/Qemu perspective that I 
couldn't pass through a PF to a guest, and some users have expressed surprise 
to me when they have run into this check in the Nova driver. I assume in the 
initial implementation this was prevented to avoid a whole heap of fun 
additional logic that is required if this is allowed (e.g. check that no VFs 
from the PF being requested are already in use, remove all the associated VFs 
from the pool when assigning the PF, who gets allowed to use PFs versus VFs 
etc.). Am I correct here or is there another reason that this would be 
undesirable to allow in future - assuming such checks can also be designed - 
that I am missing?

Thanks,

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Mike Bayer



Attila Fazekas afaze...@redhat.com wrote:

 I have a question related to deadlock handling as well.
 
 Why the DBDeadlock exception is not caught generally for all api/rpc request ?
 
 The mysql recommendation regarding to Deadlocks [1]:
 Normally, you must write your applications so that they are always 
 prepared to re-issue a transaction if it gets rolled back because of a 
 deadlock.
 
 Now the services are just handling the DBDeadlock in several places.
 We have some logstash hits for other places even without galera.
 
 Instead of throwing 503 to the end user, the request could be repeated 
 `silently`.
 
 The users would be able repeat the request himself,
 so the automated repeat should not cause unexpected new problem.
 
 The retry limit might be configurable, the exception needs to be watched 
 before
 anything sent to the db on behalf of the transaction or request.
 
 Considering all request handler as potential deadlock thrower seams much 
 easier than,
 deciding case by case.  

typically, deadlocks in “normal” applications are very unusual, except in
well-known “hot-spots” where they are known to occur. The deadlock-retry can
be applied to all methods as a whole, but this generally adds a lot more
weight to the app, in that methods need to be written with the assumption
that this is to occur. It complicates the potential that perhaps one method
that is already wrapped in a retry needs to call upon another method that is
also wrapped - should the wrappers organize themselves into a single “wrap”
for the whole thing?   It’s not like this is a bad idea, but it does have 
potential
implications.

Part of the promise of enginefacade [1] is that, if applications used the
decorator version (which unfortunately not all apps week to want to), we
could build this “smart retry” functionality right into the decorator and we 
would in fact gain the ability to do this pretty easily.

[1] https://review.openstack.org/#/c/125181/




 [1] http://dev.mysql.com/doc/refman/5.0/en/innodb-deadlocks.html
 
 - Original Message -
 From: Matthew Booth mbo...@redhat.com
 To: openstack-dev@lists.openstack.org
 Sent: Thursday, February 5, 2015 10:36:55 AM
 Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody 
 should know about Galera
 
 On 04/02/15 17:05, Sahid Orentino Ferdjaoui wrote:
 * Commit will fail if there is a replication conflict
 
 foo is a table with a single field, which is its primary key.
 
 A: start transaction;
 B: start transaction;
 A: insert into foo values(1);
 B: insert into foo values(1); -- 'regular' DB would block here, and
  report an error on A's commit
 A: commit; -- success
 B: commit; -- KABOOM
 
 Confusingly, Galera will report a 'deadlock' to node B, despite this not
 being a deadlock by any definition I'm familiar with.
 
 Yes ! and if I can add more information and I hope I do not make
 mistake I think it's a know issue which comes from MySQL, that is why
 we have a decorator to do a retry and so handle this case here:
 
  
 http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n177
 
 Right, and that remains a significant source of confusion and
 obfuscation in the db api. Our db code is littered with races and
 potential actual deadlocks, but only some functions are decorated. Are
 they decorated because of real deadlocks, or because of Galera lock
 contention? The solutions to those 2 problems are very different! Also,
 hunting deadlocks is hard enough work. Adding the possibility that they
 might not even be there is just evil.
 
 Incidentally, we're currently looking to replace this stuff with some
 new code in oslo.db, which is why I'm looking at it.
 
 Matt
 --
 Matthew Booth
 Red Hat Engineering, Virtualisation Team
 
 Phone: +442070094448 (UK)
 GPG ID:  D33C3490
 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] barbican resource delete question

2015-02-05 Thread Steve Heyman

Greetings all -

Today Barbican provides a “soft” delete of resources – they remain in our 
database, tagged as deleted.

We are looking at adding quotas 
(https://review.openstack.org/#/c/132091/10/specs/kilo/quota-support-for-barbican-resources.rst)
 and that introduces some pain for testing or usage patterns with many 
create/delete cycles as the quota (which includes the soft deleted resources) 
would fill up quickly making the project unusable.

Would like to gather some thoughts on how others handle this situation – making 
all deletes hard deletes isn’t an option due to things like audit trails.

[cid:41BC778A-3AB5-49E3-9292-515E9FD3B83C]
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

2015-02-05 Thread Ed Leafe

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 09:02 AM, Alexis Lee wrote:

 May I suggest stricter moderation? EG a short phase to propose
 items, then work through them 1 by 1. Or, we take items one by one
 according to who shouts fastest but ask people not to interrupt.

Or how about going through the ones listed on the agenda, rather than
having a free-for-all shouting match?

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iQIcBAEBAgAGBQJU052HAAoJEKMgtcocwZqLHiIP/A7vIQsh219+7mnxttDPLc4A
Av25XW6WJDVciPlR5VIlDIQTdl/Gy2sv2IyArhmmBalnBRiFmWbkjli9lg3/r2IY
//EtkRGNiOPSiXRVoWBSF4z/yceO/8iTdmjikVuLOCDtP9TD96Va3wxM8JFVQqa6
YpF05SqEUHoWIB1+sZ0tqK6PsDH07hgWT472kZ4jOjL9ZZUS8abAaX72tltqmt2x
V0e/liLdiO9sDD5owRZhOV6ho6AIkSeh76Ng6q9sLIKZC/Tm94s/M4R88kLaSpqE
PqaL06z5OTQXEKzBuVu6irV2c389JEdhG3HpmgI+r/b7jQJoy5Ui73V8h6+dNVvG
/hbUIoJGTQY+jgZTfDgOq41ceu0ujdhO29bR0WnfcLN9RRc0sz/cTz1c6n1MvBmP
knBkYd+TjYbsdgI7m3gD9TIvs1rgS8FQ6OOKaDHoqxrjL19rrGFOn2ZsjcODJSnk
m0Bm1Dj6jpPcyzxGZoKWJLlZ2WQvUvR6RRLw52DXWUxdUdYGIqKFpAwHrjbAzSyg
LOuyK90vixCR1Nv+iCSguvRqCo0bxGwHZfOua00qf2RQF0ByQh4cbqA+P1PuE+kC
GOP8doUbqIHMLuU1aHdIAL5u6q9ussqdc5InN58zaju2o4sdggbh2e1NBwkSM77f
KTd+HJNCsApaXhP7mRWS
=wUry
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

On Thu, Feb 05, 2015 at 10:22:08AM -0600, Matt Riedemann wrote:
 
 
 On 2/5/2015 4:49 AM, Daniel P. Berrange wrote:
 On Thu, Feb 05, 2015 at 11:40:46AM +0100, Andreas Jaeger wrote:
 On 02/05/2015 11:31 AM, Daniel P. Berrange wrote:
 This is a message to alert everyone to the fact that the old hypervisor
 support matrix on the wiki[1], should really be considered obsolete
 [...]
 
 In that case, I suggest to remove it's contents and just leave a pointer
 to the new location,
 
 See my point about it being the only place with info about the out of
 tree Docker  PowerKVM drivers. I want to give them time to setup a
 support matrix in their own GIT repo before removing the only source
 of info about them.
 
 I will be updating the wiki page to warn people about the new location
 though.
 
 Regards,
 Daniel
 
 
 There might be some confusion on PowerKVM here, the pKVM support is in tree
 in the libvirt driver, that's what the PowerKVM third party CI is running
 against.
 
 The new as of last week PowerVM driver in stackforge [1] (and older PowerVC
 driver in stackforge [2]) are different and shouldn't be in the hypervisor
 support matrix wiki or the in-tree hypervisor support table.


Ok, so in this page

   https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Features

The 'PowerKVM' column doesn't mention libvirt and it links to this page

  www.ibm.com/systems/power/software/linux/powerlinux/powerkvm


So I assumed that was referring to one of the stackforge drivers, and
that info on power-kvm-with-libvirt was simply missing entirely from
the wiki page.  So we'd need someone to update the new in-tree docs
with power-kvm-on-libvirt information from scratch.

If anyone still cares about the non-libvirt Power drivers they can
maintain a support matrix in stackforge for that.

 The only thing I'd say about the pKVM support in the in-tree matrix is what
 it's distro support is, i.e. if I have latest Fedora ppc64 will nova
 libvirt/qemu work with it?  How about Ubuntu?

The approach we've been trying to take with libvirt recently is that
each new platform we support (whether a new architecture, or new
libvirt hypervisor) would explicitly declare the minimum required
libvirt version for that platform.

eg the Parallels driver added

  MIN_LIBVIRT_PARALLELS_VERSION = (1, 2, 12)

And in init_host()

if (CONF.libvirt.virt_type == 'parallels' and
not self._host.has_min_version(MIN_LIBVIRT_PARALLELS_VERSION)):


Given that Power support in libvirt requires some minimum version,
we'll need to add a MIN_LIBVIRT_POWER_KVM_VERSION and check for
that.

These min version numbers aren't something I've attempted to capture
in the context of the feature matrix.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

On Thu, Feb 05, 2015 at 10:24:24AM -0600, Kurt Taylor wrote:
 On Thu, Feb 5, 2015 at 4:31 AM, Daniel P. Berrange berra...@redhat.com
 wrote:
 
  Hi Team Nova,
 
  This is a message to alert everyone to the fact that the old hypervisor
  support matrix on the wiki[1], should really be considered obsolete.
 
  The canonical location for it going forward will be
 
 http://docs.openstack.org/developer/nova/support-matrix.html
 
  That URL shows current GIT snapshot, releases will get their own URL
  when the time comes.
 
  The source for this document is part of Nova GIT in the path
 
 doc/source/support-matrix.ini
 
  The docs are auto-generated from that ini file using a sphinx extension
 
 doc/ext/support_matrix.py
 
  The CSS styling is in
 
 doc/source/_static/support-matrix.css
 
  Some things to note here
 
   - The new doc was populated based on the contents of the old wiki page
  from
 about two months ago, so if there have been additions to the wiki in
  that
 time, they might not all have been captured - depends how good I was at
 figuring out changes.
 
   - Improvements to the content and/or HTML styling should obviously be sent
 as patches to Nova GIT in the files mentioned above, via normal Gerrit
 review practice.
 
   - Since it is in GIT, the support matrix is now able to record information
 per release branch of Nova. So users can be clear about what features
 their release of Nova supports, as opposed to playing guessing games.
 
   - The in-tree document only covers features of the in-tree Nova drivers.
 As such it does not include information about Docker or PowerKVM or
 the (now deleted) BareMetal drivers. My currently suggestion is that
 people maintaining out of tree drivers, should reuse the sphinx
  extension
 to format their own support matrix ini file in their local GIT repo.
 
 
 I think that maybe you have confused PowerKVM with PowerVM.  The PowerVM
 driver was removed, but PowerKVM support is in tree with libvirt.

Ok, so the wiki page was indeed referring to the libvirt impl. That wasn't
obvious since it didn't mention libvirt in the heading as all the other
libvirt columns did ! Sorry for not copying across your data then.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] fixed ip info shown for port even when dhcp is disabled

2015-02-05 Thread Salvatore Orlando

I have the feeling that the discussion is diverging a bit.

John is correctly stating that with pluggable IPAM it should be possible,
in theory to write a driver which interfaces to any DHCP server, providing
it the information it needs to distribute addresses assigned by Neutron.
This is possible in theory even if the DHCP server does not expose any sort
of API - as an example you might write a driver which writes into
configuration files and then restarts or reloads the DHCP server as needed,
which is not very different from what we do today with Dnsmasq.

However, it seems to me that the gist of Padmanabhan's question is whether
neutron should allow completely out of band IP address management. Neutron
is evolving in a direction where this would be possible only if one
considers it as a simple service for building virtualised layer-2 segments.
Unless some form of interaction with the entity which manages IPs is
envisioned, it would not be possible to use neutron's security and routing
services.
Also, another aspect to factor in is nova. I have not checked this in a
while, but I seem to recall it was not able to boot a VM with network
interfaces if it did not obtain also IP addresses for such interfaces - and
those IPs are indeed fetched from neutron's port info.
If I got Padmanabhan's point right then we need to discuss if and how out
of band address mgmt and distribution should be supported in Neutron.

Regards,
Salvatore

On 5 February 2015 at 15:20, John Belamaric jbelama...@infoblox.com wrote:

  The pluggable IPAM [1] is intended to support the scenario you described
 below. That is, a fixed IP is provided for the port by IPAM, and then the
 DHCP server is programmed to return that IP for that MAC or DUID (for
 IPv6). If I understand correctly, your concern then is:

  1) The DHCP server may not allow such programming;
 2) The DHCP server may not be able to provide an IP allocation via any
 means other than DHCP (ie, no API to pre-allocate the IP)

  I would think then, what you are asking for is the ability to attach an
 interface to a layer 2 network without also giving it an IP in any
 subnet(s) that are on that network. Seems like a reasonable request, but I
 am not sure what would be involved in implementing that.

  Additionally, we would need some mechanism to update the port with the
 IP after it is allocated via the DHCP server. Otherwise, I don't think all
 the iptables rules and such will be properly configured, so you probably
 won't be able to pass traffic beyond the local subnet. Not sure on that
 though.


   [1] -
 http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html



   From: Padmanabhan Krishnan kpr...@yahoo.com
 Reply-To: Padmanabhan Krishnan kpr...@yahoo.com
 Date: Thursday, February 5, 2015 at 1:47 AM
 To: John Belamaric jbelama...@infoblox.com, OpenStack Development
 Mailing List (not for usage questions) openstack-dev@lists.openstack.org
 
 Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even
 when dhcp is disabled

Hi John,
 Sure, this may not be in the scope of IPAM as originally proposed in [1].
 Am just trying to see if there can be a solution for this scenario using
 IPAM.

  What I had in mind is also a centrally managed IPAM and not each VM
 allocating its own IP address. Let me clarify.

 It's not an uncommon requirement to use a commercial DHCP server in an
 enterprise/DC. I am referring to it as external DHCP server from
 Openstack's perspective.
 One scenario of deployment is when IPAM is done through Openstack and in
 which case, the MAC, IP, optionally segment can be programmed in the
 external DHCP server, assuming they have standard API's for that. Then, the
 VM will get the openstack assigned IP address from the DHCP server when it
 boots up. You also suggested this and sure, it's not a problem here.

  Now, another scenario and that's of interest is when IPAM itself is done
 directly using the commercial DHCP server for various reasons. I am just
 trying to see how this model will work (or can be extended to work) for
 this case. What's the role of pluggable IPAM [1] in this scenario? If at
 all there's a way to tell the external DHCP server, do your own allocation
 and return an IP address for me for this MAC, segment, then this IP
 address can be returned during the allocate_ip API by the pluggable IPAM?
 But, I am not sure, an external DHCP server will have this flexibility.
 Then, in such scenarios, the only way is to not allocate an IP address
 during create_port. When the VM comes up and sends a DHCP request the
 commercial DHCP server responds with an address. The pluggable IPAM then
 can use its own method, and when it discovers the IP address of the VM, it
 can call to update_port with the IP address.
 Any other way?

  [1] -
 http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html

  Thanks,
 Paddu


   On Tuesday, February 3, 2015 8:57 AM, John Belamaric

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 02/05/2015 09:02 AM, Alexis Lee wrote:
 
  May I suggest stricter moderation? EG a short phase to propose
  items, then work through them 1 by 1. Or, we take items one by one
  according to who shouts fastest but ask people not to interrupt.
 
 Or how about going through the ones listed on the agenda, rather than
 having a free-for-all shouting match?

Indeed, I thought that was the whole point of putting them in the
agenda in the first place :-)

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Iccha Sethi

+1.

Congratulations to the new core members.

From: Denis Makogon dmako...@mirantis.commailto:dmako...@mirantis.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, February 5, 2015 at 10:38 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Trove] Core reviewer update

+1

Congratulations Peter, Victoria and Edmond.

On Thu, Feb 5, 2015 at 6:26 PM, Nikhil Manchanda 
slick...@gmail.commailto:slick...@gmail.com wrote:
Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

Thanks,
Nikhil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] IPv6 Status

2015-02-05 Thread Brian Haley

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 05:38 AM, Ihar Hrachyshka wrote:
 On 02/05/2015 09:14 AM, Andreas Scheuring wrote:
 Hi,
 
 is there a central place where I can find a matrix (or something similar)
 that shows what is currently supposed to work in the sense of IPv6
 Networking?

I'm not sure there's a matrix, but there are a number of updates coming in
Kilo, check https://blueprints.launchpad.net/neutron/kilo for the IPv6 ones.

Most of the bug fixes are tagged and can be found here:

https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6

 I also had a look at a couple of blueprints out there, but I'm looking
 for a simple overview containing what's supported, on which features are
 people working on and what's future. I mean all the good stuff for Tenant
 Networks like
 
 - SNAT - FloatingIP - External Provider Networks - DVR - fwaas, 
 vpnaas,...

There will be no default SNATv6 or Floating IPv6 as decided at the Kilo Summit
- - they're really not necessary if the VM has a global address.

Probably the best thing for you to do is spin-up a devstack with IPv6 enabled
and see how things work, putting these in local.conf will enable both DVR and
IPv6 (assuming you have RECLONE=yes):

Q_DVR_MODE=dvr_snat

# to enable IPv4 and IPv6
IP_VERSION=4+6

 and also about the Host Network - e.g. vxlan/gre tunneling via ipv6 host
 network...
 
 AFAIK it's not supported by OVS yet. The last time I talked to a guy who
 worked on the feature, he told me that it will take some time, and it will
 probably be VXLAN only. (Unless someone steps in.)

OVS/VXLAN w/IPv6 is not supported, pointer to thread:

http://openvswitch.org/pipermail/discuss/2015-January/016344.html

- -Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU05XhAAoJEIYQqpVulyUozYgH/iple8dvRoyE0Z+9aUObcYxi
uh5jkly4zeCs7OUEOlMDeAsboKBdgEc+kSLzu6ianqd1f8CtHXG1iROn2YTb7z05
HN5bPByT9pZW5eu5lSN0KsOvlnpJCvK/Kz6xbW+cJJ03YCmHZkto64SEOcnJJ1iq
mFFnKOjxDlxHUGJyt0GNto7hQNV9RUSVA6fk7omsn5UnSP4RcZJjqbXCFW4mmU9j
ppUGB+dnGeQyKq0egPN9bzNRudSfVKA6mne5ipxOhYNzju5LBp84xqIAlBq0w7k7
8SIYsdDIrmPjWwckr6+39QHFSCUPqbNmRyH2H28CoYpd7ZQuvPZ2osseNX0AahA=
=ahi+
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

On 05/02/15 15:02, Alexis Lee wrote:
 Sean Dague said on Wed, Feb 04, 2015 at 09:51:30AM -0500:
 As there has been a bunch of concern around patches getting lost or
 stuck, I wanted to re-announce the fact that we've got a dedicated slot
 at the weekly Nova meeting for just those sorts of things.
 
 The slot turned into everyone talking at once fairly quickly this week.
 That led to several patches not getting a real discussion.
 
 May I suggest stricter moderation? EG a short phase to propose items,
 then work through them 1 by 1. Or, we take items one by one according to
 who shouts fastest but ask people not to interrupt.

+1

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Nikhil Manchanda

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

Thanks,
Nikhil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Amrith Kumar

Nikhil,

Regarding your nomination of Victoria, Peter and Edmond to core, here is my 
vote (here are my votes).

Victoria: +1
Peter: +1
Edmond: +1

My thanks to all of you for your contributions to the project thus far, and I 
look forward to working with all of you moving forward.

Also, my sincere thanks to Michael (Bas) Basnight and Tim (grapex) Simpson. It 
has been awesome working with both of you and look forward to working together 
again!

Thanks,

-amrith


--

Amrith Kumar, CTO Tesora (www.tesora.com)

Twitter: @amrithkumar
IRC: amrith @freenode





From: Nikhil Manchanda [mailto:slick...@gmail.com]
Sent: Thursday, February 05, 2015 11:27 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Trove] Core reviewer update

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

Thanks,
Nikhil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Tim Simpson

+1

Alas, my days of offering substantial activity on Trove are over. Best of luck 
in all of your adventures!



On Feb 5, 2015, at 10:26 AM, Nikhil Manchanda 
slick...@gmail.commailto:slick...@gmail.com
 wrote:

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

Thanks,
Nikhil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Core reviewer update

2015-02-05 Thread Craig Vyvial

+1 +1 +1
I think these nominations will help grow the trove community.

-Craig

On Thu, Feb 5, 2015 at 10:48 AM, Amrith Kumar amr...@tesora.com wrote:

  Nikhil,



 Regarding your nomination of Victoria, Peter and Edmond to core, here is
 my vote (here are my votes).



 Victoria: +1

 Peter: +1

 Edmond: +1



 My thanks to all of you for your contributions to the project thus far,
 and I look forward to working with all of you moving forward.



 Also, my sincere thanks to Michael (Bas) Basnight and Tim (grapex)
 Simpson. It has been awesome working with both of you and look forward to
 working together again!



 Thanks,



 -amrith





 --



 Amrith Kumar, CTO Tesora (www.tesora.com)



 Twitter: @amrithkumar

 IRC: amrith @freenode











 *From:* Nikhil Manchanda [mailto:slick...@gmail.com]
 *Sent:* Thursday, February 05, 2015 11:27 AM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [Trove] Core reviewer update



 Hello Trove folks:

 Keeping in line with other OpenStack projects, and attempting to keep
 the momentum of reviews in Trove going, we need to keep our core-team up
 to date -- folks who are regularly doing good reviews on the code should
 be brought in to core and folks whose involvement is dropping off should
 be considered for removal since they lose context over time, not being
 as involved.

 For this update I'm proposing the following changes:
 - Adding Peter Stachowski (peterstac) to trove-core
 - Adding Victoria Martinez De La Cruz (vkmc) to trove-core
 - Adding Edmond Kotowski (edmondk) to trove-core
 - Removing Michael Basnight (hub_cap) from trove-core
 - Removing Tim Simpson (grapex) from trove-core

 For context on Trove reviews and who has been active, please see
 Russell's stats for Trove at:
 - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
 - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

 Trove-core members -- please reply with your vote on each of these
 proposed changes to the core team. Peter, Victoria and Eddie -- please
 let me know of your willingness to be in trove-core. Michael, and Tim --
 if you are planning on being substantially active on Trove in the near
 term, also please do let me know.

 Thanks,
 Nikhil

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Angus Lees

On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum cl...@fewbar.com wrote:

 In a single thread, using a single database session, then a read after
 successful commit is guaranteed to read a version of the database
 that existed after that commit.


Ah, I'm relieved to hear this clarification - thanks.

I'd like to see actual examples where that will matter. Meanwhile making
 all selects wait for the cluster will basically just ruin responsiveness
 and waste tons of time, so we should be careful to think this through
 before making any blanket policy.


Matthew's example earlier in the thread is simply a user issuing two
related commands in succession:

$ nova aggregate-create
$ nova aggregate-details

Once that fails a few times, the user will put a poorly commented sleep 2
in between the two statements, and this will fix the problem most of the
time.  A better fix would repeat the aggregate-details query multiple
times until it looks like it has found the previous create.

Now, that sleep or poll is of course a poor version of something you could
do at a lower level, by waiting for reads+writes to propagate to a majority
quorum.

I'd also like to see consideration given to systems that handle
 distributed consistency in a more active manner. etcd and Zookeeper are
 both such systems, and might serve as efficient guards for critical
 sections without raising latency.


+1 for moving to such systems.  Then we can have a repeat of the above
conversation without the added complications of SQL semantics ;)

 - Gus
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Resource CREATE failed with TypeError

2015-02-05 Thread Qiming Teng

Hi,

Just checked your template.  It seems your SoftwareDeployment resource
is not referencing the SoftwareConfig resource properly.  A
SoftwareDeployment 'binds' a SoftwareConfig to a Server.  Without that
'binding', the template won't work as expected.

I'll follow up on this checking if Heat should validate that the
'config' property of a SoftwareDeployment is set.

Regards,
  Qiming

On Wed, Feb 04, 2015 at 07:23:10AM +, Zhou, Zhenzan wrote:
 Hi, Experts
 
 I am writing a template to start a multi node devstack cloud inside 
 overcloud. Heat Engine got exception after started the first controller VM. I 
 am using the latest Heat code.
 Here is the stack trace:
 
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 ERROR oslo_messaging.rpc.dispatcher 
 [req-f8fbb6d4-924d-4c0c-8b60-16ed30358765 ] Exception during message 
 handling: object of type 'NoneType' has no len()
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher Traceback 
 (most recent call last):
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
 /opt/stack/venvs/heat/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py,
  line 142, in _dispatch_and_reply
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher 
 executor_callback))
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
 /opt/stack/venvs/heat/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py,
  line 186, in _dispatch
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher 
 executor_callback)
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
 /opt/stack/venvs/heat/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py,
  line 130, in _do_dispatch
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher result 
 = func(ctxt, **new_args)
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
 /opt/stack/venvs/heat/local/lib/python2.7/site-packages/osprofiler/profiler.py,
  line 105, in wrapper
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher return 
 f(*args, **kwargs)
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
 /opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/engine/service.py,
  line 74, in wrapped
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher return 
 func(self, ctx, *args, **kwargs)
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
 /opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/engine/service.py,
  line 1386, in show_software_config
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher sc = 
 db_api.software_config_get(cnxt, config_id)
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
 /opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/db/api.py, 
 line 258, in software_config_get
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher return 
 IMPL.software_config_get(context, config_id)
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
 /opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/db/sqlalchemy/api.py,
  line 717, in software_config_get
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher result 
 = model_query(context, models.SoftwareConfig).get(config_id)
 Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
 /opt/stack/venvs/heat/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py,
  line 818, in get

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

2015-02-05 Thread Michael Still

Certainly it was my intent when I created that agenda item to cover
reviews that wouldn't otherwise reach a decision -- either two cores
wedged, or something else that we can't resolve trivially in gerrit.

Now, I can see that people don't like reviews sitting for a long time,
but that's probably too long a list to cover in an IRC meeting. I'm
not opposed to trying, but we should set expectations that we're going
to talk about only a few important reviews, not the dozens that are
unloved.

Michael

On Fri, Feb 6, 2015 at 9:27 AM, Tony Breeds t...@bakeyournoodle.com wrote:
 On Thu, Feb 05, 2015 at 11:13:50PM +0100, Sylvain Bauza wrote:

 I was always considering stuck reviews as reviews where 2 or more cores were
 disagreeing between themselves so that it was needing a debate discussion
 during the meeting.

 I was under the same impression.

 Stuck reviews were for reviewws were there was strong disagreement (amongst
 cores)
 Other reviews can be discussed as part of Open discussion

 Yours Tony.

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Rackspace Australia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Joshua Harlow

Angus Lees wrote:

On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum cl...@fewbar.com
mailto:cl...@fewbar.com wrote:

In a single thread, using a single database session, then a read after
successful commit is guaranteed to read a version of the database
that existed after that commit.

Ah, I'm relieved to hear this clarification - thanks.

I'd like to see actual examples where that will matter. Meanwhile making
all selects wait for the cluster will basically just ruin responsiveness
and waste tons of time, so we should be careful to think this through
before making any blanket policy.

Matthew's example earlier in the thread is simply a user issuing two
related commands in succession:

$ nova aggregate-create
$ nova aggregate-details

Once that fails a few times, the user will put a poorly commented sleep
2 in between the two statements, and this will fix the problem most
of the time. A better fix would repeat the aggregate-details query
multiple times until it looks like it has found the previous create.

Now, that sleep or poll is of course a poor version of something you
could do at a lower level, by waiting for reads+writes to propagate to a
majority quorum.

I'd also like to see consideration given to systems that handle
distributed consistency in a more active manner. etcd and Zookeeper are
both such systems, and might serve as efficient guards for critical
sections without raising latency.

+1 for moving to such systems. Then we can have a repeat of the above
conversation without the added complications of SQL semantics ;)

So just an fyi:

http://docs.openstack.org/developer/tooz/ exists.

Specifically:

http://docs.openstack.org/developer/tooz/developers.html#tooz.coordination.CoordinationDriver.get_lock

It has a locking api that it provides (that plugs into the various
backends); there is also a WIP https://review.openstack.org/#/c/151463/
driver that is being worked for etc.d.

-Josh

- Gus

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Gregory Haynes

Excerpts from Joshua Harlow's message of 2015-02-06 01:26:25 +:
 Angus Lees wrote:
  On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum cl...@fewbar.com
  mailto:cl...@fewbar.com wrote:
  I'd also like to see consideration given to systems that handle
  distributed consistency in a more active manner. etcd and Zookeeper are
  both such systems, and might serve as efficient guards for critical
  sections without raising latency.
 
 
  +1 for moving to such systems.  Then we can have a repeat of the above
  conversation without the added complications of SQL semantics ;)
 
 
 So just an fyi:
 
 http://docs.openstack.org/developer/tooz/ exists.
 
 Specifically:
 
 http://docs.openstack.org/developer/tooz/developers.html#tooz.coordination.CoordinationDriver.get_lock
 
 It has a locking api that it provides (that plugs into the various 
 backends); there is also a WIP https://review.openstack.org/#/c/151463/ 
 driver that is being worked for etc.d.
 

An interesting note about the etcd implementation is that you can
select per-request whether you want to wait for quorum on a read or not.
This means that in theory you could obtain higher throughput for most
operations which do not require this and then only gain quorum for
operations which require it (e.g. locks).

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Report on virtual sprinting

2015-02-05 Thread Thierry Carrez

Elizabeth K. Joseph wrote:
 [...]
 We found these virtual sprints to be incredibly valuable for knocking
 out work items that we'd defined at the Summit and in Specs. By
 focusing on specific work items we were able to spend just a day or
 two on each sprint and we didn't have the travel time (and jet lag!)
 penalty that physical sprints have. They were also relatively easy to
 schedule around the particularly active travel schedule that our team
 members have.
 [...]

That's great feedback, thanks Liz!

Personally I think F2F sprints are great to make a team converge to
common objectives, by sharing as much understanding as possible using
high-bandwidth discussions, but also spending time together off-work.
For example, the original storyboard sprint in Brussels last year was
great to build a common understanding of the goal and get all the team
behind it. I don't think a virtual sprint could have achieved that.

But if the convergence and common understanding of the goal is already
there, then virtual sprints are nearly as good to get work done, much
easier to organize, and more inclusive. Once that shared understanding
is built, it's also totally doable for smaller teams to maintain it by
leveraging design summits F2F discussions only, without the need for a
F2F midcycle sprint.

 Some lessons learned:
 
  * Schedule as far in advance as you can, taking into account the core
 people needed to complete the task
 
  * Block out time for the sprint in your schedule
 
  Just like being at a physical sprint, ignore much of the rest of IRC,
 mailing lists and other meetings and be present at the virtual sprint.
 Continous presence in channel helps the team tackle problems and
 coordinate work.

That's what I struggle to do. F2F sprints force me to focus. In virtual
sprints, I have to force myself to focus... but I agree it's critical to
the success of the virtual sprint.

 [...]
  * Use a common Gerrit topic for the sprint
 
 In order to help others in the sprint review changes, use a common
 topic in Gerrit for all changes made during the sprint, this can be
 set upon submission to Gerrit with: git review -t sprint-topic-here,
 or afterwords by the owner in the Gerrit UI.

++

Regards,

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack Foundation] Finding people to work on the EC2 API in Nova

2015-02-05 Thread Alexandre Levine


Davanum,

We've added the devstack support. It's in our stackforge repository.
https://github.com/stackforge/ec2-api/tree/master/contrib/devstack

Best regards,
  Alex Levine

On 1/31/15 2:21 AM, Davanum Srinivas wrote:

Alexandre, Randy,

Are there plans afoot to add support to switch on stackforge/ec2-api
in devstack? add tempest tests etc? CI Would go a long way in
alleviating concerns i think.

thanks,
dims

On Fri, Jan 30, 2015 at 1:24 PM, Bias, Randy randy.b...@emc.com wrote:

As you know we have been driving forward on the stack forge project and
it¹s our intention to continue to support it over time, plus reinvigorate
the GCE APIs when that makes sense. So we¹re supportive of deprecating
from Nova to focus on EC2 API in Nova.  I also think it¹s good for these
APIs to be able to iterate outside of the standard release cycle.



--Randy

VP, Technology, EMC Corporation
Formerly Founder  CEO, Cloudscaling (now a part of EMC)
+1 (415) 787-2253 [google voice]
TWITTER: twitter.com/randybias
LINKEDIN: linkedin.com/in/randybias
ASSISTANT: ren...@emc.com






On 1/29/15, 4:01 PM, Michael Still mi...@stillhq.com wrote:


Hi,

as you might have read on openstack-dev, the Nova EC2 API
implementation is in a pretty sad state. I wont repeat all of those
details here -- you can read the thread on openstack-dev for detail.

However, we got here because no one is maintaining the code in Nova
for the EC2 API. This is despite repeated calls over the last 18
months (at least).

So, does the Foundation have a role here? The Nova team has failed to
find someone to help us resolve these issues. Can the board perhaps
find resources as the representatives of some of the largest
contributors to OpenStack? Could the Foundation employ someone to help
us our here?

I suspect the correct plan is to work on getting the stackforge
replacement finished, and ensuring that it is feature compatible with
the Nova implementation. However, I don't want to preempt the design
process -- there might be other ways forward here.

I feel that a continued discussion which just repeats the last 18
months wont actually fix the situation -- its time to break out of
that mode and find other ways to try and get someone working on this
problem.

Thoughts welcome.

Michael

--
Rackspace Australia

___
Foundation mailing list
foundat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Sahid Orentino Ferdjaoui

On Thu, Feb 05, 2015 at 09:56:21AM +, Matthew Booth wrote:
 On 04/02/15 19:04, Jay Pipes wrote:
  On 02/04/2015 12:05 PM, Sahid Orentino Ferdjaoui wrote:
  On Wed, Feb 04, 2015 at 04:30:32PM +, Matthew Booth wrote:
  I've spent a few hours today reading about Galera, a clustering solution
  for MySQL. Galera provides multi-master 'virtually synchronous'
  replication between multiple mysql nodes. i.e. I can create a cluster of
  3 mysql dbs and read and write from any of them with certain consistency
  guarantees.
 
  I am no expert[1], but this is a TL;DR of a couple of things which I
  didn't know, but feel I should have done. The semantics are important to
  application design, which is why we should all be aware of them.
 
 
  * Commit will fail if there is a replication conflict
 
  foo is a table with a single field, which is its primary key.
 
  A: start transaction;
  B: start transaction;
  A: insert into foo values(1);
  B: insert into foo values(1); -- 'regular' DB would block here, and
 report an error on A's commit
  A: commit; -- success
  B: commit; -- KABOOM
 
  Confusingly, Galera will report a 'deadlock' to node B, despite this not
  being a deadlock by any definition I'm familiar with.
  
  It is a failure to certify the writeset, which bubbles up as an InnoDB
  deadlock error. See my article here:
  
  http://www.joinfu.com/2015/01/understanding-reservations-concurrency-locking-in-nova/
  
  
  Which explains this.
  
  Yes ! and if I can add more information and I hope I do not make
  mistake I think it's a know issue which comes from MySQL, that is why
  we have a decorator to do a retry and so handle this case here:
 

  http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n177
 
  
  It's not an issue with MySQL. It's an issue with any database code that
  is highly contentious.

I wanted to speak about the term deadlock (which also looks to
surprise Matthew) used, I though it comes from MySQL. In our situation
it's not really a deadlock, just a locked sessions from A and so B needs
to retry ?

I believe a deadlock would be when a session A tries to read something
on table x.foo to update y.bar when B tries to read something on y.bar
to update x.foo - so when A acquires a lock to read x.foo, B acquires
a lock to read y.bar, then when A needs to acquire lock to update
y.bar it can not, then same thing for B with x.foo.

  Almost all highly distributed or concurrent applications need to handle
  deadlock issues, and the most common way to handle deadlock issues on
  database records is using a retry technique. There's nothing new about
  that with Galera.
  
  The issue with our use of the @_retry_on_deadlock decorator is *not*
  that the retry decorator is not needed, but rather it is used too
  frequently. The compare-and-swap technique I describe in the article
  above dramatically* reduces the number of deadlocks that occur (and need
  to be handled by the @_retry_on_deadlock decorator) and dramatically
  reduces the contention over critical database sections.

Thanks for these informations.

 I'm still confused as to how this code got there, though. We shouldn't
 be hitting Galera lock contention (reported as deadlocks) if we're using
 a single master, which I thought we were. Does this mean either:

I guess we can hit a lock contention even in single master.

 A. There are deployments using multi-master?
 B. These are really deadlocks?
 
 If A, is this something we need to continue to support?
 
 Thanks,
 
 Matt
 -- 
 Matthew Booth
 Red Hat Engineering, Virtualisation Team
 
 Phone: +442070094448 (UK)
 GPG ID:  D33C3490
 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] JavaScript docs?

2015-02-05 Thread Radomir Dopieralski

On 02/05/2015 10:27 AM, Anton Zemlyanov wrote:
 JSDoc (ngdoc) is good thing. It allows to describe files, functions and
 it's parameters, constructors, classes in case of ES6.

As does Sphinx.

 The problem is it tends to diverge with reality. The code is being fixed
 and evolved, but comments are often not updated (who want to do much
 more work)? And JSDoc generated documentation loses the connection to
 reality. 

That is not a problem. We will just reject patches that do such changes
without updating the comments.

-- 
Radomir Dopieralski

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Hypervisor support matrix now in GIT

Hi Team Nova,

This is a message to alert everyone to the fact that the old hypervisor
support matrix on the wiki[1], should really be considered obsolete.

The canonical location for it going forward will be

   http://docs.openstack.org/developer/nova/support-matrix.html

That URL shows current GIT snapshot, releases will get their own URL
when the time comes.

The source for this document is part of Nova GIT in the path

   doc/source/support-matrix.ini

The docs are auto-generated from that ini file using a sphinx extension

   doc/ext/support_matrix.py

The CSS styling is in

   doc/source/_static/support-matrix.css

Some things to note here

 - The new doc was populated based on the contents of the old wiki page from
   about two months ago, so if there have been additions to the wiki in that
   time, they might not all have been captured - depends how good I was at
   figuring out changes.

 - Improvements to the content and/or HTML styling should obviously be sent
   as patches to Nova GIT in the files mentioned above, via normal Gerrit
   review practice.

 - Since it is in GIT, the support matrix is now able to record information
   per release branch of Nova. So users can be clear about what features
   their release of Nova supports, as opposed to playing guessing games.

 - The in-tree document only covers features of the in-tree Nova drivers.
   As such it does not include information about Docker or PowerKVM or
   the (now deleted) BareMetal drivers. My currently suggestion is that
   people maintaining out of tree drivers, should reuse the sphinx extension
   to format their own support matrix ini file in their local GIT repo.

   I've not deleted the wiki page, since in the short term it is the
   only place with info about Docker/PowerKVM.

 - When submitting a new virt driver for merge in Nova, you should add
   it to the docs/source/support-matrix.ini file. This clearly shows
   reviewers what feature set your initial code submission supports

   For example, the Parallels team who have been adding Parallels support
   to Libvirt for Kilo should submit a patch to update this matrix prior
   to Kilo release.

   Likewise people working on making libvirt KVM run on Arm and PPC
   should update the matrix, since it only records x86 support status
   for Libvirt currently.

 - When adding support for new APIs to existing drivers, rememeber to
   update the docs/source/support-matrix.ini file to list the new
   capability for the driver you changed.

 - If adding new public API features, consider whether to add a new
   feature line item to the docs/source/support-matrix.ini if it is
   likely users need to know about support status across drivers.

 - Against each line item feature, there is note about whether the
   feature is considered mandatory to support in all drivers. The
   current support matrix only lists 2 features as mandatory - start
   and stop of instances. Everything else was left as optional on the
   basis that at least one existing in-tree driver doesn't support
   the feature.

   It is very important to note that this is a *tentative* list. The
   decision about mandatory vs optional features is subject to change
   as it has *not* undergone detailed critique by Nova core team at
   this time. IOW, we might make more features mandatory to support
   in the future. TBD.

 - There is clear scope for making the existing feature list more
   fine grained. For example there are many different ways to configure
   block storage for guests and only a few of them are captured in the
   current support matrix. Likewise for networking, and many other
   aspects of guest configuration.


Sean has added the support matrix as a discussion item for today's
Nova meeting, to evaluate what if any changes we need to make to it
in the near term to better capture the current thoughts of Nova team
about support status.

  https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting

So either send questions in this thread or join the IRC meeting

Regards,
Daniel

[1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

On 05/02/15 04:30, Mike Bayer wrote:
 Galera doesn't change anything here. I'm really not sure what the
 fuss is about, frankly.
 
 because we’re trying to get Galera to actually work as a load
 balanced cluster to some degree, at least for reads.

Yeah, the use case of concern here is consecutive RPC transactions from
a single remote client, which can't reasonably be in the same
transaction. This affects semantics visible to the end-user.

In Nova, they might do:

$ nova aggregate-create ...
$ nova aggregate-details ...

Should they expect that the second command might fail if they don't
pause long enough between the 2? Should they retry until it succeeds?
This example is a toy, but I would expect to find many other more subtle
examples.

 Otherwise I’m not really sure why we have to bother with Galera at
 all.  If we just want a single MySQL server that has a warm standby
 for failover, why aren’t we just using that capability straight from
 MySQL.  Then we get “SELECT FOR UPDATE” and everything else back.

Actually I think this is a misconception. If I have understood
correctly[1], Galera *does* work with select for update. Use of select
for update on a single node will work exactly as normal with blocking
behaviour. Use of select for update across 2 nodes will not block, but
fail on commit if there was lock contention.

 Galera’s “multi master” capability is already in the trash for us,
 and it seems like “multi-slave” is only marginally useful either, the
 vast majority of openstack has to be 100% pointed at just one node to
 work correctly.

It's not necessarily in the trash, but given that the semantics are
different (fail on commit rather than block) we'd need to do more work
to support them. It sounds to me that we want to defer that rather than
try to fix it now. i.e. multi-master is currently unsupport(ed|able).

We could add an additional decorator to enginefacade which would
re-execute a @writer block if it detected Galera lock contention.
However, given that we'd have to audit that code for other side-effects,
for the moment it sounds like it's safer to fail.

Matt

[1] Standard caveats apply.
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Attila Fazekas

I have a question related to deadlock handling as well.

Why the DBDeadlock exception is not caught generally for all api/rpc request ?

The mysql recommendation regarding to Deadlocks [1]:
Normally, you must write your applications so that they are always 
 prepared to re-issue a transaction if it gets rolled back because of a 
deadlock.

Now the services are just handling the DBDeadlock in several places.
We have some logstash hits for other places even without galera.

Instead of throwing 503 to the end user, the request could be repeated 
`silently`.

The users would be able repeat the request himself,
so the automated repeat should not cause unexpected new problem.

The retry limit might be configurable, the exception needs to be watched before
anything sent to the db on behalf of the transaction or request.

Considering all request handler as potential deadlock thrower seams much easier 
than,
deciding case by case.  

[1] http://dev.mysql.com/doc/refman/5.0/en/innodb-deadlocks.html

- Original Message -
 From: Matthew Booth mbo...@redhat.com
 To: openstack-dev@lists.openstack.org
 Sent: Thursday, February 5, 2015 10:36:55 AM
 Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody 
 should know about Galera
 
 On 04/02/15 17:05, Sahid Orentino Ferdjaoui wrote:
  * Commit will fail if there is a replication conflict
 
  foo is a table with a single field, which is its primary key.
 
  A: start transaction;
  B: start transaction;
  A: insert into foo values(1);
  B: insert into foo values(1); -- 'regular' DB would block here, and
report an error on A's commit
  A: commit; -- success
  B: commit; -- KABOOM
 
  Confusingly, Galera will report a 'deadlock' to node B, despite this not
  being a deadlock by any definition I'm familiar with.
  
  Yes ! and if I can add more information and I hope I do not make
  mistake I think it's a know issue which comes from MySQL, that is why
  we have a decorator to do a retry and so handle this case here:
  

  http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n177
 
 Right, and that remains a significant source of confusion and
 obfuscation in the db api. Our db code is littered with races and
 potential actual deadlocks, but only some functions are decorated. Are
 they decorated because of real deadlocks, or because of Galera lock
 contention? The solutions to those 2 problems are very different! Also,
 hunting deadlocks is hard enough work. Adding the possibility that they
 might not even be there is just evil.
 
 Incidentally, we're currently looking to replace this stuff with some
 new code in oslo.db, which is why I'm looking at it.
 
 Matt
 --
 Matthew Booth
 Red Hat Engineering, Virtualisation Team
 
 Phone: +442070094448 (UK)
 GPG ID:  D33C3490
 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack Foundation] Finding people to work on the EC2 API in Nova

2015-02-05 Thread Davanum Srinivas

Alexandre,

very cool. Next step would be what we call a dsvm job that uses this
devstack hook. Example i am most familiar is is nova-docker's
check-tempest-dsvm-docker job:

https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/nova-docker.yaml
(also see zuul/layout.yaml)

thanks,
dims

On Thu, Feb 5, 2015 at 7:01 AM, Alexandre Levine
alev...@cloudscaling.com wrote:
Davanum,

We've added the devstack support. It's in our stackforge repository.
https://github.com/stackforge/ec2-api/tree/master/contrib/devstack

Best regards,
Alex Levine

On 1/31/15 2:21 AM, Davanum Srinivas wrote:

Alexandre, Randy,

Are there plans afoot to add support to switch on stackforge/ec2-api
in devstack? add tempest tests etc? CI Would go a long way in
alleviating concerns i think.

thanks,
dims

On Fri, Jan 30, 2015 at 1:24 PM, Bias, Randy randy.b...@emc.com wrote:

As you know we have been driving forward on the stack forge project and
it¹s our intention to continue to support it over time, plus reinvigorate
the GCE APIs when that makes sense. So we¹re supportive of deprecating
from Nova to focus on EC2 API in Nova. I also think it¹s good for these
APIs to be able to iterate outside of the standard release cycle.

--Randy

VP, Technology, EMC Corporation
Formerly Founder CEO, Cloudscaling (now a part of EMC)
+1 (415) 787-2253 [google voice]
TWITTER: twitter.com/randybias
LINKEDIN: linkedin.com/in/randybias
ASSISTANT: ren...@emc.com

On 1/29/15, 4:01 PM, Michael Still mi...@stillhq.com wrote:

Hi,

as you might have read on openstack-dev, the Nova EC2 API
implementation is in a pretty sad state. I wont repeat all of those
details here -- you can read the thread on openstack-dev for detail.

However, we got here because no one is maintaining the code in Nova
for the EC2 API. This is despite repeated calls over the last 18
months (at least).

So, does the Foundation have a role here? The Nova team has failed to
find someone to help us resolve these issues. Can the board perhaps
find resources as the representatives of some of the largest
contributors to OpenStack? Could the Foundation employ someone to help
us our here?

I suspect the correct plan is to work on getting the stackforge
replacement finished, and ensuring that it is feature compatible with
the Nova implementation. However, I don't want to preempt the design
process -- there might be other ways forward here.

I feel that a continued discussion which just repeats the last 18
months wont actually fix the situation -- its time to break out of
that mode and find other ways to try and get someone working on this
problem.

Thoughts welcome.

Michael

--
Rackspace Australia

___
Foundation mailing list
foundat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Davanum Srinivas :: https://twitter.com/dims

Re: [openstack-dev] [horizon][keystone]

2015-02-05 Thread Anton Zemlyanov

Hi,

I guess Credentials is login and password. I have no idea what is
Default Protocol or Discovery Service.
The proposed UI is rather embarrassing.

Anton

On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:

 Hi all,

 I have been helping with the websso effort and wanted to get some feedback.
 Basically, users are presented with a login screen where they can select:
 credentials, default protocol, or discovery service.
 If user selects credentials, it works exactly the same way it works today.
 If user selects default protocol or discovery service, they can choose to
 be redirected to those pages.

 Keep in mind that this is a prototype, early feedback will be good.
 Here are the relevant patches:
 https://review.openstack.org/#/c/136177/
 https://review.openstack.org/#/c/136178/
 https://review.openstack.org/#/c/151842/

 I have attached the files and present them below:





 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] IPv6 Status

2015-02-05 Thread Ihar Hrachyshka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 09:14 AM, Andreas Scheuring wrote:
 Hi,
 
 is there a central place where I can find a matrix (or something 
 similar) that shows what is currently supposed to work in the sense
 of IPv6 Networking?
 
 I also had a look at a couple of blueprints out there, but I'm
 looking for a simple overview containing what's supported, on which
 features are people working on and what's future. I mean all the
 good stuff for Tenant Networks like
 
 - SNAT - FloatingIP - External Provider Networks - DVR - fwaas,
 vpnaas,...
 
 and also about the Host Network - e.g. vxlan/gre tunneling via ipv6
 host network...

AFAIK it's not supported by OVS yet. The last time I talked to a guy
who worked on the feature, he told me that it will take some time, and
it will probably be VXLAN only. (Unless someone steps in.)

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU00gmAAoJEC5aWaUY1u57OZEH/ia2vXIVJDRgBtbGzp7O6dyl
fXhrLgitod0S7k6h7/ocacXkutQJ4qF8ab01Ry19YmbYB1xfE7ExSmt/Js9/rqn1
PANaDCvBe9iSEvgj/s/kmAwJNRRILvtZ8ZjFsGr1VGebJQmyqNvmZtRrljX7rfDl
o6j7grBINc+iY9sck/f9OW8wA6nzWT1nwKJksExT6pIZ/9MkeddRn/L/ALDRC0qD
6erLS/1GyG+1ByEzFApBXvtqhF8JVkUVrePm9PDWDWMnLb6db0v9J61E/KWqy+IQ
jzPnOmUlj3u3J5zFLalt6PKq2T9+58y+MziCwi9Oq8LygQWBXqeQTITmWpqD+OU=
=pwN5
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

2015-02-05 Thread Andreas Jaeger

On 02/05/2015 11:31 AM, Daniel P. Berrange wrote:
 This is a message to alert everyone to the fact that the old hypervisor
 support matrix on the wiki[1], should really be considered obsolete
 [...]

In that case, I suggest to remove it's contents and just leave a pointer
to the new location,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
   Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera