date:20150406


On 04/06/2015 10:08 PM, Angus Salkeld wrote:

On Tue, Apr 7, 2015 at 1:53 PM, Chris Friesen mailto:chris.frie...@windriver.com>> wrote:

On 04/06/2015 08:55 PM, Angus Salkeld wrote:

Hi all

For quite some time we (Heat team) have wanted to be able to send
messages to our
users (by user I do not mean the Operator, but the User that is
interacting with
the client).

What do I mean by "user messages", and how do they differ from our
current log
messages and notifications?
- Our current logs are for the operator and have information that the 
user
should not have
(ip addresses, hostnames, configuration options, other tenant info
etc..)
- Our notifications (that Ceilometer uses) *could* be used, but I am not
sure if
it quite fits.
(they seem a bit heavy weight for a log message and aimed at higher
level events)




What are some options we could investigate:
1. remote syslog
2. Zaqar
3. Other options:
 Please chip in with suggestions/links!


What about a per-user notification topic using the existing notification
backend?


Wouldn't that require the Operator to provide the end user with access to the
message bus?
Seems scary to me.


AMQP supports access controls, so is it really all that scary?  Maybe set up a 
virtual host per user if we want to be paranoid? (Just throwing it out there as 
an option since we're already using it...)


Chris

__
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-scheduler] Scheduler sub-group (gantt) meeting agenda 4/7

2015-04-06 Thread Dugger, Donald D

Meeting on #openstack-meeting at 1500 UTC (9:00AM MDT)



1)  Gantt - what's in a name?

2)  Patch status - 
https://etherpad.openstack.org/p/kilo-nova-priorities-tracking

3)  Vancouver design summit - start thinking about what we want to discuss

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

__
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] Liberty mid-cycle coding sprint

2015-04-06 Thread Ben Pfaff

On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote:
> I know we're not even at the Liberty Design Summit in Vancouver yet, but I
> wanted to take this time to announce the Neutron mid-cycle coding sprint
> for Liberty. HP has been gracious enough to offer to host at it's Fort
> Collins, CO offices. The dates are set for June 24-26, this is
> Wednesday-Friday. I've got additional information on the etherpad [1].
> 
> We'll set the specific agenda in the coming weeks, but the idea is to focus
> on things like the pending neutron-lib work [2] while there, similar to
> what we did with the advanced services split in Utah last year. My
> experience running the past two mid-cycles has been that having these
> earlier in the cycle has been helpful for landing a lot of work near the
> first milestone of a release. I expect this to be the same for Liberty with
> the sprint in Fort Collins.
> 
> Please note attendance is not required at all. We will do our best to
> facilitate virtual collaboration for those who cannot travel to the event.
> I wanted to get this out there for folks who have to book travel in advance.

I don't know anything about these events.  Naively: would OVN
development (some of which is in Neutron, much of which is not) be an
appropriate use of time at the event?

__
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] how to send messages (and events) to our users

2015-04-06 Thread Angus Salkeld

On Tue, Apr 7, 2015 at 1:53 PM, Chris Friesen 
wrote:

> On 04/06/2015 08:55 PM, Angus Salkeld wrote:
>
>> Hi all
>>
>> For quite some time we (Heat team) have wanted to be able to send
>> messages to our
>> users (by user I do not mean the Operator, but the User that is
>> interacting with
>> the client).
>>
>> What do I mean by "user messages", and how do they differ from our
>> current log
>> messages and notifications?
>> - Our current logs are for the operator and have information that the user
>> should not have
>>(ip addresses, hostnames, configuration options, other tenant info
>> etc..)
>> - Our notifications (that Ceilometer uses) *could* be used, but I am not
>> sure if
>> it quite fits.
>>(they seem a bit heavy weight for a log message and aimed at higher
>> level events)
>>
>
> 
>
>  What are some options we could investigate:
>> 1. remote syslog
>> 2. Zaqar
>> 3. Other options:
>> Please chip in with suggestions/links!
>>
>
> What about a per-user notification topic using the existing notification
> backend?
>

Wouldn't that require the Operator to provide the end user with access to
the message bus?
Seems scary to me.

-Angus


>
> Chris
>
> __
> 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] Developer survey questions

2015-04-06 Thread Dean Troyer

On Mon, Apr 6, 2015 at 9:07 PM, Robert Collins 
wrote:

> If you have any questions you'd like answered, please mail them to me
> (direct, or in reply to this) by the end of this week.
>

I would love to learn a bit about how DevStack is used outside the gate:
* Do you use DevStack as part of your everyday workflow?
* If so, on what distribution(s)?
* Do you run a non-default configuration WRT system services? ie, qpid or
zmq, or psql
* Do you run a gate-like environment using devstack-gate or something like
it?
* Do you regularly run a forked/branched DevStack
* Do you run Grenade as part of your local workflow?

I think it would be interesting to also ask about some of the other tools
developed in our community, like gertty.  Knowing the usefulness and
adoption of these tools can help justify (or not) ongoing work in this area.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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] how to send messages (and events) to our users


On 04/06/2015 08:55 PM, Angus Salkeld wrote:

Hi all

For quite some time we (Heat team) have wanted to be able to send messages to 
our
users (by user I do not mean the Operator, but the User that is interacting with
the client).

What do I mean by "user messages", and how do they differ from our current log
messages and notifications?
- Our current logs are for the operator and have information that the user
should not have
   (ip addresses, hostnames, configuration options, other tenant info etc..)
- Our notifications (that Ceilometer uses) *could* be used, but I am not sure if
it quite fits.
   (they seem a bit heavy weight for a log message and aimed at higher level 
events)





What are some options we could investigate:
1. remote syslog
2. Zaqar
3. Other options:
Please chip in with suggestions/links!


What about a per-user notification topic using the existing notification 
backend?

Chris

__
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] [TripleO] PTL Candidacy

2015-04-06 Thread James Slagle

Hi,

I'm running for TripleO PTL for the Liberty cycle. I've been an active
TripleO developer and contributor for going on 2 years now.

I'm really excited about all the great progress TripleO made during Kilo.
The puppet integration is almost fully complete and has enabled several
aspects that I'd like to see TripleO continue to improve on during Liberty:

* Better defined interfaces in tripleo-heat-templates -- The puppet work has
moved us to having a cleaner separation in the templates between the actual
deployment and configuration of the Overcloud. I'd like to see us build on
this work, particularly in a way that will enable integration with Kolla so
we can have a Heat deployed containerized Overcloud.

* Package based updates -- I really feel a traditional distribution based
package based story is the quickest way to providing an update solution for
TripleO. Containerization, once integrated, could provide a second update
solution that would provide many of the same benefits as an image based
update model.

* CI coverage -- tripleo-ci continues to prove it's value by finding real
regressions in OpenStack that otherwise would have been missed. I'd like to
continue to press on our CI and use it to report on other projects (such as
the puppet modules) where that desire exists.

There are a few other items that I feel are important for us to focus on
during Liberty:

I feel we can do a better job releasing our software projects in a way that
makes it easier to consume TripleO.  Particularly in such a way that it's
more obvious how to use it together to deploy OpenStack. I think a part of
that would be the re-introduction of using stable branches and to improve
our documentation on deploying via TripleO.

I'd also like to see us make it easier for users to get started with
TripleO.  The only so called "entry point" or way to get started with
TripleO currently is devtest.  While devtest works for developers and at
driving our CI, I don't consider it something to be used for deploying an
actual production cloud. I think we need to work to fill this gap.

Making things easier to get started would also help us bring in new
developers.  In the same vein, we grow our developer community by
integrating with things like Puppet and Kolla. I think we have a lot of
great opportunity here to show how TripleO can integrate with new and
existing deployment solutions.

Finally, moving forward, I'd like to see our project encourage more
leadership growth. I don't feel like the majority of a project's leadership
needs to come from just 1 (or a few) individual or role. If elected as PTL,
I'd look forward to fostering this type of growth in our community.

Thanks for your consideration!

-- 
-- James Slagle
--

__
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] [all] how to send messages (and events) to our users

2015-04-06 Thread Angus Salkeld

Hi all

For quite some time we (Heat team) have wanted to be able to send messages
to our
users (by user I do not mean the Operator, but the User that is interacting
with the client).

What do I mean by "user messages", and how do they differ from our current
log messages
and notifications?
- Our current logs are for the operator and have information that the user
should not have
  (ip addresses, hostnames, configuration options, other tenant info etc..)
- Our notifications (that Ceilometer uses) *could* be used, but I am not
sure if it quite fits.
  (they seem a bit heavy weight for a log message and aimed at higher level
events)

These messages could be (based on Heat's use case):

- Specific user oriented log messages (distinct from our normal operator
logs)
- Deprecation messages (if they are using old resource properties/template
features)
- Progress and resource state changes (an application doesn't want to poll
an api for a state change)
- Automated actions (autoscaling events, time based actions)
- Potentially integrated server logs (from in guest agents)

I wanted to raise this to "[all]" as it would be great to have a general
solution that
all projects can make use of.

What do we have now:
- The user can not get any kind of log message from services. The closest
thing
  ATM is the notifications in Ceilometer, but I have the feeling that these
have a different aim.
- nova console log
- Heat has a DB "event" table for users (we have long wanted to get rid of
this)

What do other clouds provide:
- https://devcenter.heroku.com/articles/logging
- https://cloud.google.com/logging/docs/
- https://aws.amazon.com/blogs/aws/cloudwatch-log-service/
- http://aws.amazon.com/cloudtrail/
(other examples...)

What are some options we could investigate:
1. remote syslog
The user provides a rsyslog server IP/port and we send their messages
to that.
[pros] simple, and the user could also send their server's log messages
to the same
  rsyslog - great visibility into what is going on.

  There are great tools like loggly/logstash/papertrailapp that
source logs from remote syslog
  It leaves the user in control of what tools they get to use.

[cons] Would we become a spam agent (just sending traffic to an
IP/Port) - I guess that's how remote syslog
   works. I am not sure if this is an issue or not?

  This might be a lesser solution for the use case of "an
application doesn't want to poll an api for a state change"

  I am not sure how we would integrate this with horizon.

2. Zaqar
We send the messages to a queue in Zaqar.
[pros] multi tenant OpenStack project for messaging!

[cons] I don't think Zaqar is installed in most installations (tho'
please correct me here if this
   is wrong). I know Mirantis does not currently support Zaqar,
so that would be a problem for me.

  There is not the level of external tooling like in option "1"
(logstash and friends)

3. Other options:
   Please chip in with suggestions/links!


https://blueprints.launchpad.net/heat/+spec/user-visible-logs


Regards
Angus
__
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] PTL Candidacy


I'd like to announce my candidacy for the Heat PTL in Liberty.

As I was the PTL during Icehouse, this will be Heat's first rerun PTL 
under our convention for rotating leaders. Even if elected I would hope 
that we continue to find Heat PTL new-blood for future cycles.


Towards the end of the Kilo cycle we started to get some momentum on 
landing the changes required for the Convergence effort. The aim will be 
to get much of the first-phase features landing early in Liberty, and 
spend the rest of the cycle focusing on convergence features which 
provide the most user benefit.


There are important maintenance tasks in the Liberty cycle which will 
need continued effort, including functional/integration testing, content 
for the template-writer's guide, and general usability improvements.


It seems that our merge throughput would be higher if our existing 
review attention were more coordinated. Nova has had some success with 
priorities, and Swift works well with a PTL curated etherpad of 
suggested reviews. I'd like to discuss the options with other heat 
cores, and am currently suggesting something like the Swift approach.


As the Big Tent process continues to mature I'd like to ensure that Heat 
is well positioned to qualify for the appropriate tags as they are 
defined. Also it would be worth looking into whether there should be 
heat-related tags available for projects with sufficiently mature 
resource implementations.


I'll be continuing Heat's tradition of the leadership emerging from a 
shared consensus, leaving the PTL as a point of coordination within the 
project, and a point of communication to the greater ecosystem.


I look forward to the opportunity to do this!

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] Developer survey questions

2015-04-06 Thread Andre Martin


> On Apr 7, 2015, at 11:07, Robert Collins  wrote:
> 
> I'd like to do a survey of us - the developers hacking on OpenStack.
> 
> Since getting folk to do such things takes up their time, I'd like to
> include in the survey any questions other folk have pending that
> they'd like answered. I don't want to ask things that we can answer by
> e.g. git repo analysis. So questions like 'what projects do you
> contribute to' - nope.
> 
> If you have any questions you'd like answered, please mail them to me
> (direct, or in reply to this) by the end of this week.
> 
> Questions that I intend to ask already:
> How many years have you been contributing to OpenStack
>  [needed to control for the next question]
> How many years have you been writing in Python
> How fluent do you consider yourself to be in:
> - Python
> - C
> - Javascript
> How much time do you spend doing:
> - operations
> - development
> - packaging/redistribution
> What operating system do you use to do your OpenStack development

Excellent initiative.

A few more questions:
- Are you coding on OpenStack as part of your daytime job
- What percentage of your time can you dedicate to OpenStack
- Is your employer enforcing a policy for upstream contributions (internal code 
review, require approval, etc)

Regards,
Martin

> Cheers,
> Rob
> 
> -- 
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
> 
> __
> 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


"PLEASE NOTE:  This email,  and  any  attachments  hereto,  are
intended only  for use  by the specified addressee(s)  and  may
contain legally privileged and/or confidential and/or proprietary
information of KVH Co., Ltd.  and/or its affiliates  (including
personal information).  If you are not the intended recipient of
this email, please immediately notify the sender by email,  and
please permanently  delete the original,  any print out and any
copies of the foregoing. "



__
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] Developer survey questions

2015-04-06 Thread Robert Collins

I'd like to do a survey of us - the developers hacking on OpenStack.

Since getting folk to do such things takes up their time, I'd like to
include in the survey any questions other folk have pending that
they'd like answered. I don't want to ask things that we can answer by
e.g. git repo analysis. So questions like 'what projects do you
contribute to' - nope.

If you have any questions you'd like answered, please mail them to me
(direct, or in reply to this) by the end of this week.

Questions that I intend to ask already:
How many years have you been contributing to OpenStack
  [needed to control for the next question]
How many years have you been writing in Python
How fluent do you consider yourself to be in:
 - Python
 - C
 - Javascript
How much time do you spend doing:
 - operations
 - development
 - packaging/redistribution
What operating system do you use to do your OpenStack development

Cheers,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [Infra] Meeting Tuesday April 7th at 19:00 UTC

2015-04-06 Thread Elizabeth K. Joseph

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday April 7th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

In case you missed it or would like a refresher, meeting logs and
minutes from our last two meetings are available.

March 24th:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-03-24-19.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-03-24-19.00.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-03-24-19.00.log.html

March 31st:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-03-31-19.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-03-31-19.00.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-03-31-19.00.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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] PTL Candidacy

2015-04-06 Thread Michael Still

On Fri, Apr 3, 2015 at 12:38 AM, Matthew Booth  wrote:
> On 02/04/15 07:20, Michael Still wrote:

First off, sorry for the slow reply to this email. The reason that I
sent my candidacy email at the very start of the election window is
that Easter is a four day holiday in Australia, so I sent the email
about then disappeared to do family stuff all weekend. I'm only just
catching up on email now.

>> I'd like another term as Nova PTL, if you'll have me.

[snip]

>> I think its a good idea also to examine briefly some statistics about specs:
>>
>> Juno:
>>approved but not implemented: 40
>>implemented: 49
>>
>> Kilo:
>>approved but not implemented: 30
>>implemented: 32

[snip]

> It has been my impression over at least the last 2 releases that the
> most significant barrier to progress in Nova is the lack of core
> reviewer bandwidth. This affects not only feature development, but also
> the much less sexy paying down of technical debt. There have been
> various attempts to redefine roles and create new processes, but no
> attempt that I have seen to address the underlying fundamental issue:
> the lack of people who can +2 patches.
>
> There is a discussion currently ongoing on this list, "The Evolution of
> core developer to maintainer", which contains a variety of proposals.
> However, none of these will gain anything close to a consensus. The
> result of this will be that none of them will be implemented. We will be
> left by default with the status quo, and the situation will continue not
> to improve despite the new processes we will invent instead.
>
> The only way we are going to change the status quo is by fiat. We should
> of course make every effort to get as many people on board as possible.
> However, when change is required, but nobody can agree precisely which
> change, we need positive leadership from the PTL.
>
> Would you like to take a position on how to improve core reviewer
> throughput in the next cycle?

Thanks for the question.

I agree that cores aren't keeping up with the workload in Nova,
although I think its a quite complicated issue with no single fix.

For example, we could look at the number of patchsets, and the number
of reviews by cores and decide that cores aren't keeping up. That
doesn't take into account the number of those patchsets waiting on the
author to respond to comments from a previous reviewer though. It also
doesn't take into account that patchsets at the end of review chains
will by definition take a longer time to merge and therefore will
experience more patchsets through rebases. As a tangible example, when
the VMWare driver was being refactored there were patches at the end
of the review chain which ended up with 40 or 50 revisions through
this rebasing. That's not actually a problem as long as the _start_ of
the review chain is getting active reviews.

Additionally, we have consistently asked for non-cores to help cover
the review load. It doesn't have to be a core that notices a problem
with a patch -- anyone can do that. There are many people who do help
out with non-core reviews, and I am thankful for all of them. However,
I keep meeting people who complain about review delays, but who don't
have a history of reviewing themselves. That's confusing and
frustrating to me.

So, we need to encourage everyone to do more reviews, not just promote
more cores to rubber stamp. We also need to work on better metrics for
which reviews are genuinely blocked (i.e. not waiting on the author to
perform an action or stuck at the end of a review chain). Russell has
done some work on this in the past, but its something that I think
needs a reinvigorated effort in Liberty.

That said, you're right. Core is too static a group. There are still
cores not doing many reviews, and the group should grow as Nova grows.
Last release I asked cores to keep an eye out for people who were
close to being trusted enough, so that we could mentor those people
across the line. That work needs to continue in Liberty.

With our current veto process for core nominations, it is very easy
for a proposed core to be blocked from being added. I think our
"founding developers" had good intent here -- core disagreements are
expensive to resolve and slow us down even more than blocking on
reviews. We do need to grow more cores though as the current ones drop
away through attrition.

I don't have a simple solution to this problem. I do think its
something we can solve if we keep hammering at it though.

Michael

-- 
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] [neutron] [QoS] QoS weekly meeting

2015-04-06 Thread Kyle Mestery

On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando 
wrote:

>
>
> On 7 April 2015 at 00:33, Armando M.  wrote:
>
>>
>> On 6 April 2015 at 08:56, Miguel Ángel Ajo  wrote:
>>
>>>  I’d like to co-organized a QoS weekly meeting with Sean M. Collins,
>>>
>>> In the last few years, the interest for QoS support has increased,
>>> Sean has been leading
>>> this effort [1] and we believe we should get into a consensus about how
>>> to model an extension
>>> to let vendor plugins implement QoS capabilities on network ports and
>>> tenant networks, and
>>> how to extend agents, and the reference implementation & others [2]
>>>
>>
> As you surely know, so far every attempt to achieve a consensus has failed
> in a pretty miserable way.
> This mostly because "QoS" can be interpreted in a lot of different ways,
> both from the conceptual and practical perspective.
> It is important in my opinion to clearly define the goals first. For
> instance a simple extensions for bandwidth limiting could be a reasonable
> target for the Liberty release.
> Moving things such as ECN into "future works" is the right thing to do in
> my opinion. Attempting to define a flexible framework that can deal with
> advanced QoS policies specification is a laudable effort, but I am a bit
> skeptical about its feasibility.
>
> ++, I think focusing on perhaps bandwidth limiting may make a lot of sense.


>
>
>>
>>> As per discussion we’ve had during the last few months [3], I
>>> believe we should start simple, but
>>> prepare a model allowing future extendibility, to allow for example
>>> specific traffic rules (per port,
>>> per IP, etc..), congestion notification support [4], …
>>>
>>
> "Simple" in my mind is even more extreme then what you're proposing
> here... I'd start with bare APIs for specifying bandwidth limiting, and
> then phase them out once this "framework" is in place.
> Also note that this kind of design bears some overlap with the flavor
> framework which is probably going to be another goal for Liberty.
>
> Indeed, and the flavor framework is something I'm hoping we can land by
Liberty-1 (yes, I just said Liberty-1).


> Morever, consider using "common" tools such as the specs repo to share and
> discuss design documents.
>
>
Also a good idea.


>
>>> It’s the first time I’m trying to organize an openstack/neutron
>>> meeting, so, I don’t know what’s the
>>> best way to do it, or find the best timeslot. I guess interested people
>>> may have a saying, so I’ve
>>> looped anybody I know is interested in the CC of this mail.
>>>
>>
>> I think that's a good idea. Incidentally I was speaking with Sean
>> regarding Summit session [1], and we were hoping we could get some folks
>> together either prior or during the summit, to try and get some momentum
>> going behind this initiative, once again.
>>
>
> I think is a good idea as well.  I was thinking that perhaps it might be a
> good idea to grab a design summit session as well (surely not a fishbowl
> one as they're totally unfit for this purpose).
> However, it might be good to achieve some sort of consensus before the
> summit, as as we know fairly well now the summit is probably the worst
> place where consensus can be achieved!
>
> And finally, agreed here as well.


>
>> We'd need to fill in page [2], and find an empty slot on [3]
>>
>> One thing I had proposed to Miguel was to use the meeting as an initial
starting point, and then once momentum is achieved to naturally end it and
move any further meeting needs to the regular Neutron meeting.


> Thanks for starting this thread!
>>
>> [1]
>> https://openstacksummitmay2015vancouver.sched.org/event/27eeef71d5f57997ac09b4c7783c72fe#.VSMIzJT-NhM
>>
>> [2] https://wiki.openstack.org/wiki/NeutronSubTeams
>> [3] https://wiki.openstack.org/wiki/Meetings
>>
>>
>>
>>>
>>> Miguel Ángel Ajo
>>>
>>> [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api
>>> [2]
>>> https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing
>>> [3]
>>> https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231
>>> [4]
>>> https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification
>>>
>>>
>>> __
>>> 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-

[openstack-dev] [Neutron]: partially update over REST APIs

2015-04-06 Thread Yi Yang


Does neutron support partially update over REST APIs (PUT method)?

In other words, if an property is NOT included in the update, will be 
property be removed, or just kept as its existing value?


Yi

__
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] [stable] [Cinder] FFE for "Clear migration_status from a destination volume if migration fails"

2015-04-06 Thread Mitsuhiro Tanino

Hello,

I would like to get a FFE for patch https://review.openstack.org/#/c/161328/.

This patch fixes the volume migration problem which is not executed proper 
cleanup steps if the volume migration is failed. This change only affects 
cleanup steps and does not change normal volume migration steps.

Regards,
Mitsuhiro Tanino 
HITACHI DATA SYSTEMS
__
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] [QoS] QoS weekly meeting

2015-04-06 Thread Salvatore Orlando

On 7 April 2015 at 00:33, Armando M.  wrote:

>
> On 6 April 2015 at 08:56, Miguel Ángel Ajo  wrote:
>
>>  I’d like to co-organized a QoS weekly meeting with Sean M. Collins,
>>
>> In the last few years, the interest for QoS support has increased,
>> Sean has been leading
>> this effort [1] and we believe we should get into a consensus about how
>> to model an extension
>> to let vendor plugins implement QoS capabilities on network ports and
>> tenant networks, and
>> how to extend agents, and the reference implementation & others [2]
>>
>
As you surely know, so far every attempt to achieve a consensus has failed
in a pretty miserable way.
This mostly because "QoS" can be interpreted in a lot of different ways,
both from the conceptual and practical perspective.
It is important in my opinion to clearly define the goals first. For
instance a simple extensions for bandwidth limiting could be a reasonable
target for the Liberty release.
Moving things such as ECN into "future works" is the right thing to do in
my opinion. Attempting to define a flexible framework that can deal with
advanced QoS policies specification is a laudable effort, but I am a bit
skeptical about its feasibility.



>
>> As per discussion we’ve had during the last few months [3], I believe
>> we should start simple, but
>> prepare a model allowing future extendibility, to allow for example
>> specific traffic rules (per port,
>> per IP, etc..), congestion notification support [4], …
>>
>
"Simple" in my mind is even more extreme then what you're proposing here...
I'd start with bare APIs for specifying bandwidth limiting, and then phase
them out once this "framework" is in place.
Also note that this kind of design bears some overlap with the flavor
framework which is probably going to be another goal for Liberty.

Morever, consider using "common" tools such as the specs repo to share and
discuss design documents.


>
>> It’s the first time I’m trying to organize an openstack/neutron
>> meeting, so, I don’t know what’s the
>> best way to do it, or find the best timeslot. I guess interested people
>> may have a saying, so I’ve
>> looped anybody I know is interested in the CC of this mail.
>>
>
> I think that's a good idea. Incidentally I was speaking with Sean
> regarding Summit session [1], and we were hoping we could get some folks
> together either prior or during the summit, to try and get some momentum
> going behind this initiative, once again.
>

I think is a good idea as well.  I was thinking that perhaps it might be a
good idea to grab a design summit session as well (surely not a fishbowl
one as they're totally unfit for this purpose).
However, it might be good to achieve some sort of consensus before the
summit, as as we know fairly well now the summit is probably the worst
place where consensus can be achieved!


> We'd need to fill in page [2], and find an empty slot on [3]
>
> Thanks for starting this thread!
>
> [1]
> https://openstacksummitmay2015vancouver.sched.org/event/27eeef71d5f57997ac09b4c7783c72fe#.VSMIzJT-NhM
>
> [2] https://wiki.openstack.org/wiki/NeutronSubTeams
> [3] https://wiki.openstack.org/wiki/Meetings
>
>
>
>>
>> Miguel Ángel Ajo
>>
>> [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api
>> [2]
>> https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing
>> [3]
>> https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231
>> [4]
>> https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification
>>
>> __
>> 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] cinder[stable/juno] Fix the eqlx driver to retry on ssh timeout(Backport)

2015-04-06 Thread Mike Perez

On 16:33 Mon 06 Apr , rajini_...@dell.com wrote:
> Dell - Internal Use - Confidential
> Hi
> 
> Can we have a  freeze exception on this CR pl?
> 
> https://review.openstack.org/154123

The change has been waiting since February, was blocked because of me and is
limited to just the Dell driver, so this seems fine and fair to grant. I have
commented in the review.

-- 
Mike Perez

__
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][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

2015-04-06 Thread Robert Collins

On 7 April 2015 at 05:11, Joe Gordon  wrote:
>
>
> On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews 
> wrote:
>>
>>
>> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic  wrote:
>>>
>>> Jay,
>>>
>>>
 Not far, IMHO. 100ms difference in startup time isn't something we
 should spend much time optimizing. There's bigger fish to fry.
>>>
>>>
>>> I agree that priority of this task shouldn't be critical or even high,
>>> and that there are other places that can be improved in OpenStack.
>>>
>>> In other hand this one is as well big source of UX issues that we have in
>>> OpenStack..
>>>
>>> For example:
>>>
>>> 1) You would like to run some command X times where X is pretty big
>>> (admins likes to do this via bash loops). If you can execute all of them for
>>> 1 and not 10 minutes you will get happier end user.
>>
>>
>> +1 I'm fully in support of this effort. Shaving 100ms off the startup time
>> of a frequently used library means that you'll save that 100ms over and
>> over, adding up to a huge win.
>>
>
>
> Another data point on how slow our libraries/CLIs can be:
>
> $ time openstack -h
> 
> real0m2.491s
> user0m2.378s
> sys 0m0.111s


pbr should be snappy - taking 100ms to get the version is wrong.

-Rob



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [QoS] QoS weekly meeting

2015-04-06 Thread Armando M.

On 6 April 2015 at 08:56, Miguel Ángel Ajo  wrote:

>  I’d like to co-organized a QoS weekly meeting with Sean M. Collins,
>
> In the last few years, the interest for QoS support has increased,
> Sean has been leading
> this effort [1] and we believe we should get into a consensus about how to
> model an extension
> to let vendor plugins implement QoS capabilities on network ports and
> tenant networks, and
> how to extend agents, and the reference implementation & others [2]
>
> As per discussion we’ve had during the last few months [3], I believe
> we should start simple, but
> prepare a model allowing future extendibility, to allow for example
> specific traffic rules (per port,
> per IP, etc..), congestion notification support [4], …
>
> It’s the first time I’m trying to organize an openstack/neutron
> meeting, so, I don’t know what’s the
> best way to do it, or find the best timeslot. I guess interested people
> may have a saying, so I’ve
> looped anybody I know is interested in the CC of this mail.
>

I think that's a good idea. Incidentally I was speaking with Sean regarding
Summit session [1], and we were hoping we could get some folks together
either prior or during the summit, to try and get some momentum going
behind this initiative, once again.

We'd need to fill in page [2], and find an empty slot on [3]

Thanks for starting this thread!

[1]
https://openstacksummitmay2015vancouver.sched.org/event/27eeef71d5f57997ac09b4c7783c72fe#.VSMIzJT-NhM

[2] https://wiki.openstack.org/wiki/NeutronSubTeams
[3] https://wiki.openstack.org/wiki/Meetings



>
> Miguel Ángel Ajo
>
> [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api
> [2]
> https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing
> [3]
> https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231
> [4]
> https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification
>
> __
> 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] [heat][ceilometer]: scale up/ down based on number of instances in a group

2015-04-06 Thread Angus Salkeld

On Fri, Apr 3, 2015 at 8:51 PM, Daniel Comnea  wrote:

> Hi all,
>
> Does anyone know if the above use case has made it into the convergence
> project and in which release was/ is going to be merged?
>
>
Hi

Phase one of convergence should be merged in early L (we have some of the
patches merged now).
Phase two is to separate the "checking" of actual state into a new RPC
service within Heat.
Then you *could* run that checker periodically (or receive RPC
notifications) to learn of changes
to the stack's state during the lifetime of the stack. That *might* get
done in L - we will just have to see
how things go.

-Angus


> Thanks,
> Dani
>
> On Tue, Oct 28, 2014 at 5:40 PM, Daniel Comnea 
> wrote:
>
>> Thanks all for reply.
>>
>> I have spoke with Qiming and @Shardy (IRC nickname) and they confirmed
>> this is not possible as of today. Someone else - sorry i forgot his nicname
>> on IRC suggested to write a Ceilometer query to count the number of
>> instances but what @ZhiQiang said is true and this is what we have seen via
>> the instance sample
>>
>> *@Clint - *that is the case indeed
>>
>> *@ZhiQiang* - what do you mean by "*count of resource should be queried
>> from specific service's API*"? Is it related to Ceilometer's event types
>> configuration?
>>
>> *@Mike - *my use case is very simple: i have a group of instances and in
>> case the # of instances reach the minimum number i set, i would like a new
>> instance to be spun up - think like a cluster where i want to maintain a
>> minimum number of members
>>
>> With regards to the proposal you made -
>> https://review.openstack.org/#/c/127884/ that works but only in a
>> specific use case hence is not generic because the assumption is that my
>> instances are hooked behind a LBaaS which is not always the case.
>>
>> Looking forward to see the 'convergence' in action.
>>
>>
>> Cheers,
>> Dani
>>
>> On Tue, Oct 28, 2014 at 3:06 AM, Mike Spreitzer 
>> wrote:
>>
>>> Daniel Comnea  wrote on 10/27/2014 07:16:32 AM:
>>>
>>> > Yes i did but if you look at this example
>>> >
>>> >
>>> https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml
>>> >
>>>
>>> > the flow is simple:
>>>
>>> > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy"
>>> > which then triggers the "type: OS::Heat::AutoScalingGroup"
>>>
>>> Actually the ScalingPolicy does not "trigger" the ASG.  BTW,
>>> "ScalingPolicy" is mis-named; it is not a full policy, it is only an action
>>> (the condition part is missing --- as you noted, that is in the Ceilometer
>>> alarm).  The so-called ScalingPolicy does the action itself when
>>> triggered.  But it respects your configured min and max size.
>>>
>>> What are you concerned about making your scaling group smaller than your
>>> configured minimum?  Just checking here that there is not a
>>> misunderstanding.
>>>
>>> As Clint noted, there is a large-scale effort underway to make Heat
>>> maintain what it creates despite deletion of the underlying resources.
>>>
>>> There is also a small-scale effort underway to make ASGs recover from
>>> members stopping proper functioning for whatever reason.  See
>>> https://review.openstack.org/#/c/127884/ for a proposed interface and
>>> initial implementation.
>>>
>>> Regards,
>>> Mike
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> 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] [Heat][Horizon] What we can do for Heat in Horizon else?

On 07/04/15 10:09, Fox, Kevin M wrote:
Would that be better done as part of the glance artifact work? You 
could upload multiple files as an artifact, then launch the templates 
from the artifact. May need some of the same ui bits, but not specific 
to heat.

That would be good too, but it would still be desirable for a user to 
launch a template from a local file, even when it references other local 
files (without having to go through an artifact repository).

*
*

*From:* Steve Baker
*Sent:* Monday, April 06, 2015 2:36:07 PM
*To:* openstack-dev@lists.openstack.org
*Subject:* Re: [openstack-dev] [Heat][Horizon] What we can do for Heat 
in Horizon else?

On 02/04/15 21:55, Sergey Kraynev wrote:
> Hi community.
>
> I want to ask feedback from our Heat team and also involve Horizon
> team in this discussion.
> AFAIK during Kilo was implemented bp:
> https://blueprints.launchpad.net/horizon/+spec/heat-ui-improvement
>
> This bp add more base Heat functionality to Horizon.
> I asked some ideas from Heat guys. What we want to have here else ?
>
> There is only one idea for me about topology:
> create some filters for displaying only particular resources (by their
> type)
> F.e. stack has 50 resources, but there is half of them network 
resources.

> As user I want to see only network level, so I enable filtering by
> network resources.
>
>
>
Horizon can't launch stacks when the templates do file inclusion via
get_file or type inclusion. There was an effort a while ago to build a
stack-create workflow which introspected the template/env and prompted
for the required files but it wasn't completed.

Something I want to discuss in Vancouver is whether we should consider
supporting an archive format for packaging templates/environments/files
into a single file. The REST API would *not* support this archive format
so it would be up to the "client" (horizon server or heat CLI) to unpack
the archive before calling stack-create.

Something which solves multi-file horizon stack-create would be my No.1
feature request.

__
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] [TripleO][Heat] Overcloud software updates and ResourceGroups

2015-04-06 Thread Zane Bitter


On 03/04/15 01:29, Giulio Fidente wrote:

hi there,

thanks for sharing this, I have a

On 04/03/2015 12:31 AM, Zane Bitter wrote:

A few of us have been looking for a way to perform software updates to
servers in a TripleO Heat/Puppet-based overcloud


[...]


Here's a trivial example of what this deployment might look like:

   update_config:
 type: OS::Heat::SoftwareConfig
 properties:
   config: {get_file: do_sw_update.sh}
   inputs:
 - name: update_after_time
   description: Timestamp of the most recent update request

   update_deployment:
 type: OS::Heat::SoftwareDeployment
 properties:
   actions:
 - UPDATE
   config: {get_resource: update_config}
   server: {get_resource: my_server}
   input_values:
 update_after_time: {get_param: update_timestamp}


[...]


   heat stack-update my_overcloud -f $TMPL -P "update_timestamp=$(date)"


leaving the ResourceGroup/AutoScalingGroup to more knowledgeable people
on a side and trying instead to translate the templating approach into
user features, if I read it correctly this would also make it possible to:

1. perform a config update without a software update as long as the
update_timestamp param remains unchanged

2. perform software updates of each ResourceGroup independently from the
others by using as many update_timestamp params

3. use different update.sh scripts per ResourceGroup

are the above correct?


Yes, right on for all 3.


My single minor concern is about the update script itself which, if not
left for editing to the user but bundled instead with t-h-t , should be
clever enough to cope with different distros and distro versions because
we can't know that from the template ... but this can be achieved by
abstracting it on top of Puppet itself it seems (or whichever other
config management tool is deployed)


I picture it as a distro-specific thing that we might configure in the 
Heat environment (maybe using get_file as in the example above). 
Alternatively, I guess we could try to write a multi-platform script, 
but I'm not sure _any_ of the distros would actually thank us ;)


- ZB

__
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][Horizon] What we can do for Heat in Horizon else?

2015-04-06 Thread Fox, Kevin M

Would that be better done as part of the glance artifact work? You could upload 
multiple files as an artifact, then launch the templates from the artifact. May 
need some of the same ui bits, but not specific to heat.

Thanks,
Kevin

From: Steve Baker
Sent: Monday, April 06, 2015 2:36:07 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat][Horizon] What we can do for Heat in Horizon 
else?

On 02/04/15 21:55, Sergey Kraynev wrote:
> Hi community.
>
> I want to ask feedback from our Heat team and also involve Horizon
> team in this discussion.
> AFAIK during Kilo was implemented bp:
> https://blueprints.launchpad.net/horizon/+spec/heat-ui-improvement
>
> This bp add more base Heat functionality to Horizon.
> I asked some ideas from Heat guys. What we want to have here else ?
>
> There is only one idea for me about topology:
> create some filters for displaying only particular resources (by their
> type)
> F.e. stack has 50 resources, but there is half of them network resources.
> As user I want to see only network level, so I enable filtering by
> network resources.
>
>
>
Horizon can't launch stacks when the templates do file inclusion via
get_file or type inclusion. There was an effort a while ago to build a
stack-create workflow which introspected the template/env and prompted
for the required files but it wasn't completed.

Something I want to discuss in Vancouver is whether we should consider
supporting an archive format for packaging templates/environments/files
into a single file. The REST API would *not* support this archive format
so it would be up to the "client" (horizon server or heat CLI) to unpack
the archive before calling stack-create.

Something which solves multi-file horizon stack-create would be my No.1
feature request.

__
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] cinder[stable/juno] Fix the eqlx driver to retry on ssh timeout(Backport)


Rajini,

This is a relatively small change.

Mike, what do you think about granting an Exception for this?

Jay

On 04/06/2015 04:33 PM, rajini_...@dell.com wrote:


*Dell - Internal Use - Confidential *

Hi

Can we have a  freeze exception on this CR pl?

https://review.openstack.org/154123

Closes-Bug: #1412940    and #1417772

When the ssh session is timing out, the driver
should make attempts to retry based on the value
in eqlx_cli_max_retries. Instead it was raising
the exception and bailing out on a single attempt.

Thanks

*Rajini Ram*

*IRC: rajinir*



__
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] [TripleO][Heat] Overcloud software updates and ResourceGroups

2015-04-06 Thread Zane Bitter


On 02/04/15 20:31, Fox, Kevin M wrote:

I'm not sure how to feel about this... Its clever...


That's... unfortunate ;)

Ideally this would sound like something that is a natural fit for Heat's 
data model. The reason it's not is that config management tools like 
Puppet are less sophisticated than Heat in terms of their modelling - 
they only model the things that you want to change, and there's no way 
to reverse a change.


That's not really a criticism of Puppet, it's kind of inevitable that 
you can't represent the full complexity of a modern Linux system. 
TripleO initially tried to get around this by doing image replacement 
only, but it turns out that's too heavyweight to be practical. The real 
long-term fix, at least for the application part of a deployment, is 
most likely containers. However, we need to wait for the Kolla project 
to become mature before we can deploy OpenStack using containers in TripleO.



I started to respond to the rest of your comments, but I decided not to 
do so here, because this thread is about what we can/should do right 
now, for TripleO, in Kilo, with Heat already in feature freeze.


cheers,
Zane.

__
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] [Documentation] Not running for Doc PTL

2015-04-06 Thread Lana Brindley

Thanks for all the hand holding you’ve given me (and my team) as we’ve been 
ramping up. Your expertise and wisdom is worth a mint to us, and we’re really 
glad you’ll be sticking around. 

Thanks for everything you do.

Lana

On 7 Apr 2015, at 1:43 am, Anne Gentle  wrote:

> Hi all, 
> 
> I want to be sure you all know I don't plan to run for Documentation PTL. I 
> will certainly continue to provide leadership for documentation for 
> OpenStack. I would like to ensure continuity for documentation, by giving the 
> opportunity for more leaders to step up.
> 
> I'll be shifting focus to API design and documentation this release. Thanks 
> so much for letting me experiment with open source docs and learn so much 
> along the way. The docs team has done amazing work and will continue to do 
> so, with excellent examples of servant leadership throughout the team.
> 
> Thanks,
> Anne
> 
> -- 
> Anne Gentle
> annegen...@justwriteclick.com
> __
> 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

Lana Brindley
Technical Writer
Rackspace Cloud Builders 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] [tripleo][puppet] Running custom puppet manifests during overcloud post-deployment


On 03/04/15 04:52, Tzu-Mainn Chen wrote:


- Original Message -

On Thu, Apr 02, 2015 at 10:34:29AM -0400, Dan Prince wrote:

On Wed, 2015-04-01 at 21:31 -0400, Tzu-Mainn Chen wrote:

Hey all,

I've run into a requirement where it'd be useful if, as an end user, I
could inject
a personal ssh key onto all provisioned overcloud nodes.

Obviously this is something that not every user would need or want.  I
talked about
some options with Dan Prince on IRC, and (besides suggesting that I bring
the
discussion to the mailing list) he proposed some generic solutions - and
Dan, please
feel free to correct me if I misunderstood any of your ideas.

The first is to specify a pre-set custom puppet manifest to be run when
the Heat
stack is created by adding a post_deployment_customizations.pp puppet
manifest to
be run by all roles.  Users would simply override this manifest.

The second solution is essentially the same as the first, except we'd
perform
the override at the Heat resource registry level: the user would update
the
resource reference to point to a their custom manifest (rather than
overriding
the default post-deployment customization manifest).

Do either of these solutions seem acceptable to others?  Would one be
preferred?

Talking about this a bit more on IRC this morning we all realized that
Puppet isn't a hard requirement. Just simply providing a pluggable
mechanism to inject this sort of information into the nodes in a clean
way is all we need.

Steve Hardy's suggestion here is probably the cleanest way to support
this sort of configuration in a generic fashion.

https://review.openstack.org/170137

I don't believe this solution runs post deployment however. So if
running a hook post deployment is a requirement we may need to wire in a
similar generic config parameter for that as well.

No that's correct, this will only run when the initial node boot happens
and cloud-init runs, so it is pre-deployment only.

If we need post-deployment hooks too, then we could add a similar hook at
the end of *-post.yaml, which pulls in some deployer defined additional
post-deployment config to apply.

Steve

Post-deployment hooks would definitely be useful; one of the things we'd like
to do is create a user with very specific permissions on various openstack-
related files and executables.


Having a placeholder resource for custom user deployments is one option 
we could consider. Another option would be to add outputs into the 
overcloud template which expose the server IDs of all the resource group 
members. Something like:


outputs:
  ComputeServers:
value: {get_attr: [Compute, attributes, nova_server_resource]}
  ...

This would allow the user to define their own standalone stacks which 
create deployments for those servers. These stacks would have their own 
user-controlled lifecycle, and it would be up to the user to re-run 
stack-update on these stacks after the overcloud scales.




__
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] Fwd: [stable] Request stable freeze exception: 162112 and 162113 libvirt live migration progress & loop

2015-04-06 Thread David Medberry

Change requests https://review.openstack.org/162113 and
https://review.openstack.org/16211 2
are effecting a lot of operators (any who perform live migration) in Juno

Request stable/juno freeze exception to get these two added.

David Medberry
__
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][Horizon] What we can do for Heat in Horizon else?


On 02/04/15 21:55, Sergey Kraynev wrote:

Hi community.

I want to ask feedback from our Heat team and also involve Horizon 
team in this discussion.

AFAIK during Kilo was implemented bp:
https://blueprints.launchpad.net/horizon/+spec/heat-ui-improvement

This bp add more base Heat functionality to Horizon.
I asked some ideas from Heat guys. What we want to have here else ?

There is only one idea for me about topology:
create some filters for displaying only particular resources (by their 
type)

F.e. stack has 50 resources, but there is half of them network resources.
As user I want to see only network level, so I enable filtering by 
network resources.




Horizon can't launch stacks when the templates do file inclusion via 
get_file or type inclusion. There was an effort a while ago to build a 
stack-create workflow which introspected the template/env and prompted 
for the required files but it wasn't completed.


Something I want to discuss in Vancouver is whether we should consider 
supporting an archive format for packaging templates/environments/files 
into a single file. The REST API would *not* support this archive format 
so it would be up to the "client" (horizon server or heat CLI) to unpack 
the archive before calling stack-create.


Something which solves multi-file horizon stack-create would be my No.1 
feature request.


__
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] cinder[stable/juno] Fix the eqlx driver to retry on ssh timeout(Backport)

2015-04-06 Thread Rajini_Ram

Dell - Internal Use - Confidential
Hi

Can we have a  freeze exception on this CR pl?

https://review.openstack.org/154123

Closes-Bug: #1412940 and #1417772



When the ssh session is timing out, the driver
should make attempts to retry based on the value
in eqlx_cli_max_retries. Instead it was raising
the exception and bailing out on a single attempt.

Thanks

Rajini Ram
IRC: rajinir
__
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] [Mistral] Propose Winson Chan m4dcoder for core team

2015-04-06 Thread Dmitri Zimine

Hi folks, 

I’d like to propose Winson Chan (m4dcoder) to become Mistral core team member. 

Winson brings unique mix of field experience implementing Mistral workflows in 
user environments, and solid development skills. 

He has been contributing to Mistral since Mar 2014. Winson did a 23 commits - a 
number of them are non-trivial, like moving RPC to oslo-messaging, or 
introducing environments, or making full validation. He has submitted 14 
blueprints and detailed design proposals, contributing to design and 
directions. He found, reported, and fixed bugs. He is becoming more active on 
the review board (would encourage to do more). 

I am +1 for m4dcoder as a core team member. 

DZ.





__
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] [Congress] PTL candidacy

2015-04-06 Thread Tim Hinrichs

Hi all,

I'm writing to announce my candidacy for PTL of Congress for the Liberty cycle. 
 We've made a lot of progress in Kilo, and I'm excited by what we'll achieve in 
Liberty!  To give us some perspective, I compiled a (partial) list of 
improvements we made in Kilo:

* Officially became part of OpenStack (moved from stackforge to openstack)
* Matured the Congress community (commits/LOC from outside VMware: Juno:8%, 
Kilo:26%)
* Integrated with our first external project: Murano
* Improved scale-up by orders of magnitude (see 
http://ruleyourcloud.com/2015/03/12/scaling-up-congress.html)
* Added the first version of reactive enforcement (correcting policy violations 
after they happen)
* Created a Horizon GUI for writing policy
* Built a DSL for integrating external cloud services and enabled on-demand 
(de)installation of services

We achieved just about everything we set out to do in Kilo, thanks to the hard 
work of many outstanding folks.  For the Liberty cycle, I'm planning on similar 
success in the following areas.

* Production deployments
* Scale-out: enabling high-availability and increased throughput
* Delegation: enabling Congress to interoperate with other policy engines to 
share the burden of policy enforcement
* Community: increasing non-VMware contributions, in terms of commits/LOC and 
especially reviews

While Congress is an early-stage project, we're on a great track, and I'll make 
sure we stay on it.  As always I'm happy to chat about future directions, past 
progress, and anything in between.

Thanks!
Tim

__
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-Infra][cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)

2015-04-06 Thread Diem Tran

Hi Mike,

Thank you for re-integrating our NFS Cinder driver back in Kilo RC. We
appreciate your support.

We would like you to re-consider our iSCSI Cinder driver as well. We
have some results already posted:

https://review.openstack.org/#/c/159856/
https://review.openstack.org/#/c/166422/

The CI system is up and running and should continuously test and post
results from now on. We had network issues so only the CI for NFS driver
was reporting, but now we have set up a new infrastructure which will be
more stable. We really appreciate you considering ZFSSA iSCSI Cinder
driver to be part of Kilo RC.

Thank you,
Diem.

On 04/06/2015 01:43 AM, Mike Perez wrote:

On 18:20 Mon 23 Mar , Diem Tran wrote:

Hello Cinder team,

Oracle ZFSSA CI has been reporting since March 20th. Below is a link
to the list of results the CI already posted:

https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z

Our CI system will be running and reporting results from now on,
hence I kindly request that you accept our CI results and consider
re-integrating our drivers back in Kilo RC.

If there is any concern, please let us know.

Patch is up to revert the removal.

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

Since this CI only covers ZFSSANFSDriver and not also the ZFSSAISCSIDriver, we
won't be able to add back in iscsi driver this release.

https://review.openstack.org/#/c/169283/
http://ec2-54-149-113-183.us-west-2.compute.amazonaws.com/ci_results/refs-changes-83-169283-1-nfs/logs/etc/cinder/cinder.conf

__
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] [cinder] Current Status of IBM 3rd Party CI Testing ...

2015-04-06 Thread Anita Kuno

On 04/06/2015 04:28 PM, Jay S. Bryant wrote:
> Anita,
> 
> My apologies.  The original communication on the issue came from Mike
> via the mailing list so I was attempting to continue the public
> discussion here.
> 
> I will make sure to not do this in the future.
> 
> Jay
I appreciate your understanding and prompt response, Jay. I thank you.

As we just discussed in channel with Mike it looks like Cinder meetings
might make some space for ci system updates for the next while including
helping folks to figure out how to create and update their account wikipage.

Thanks Jay,
Anita.

https://wiki.openstack.org/wiki/ThirdPartySystems
> 
> On 04/06/2015 03:19 PM, Anita Kuno wrote:
>> On 04/06/2015 04:03 PM, Jay S. Bryant wrote:
>>> All,
>>>
>>> I just wanted to provide an update on 3rd Party CI Testing for IBM's
>>> drivers.
>>>
>>> It was noted late last month that not all of IBM's drivers were running
>>> the required 304 test cases.  That issue has been resolved for all 3rd
>>> Party CI's except for DS8k.  The maintainer of that system has been out
>>> but returns this week.  I will work with him to ensure we get that
>>> problem resolved.
>>>
>>> While looking through results, I noticed that our CI's are still
>>> intermittently failing.  I will work with the CI maintainers on this.
>>>
>>> Jay
>>>
>>> __
>>>
>>> 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
>> Okay I can understand Huawei posting many many times to the mailing list
>> to get themselves sorted out, due to their complaints noone is available
>> for them in apac time (despite the fact that I personally have never
>> seen Liu in a third party meeting - every Tuesday 0800 utc in
>> #openstack-meeting) but folks are feeling pressured so I figured I would
>> give him/her a day or two to get themselves sorted out.
>>
>> However the expected place for CI account status updates is the wikipage
>> for third party systems and your individual account page:
>> https://wiki.openstack.org/wiki/ThirdPartySystems and link to your
>> system.
>>
>> Jay, (look of disapproval), don't make me come up there,
>> Anita.
>>
>> __
>>
>> 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] [Manila] PTL Candidacy

2015-04-06 Thread Ben Swartzlander


Hello all,

I'm announcing my candidacy for Manila PTL for the Liberty release.

I've been leading the Manila project since its inception back in 2013, 
and I'm excited and humbled by how much the community around the project 
has grown, especially during the last 6 months.


If you go back and read my ML post from my last nomination, I set out a 
number of goals [1]. I think we have achieved as a team everything on 
that list. In particular I am most excited by the growth of the 
community, which has exceeded my hopes.


Manila quality has come a long way, with greatly increased test 
coverage, and a significant number of bugs found a fixed. The primary 
technical goal for Kilo, which was to make Manila usable in a wider 
variety of deployment scenarios was met with our new 
driver_handle_share_servers config flag and multiple network plugin options.


The thing that caught me most by surprise was how popular the mid-cycle 
meetup was. I made the mistake of assuming that it would be a small 
group and that there wouldn't be interest in a physical meetup. The 
meetup was well attended and a lot of great ideas came out of it. I want 
to make sure we plan ahead for the Liberty meetup so people who are able 
to travel have time to make plans, and I'd like to make the agenda more 
formal next time around so people joining remotely can schedule their 
time more effectively.


I have a long list of technical content that I would like to see go into 
Liberty. The mid-cycle meetup added a bunch of new ideas, and there's 
still a big gap between what Manila can support and what Cinder (the 
project we forked from) now supports. I would like to catch up to 
Cinder, feature-wise, and also implement all of the 
shared-file-system-specific features we've been talking about but 
haven't gotten around to implementing yet (mount automation is a big one).


There is way more work than we can get done during a single release, but 
with a bigger team I'm hopeful that we can deliver more features in 
Liberty than ever before. To this end I've been trying to grow the core 
team, with 2 recent additions, and I hope to grow it more.


To address the concern that too many core team members are from a small 
number of companies, I'd like to propose a rule that changes require +2s 
from at least 2 companies, which should alleviate concerns about single 
companies shoving through unpopular changes, and I can also guarantee 
that the next core team nominations from me will be for people from 
companies not yet represented.


I wish I could include my proposed list of Liberty features here, but 
unfortunately it's too long and not baked enough because we haven't 
quite finished Kilo enough to move on to Liberty planning (for me at 
least). I want to continue the themes we started in Kilo of quality, 
simplicity, and integrating with the rest of OpenStack. Look forward to 
my list of proposed features in the coming weeks and let's make Liberty 
the best release of Manila ever!


[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/047045.html


-Ben Swartzlander

__
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] [cinder] Current Status of IBM 3rd Party CI Testing ...


Anita,

My apologies.  The original communication on the issue came from Mike 
via the mailing list so I was attempting to continue the public 
discussion here.


I will make sure to not do this in the future.

Jay

On 04/06/2015 03:19 PM, Anita Kuno wrote:

On 04/06/2015 04:03 PM, Jay S. Bryant wrote:

All,

I just wanted to provide an update on 3rd Party CI Testing for IBM's
drivers.

It was noted late last month that not all of IBM's drivers were running
the required 304 test cases.  That issue has been resolved for all 3rd
Party CI's except for DS8k.  The maintainer of that system has been out
but returns this week.  I will work with him to ensure we get that
problem resolved.

While looking through results, I noticed that our CI's are still
intermittently failing.  I will work with the CI maintainers on this.

Jay

__
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

Okay I can understand Huawei posting many many times to the mailing list
to get themselves sorted out, due to their complaints noone is available
for them in apac time (despite the fact that I personally have never
seen Liu in a third party meeting - every Tuesday 0800 utc in
#openstack-meeting) but folks are feeling pressured so I figured I would
give him/her a day or two to get themselves sorted out.

However the expected place for CI account status updates is the wikipage
for third party systems and your individual account page:
https://wiki.openstack.org/wiki/ThirdPartySystems and link to your system.

Jay, (look of disapproval), don't make me come up there,
Anita.

__
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] [qa] [devstack] Confusion about member roles in tempest/devstack

2015-04-06 Thread David Kranz


On 04/06/2015 03:14 PM, Matthew Treinish wrote:

On Mon, Apr 06, 2015 at 02:25:14PM -0400, David Kranz wrote:

There have been a number of changes in tempest recently that seem to
coordinate with devstack that are a bit unclear.

Well, the issue was that before tempest was making all sorts of incorrect
implicit assumptions about the underlying configuration. As part of the test
accounts part 2 bp [1] we needed to correct these and make things more explicit
which resulted in a number of changes around the configuration in tempest.

FWIW, I push to have detailed commit messages to try and make it clear from the
git log and explain the rationale behind changes like this.


The following values are defined in tempest config as defaults:

[auth]
# Roles to assign to all users created by tempest (list value)
#tempest_roles =

So this option is used to set roles on every user created by tenant isolation.
Outside of tenant isolation this option does nothing.


[object-storage]
# Role to add to users created for swift tests to enable creating
# containers (string value)
#operator_role = Member

[orchestration]
# Role required for users to be able to manage stacks (string value)
#stack_owner_role = heat_stack_owner

These are the values created in tempest.conf by devstack:

[auth]

tempest_roles = Member


[orchestration]
stack_owner_role = _member_

So a couple of questions.

Why do we have Member and _member_, and what is the difference supposed to
be?

IIRC _member_ is the default role with keystone v3 which is used to show
membership in a project. I'm sure Jamie or Morgan will correct me if I'm wrong
on this.


Experimentally, it seems that the tempest roles cannot be empty, so why is
that the default?

So, I'm surprised by this, the tests which require the role Member to be set on
the created users should be specifically requesting this now. (as part of the
test accounts bp we had to make these expectations explicit) It should only be
required for the swift tests that do container manipulation.[2] I'm curious to
see what you're hitting here. The one thing is from the git log there may be
an interaction here depending on the keystone api version you're using. [3] My
guess is that it's needed for using keystone v2 in a v3 env, or vice versa, but
I'm sure Andrea will chime in if this is wrong.
Seems right to me. I should have said it is the identity v3 tests that 
fail if you leave the default for tempest_roles. It does seem that 
Member is related to swift tests and it would be less confusing if this 
were called SwiftOperator instead of Member. The only hardcoded 
reference to Member in tempest now is in javelin and that is going to be 
removed https://review.openstack.org/#/c/169108/


Andrea, can you explain why the role that is required in the 
tempest_roles is Member?
If this is really the way it needs to be we should have this as the 
default in tempest.conf rather than having devstack always set it, no?


 -David





The heat_stack_owner role used to be created in juno devstack but no longer.
Is there a reason to leave this as the default?

IIRC, the use of explicit role was removed in kilo (and maybe backported into
juno?) and was replaced with the use of delegations. It removed the need for
an explicit role to manipulate heat stacks. The config option is necessary
because of branchless tempest considerations and that you might need a specific
role to perform stack operations. [4][5] The use of _member_ on master is to
indicate that the no special role is needed to perform stack operations. When
icehouse support goes eol we probably can remove this option from tempest.

-Matt Treinish

[1] 
http://specs.openstack.org/openstack/qa-specs/specs/test-accounts-continued.html
[2] 
http://git.openstack.org/cgit/openstack/tempest/commit/?id=8f26829e939a695732cd5a242dddf63a9a84ecb8
[3] 
http://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=72f026b60d350ede39e22e08b8f7f286fd0d2633
[4] 
http://git.openstack.org/cgit/openstack/tempest/commit/?id=db9721dfecd99421f89ca9e263a97271e5f79ca0
[5] 
http://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=886cbb2a86e475a7982df1d98ea8452d0f9873fd


__
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] [cinder] Report Status of Microsoft iSCSI CI

2015-04-06 Thread Anita Kuno

On 04/06/2015 04:14 PM, Octavian Ciuhandu wrote:
> Hello Cinder team,
> 
> Please find below CI reports for the Microsoft iSCSI CI. It executes 304 
> tests, out if which 9 are skipped and 295 successful.
> 
> https://review.openstack.org/#/c/144409/
> https://review.openstack.org/#/c/144739/
> https://review.openstack.org/#/c/154350/
> https://review.openstack.org/#/c/155607/
> https://review.openstack.org/#/c/161328/
> https://review.openstack.org/#/c/161363/
> https://review.openstack.org/#/c/161400/
> https://review.openstack.org/#/c/162927/
> https://review.openstack.org/#/c/163232/
> https://review.openstack.org/#/c/163910/
> https://review.openstack.org/#/c/164527/
> https://review.openstack.org/#/c/166066/
> https://review.openstack.org/#/c/166164/
> https://review.openstack.org/#/c/167978/
> https://review.openstack.org/#/c/169653/
> https://review.openstack.org/#/c/169781/
> https://review.openstack.org/#/c/169831/
> https://review.openstack.org/#/c/169915/
> https://review.openstack.org/#/c/16/
> https://review.openstack.org/#/c/17/
> https://review.openstack.org/#/c/170770/ 
> 
> We are constantly looking at the CI status and try to respond as soon as 
> possible to any failure, to ensure the CI stability.
> 
> If there is any issue with the CI or with the reporting, please let us know.
> 
> Thank you,
> 
> Octavian.
> 
> 
> 
> __
> 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
> 
No we are not doing this people.

We are not having every single CI account post their status to the
mailing list.

Anita.

__
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] [cinder] Current Status of IBM 3rd Party CI Testing ...

2015-04-06 Thread Anita Kuno

On 04/06/2015 04:03 PM, Jay S. Bryant wrote:
> All,
> 
> I just wanted to provide an update on 3rd Party CI Testing for IBM's
> drivers.
> 
> It was noted late last month that not all of IBM's drivers were running
> the required 304 test cases.  That issue has been resolved for all 3rd
> Party CI's except for DS8k.  The maintainer of that system has been out
> but returns this week.  I will work with him to ensure we get that
> problem resolved.
> 
> While looking through results, I noticed that our CI's are still
> intermittently failing.  I will work with the CI maintainers on this.
> 
> Jay
> 
> __
> 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
Okay I can understand Huawei posting many many times to the mailing list
to get themselves sorted out, due to their complaints noone is available
for them in apac time (despite the fact that I personally have never
seen Liu in a third party meeting - every Tuesday 0800 utc in
#openstack-meeting) but folks are feeling pressured so I figured I would
give him/her a day or two to get themselves sorted out.

However the expected place for CI account status updates is the wikipage
for third party systems and your individual account page:
https://wiki.openstack.org/wiki/ThirdPartySystems and link to your system.

Jay, (look of disapproval), don't make me come up there,
Anita.

__
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] [cinder] Report Status of Microsoft iSCSI CI

2015-04-06 Thread Octavian Ciuhandu

Hello Cinder team,

Please find below CI reports for the Microsoft iSCSI CI. It executes 304 tests, 
out if which 9 are skipped and 295 successful.

https://review.openstack.org/#/c/144409/
https://review.openstack.org/#/c/144739/
https://review.openstack.org/#/c/154350/
https://review.openstack.org/#/c/155607/
https://review.openstack.org/#/c/161328/
https://review.openstack.org/#/c/161363/
https://review.openstack.org/#/c/161400/
https://review.openstack.org/#/c/162927/
https://review.openstack.org/#/c/163232/
https://review.openstack.org/#/c/163910/
https://review.openstack.org/#/c/164527/
https://review.openstack.org/#/c/166066/
https://review.openstack.org/#/c/166164/
https://review.openstack.org/#/c/167978/
https://review.openstack.org/#/c/169653/
https://review.openstack.org/#/c/169781/
https://review.openstack.org/#/c/169831/
https://review.openstack.org/#/c/169915/
https://review.openstack.org/#/c/16/
https://review.openstack.org/#/c/17/
https://review.openstack.org/#/c/170770/ 

We are constantly looking at the CI status and try to respond as soon as 
possible to any failure, to ensure the CI stability.

If there is any issue with the CI or with the reporting, please let us know.

Thank you,

Octavian.

smime.p7s
Description: S/MIME cryptographic 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] [cinder] Current Status of IBM 3rd Party CI Testing ...


All,

I just wanted to provide an update on 3rd Party CI Testing for IBM's 
drivers.


It was noted late last month that not all of IBM's drivers were running 
the required 304 test cases.  That issue has been resolved for all 3rd 
Party CI's except for DS8k.  The maintainer of that system has been out 
but returns this week.  I will work with him to ensure we get that 
problem resolved.


While looking through results, I noticed that our CI's are still 
intermittently failing.  I will work with the CI maintainers on this.


Jay

__
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] Liberty mid-cycle coding sprint

2015-04-06 Thread Kyle Mestery

I know we're not even at the Liberty Design Summit in Vancouver yet, but I
wanted to take this time to announce the Neutron mid-cycle coding sprint
for Liberty. HP has been gracious enough to offer to host at it's Fort
Collins, CO offices. The dates are set for June 24-26, this is
Wednesday-Friday. I've got additional information on the etherpad [1].

We'll set the specific agenda in the coming weeks, but the idea is to focus
on things like the pending neutron-lib work [2] while there, similar to
what we did with the advanced services split in Utah last year. My
experience running the past two mid-cycles has been that having these
earlier in the cycle has been helpful for landing a lot of work near the
first milestone of a release. I expect this to be the same for Liberty with
the sprint in Fort Collins.

Please note attendance is not required at all. We will do our best to
facilitate virtual collaboration for those who cannot travel to the event.
I wanted to get this out there for folks who have to book travel in advance.

Thanks!
Kyle

[1] https://etherpad.openstack.org/p/neutron-liberty-mid-cycle
[2] https://review.openstack.org/#/c/154736/
__
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] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

2015-04-06 Thread Mike Bayer

On 4/6/15 2:52 PM, Morgan Fainberg wrote:

On Apr 6, 2015, at 11:41, Mike Bayer > wrote:

On 4/6/15 12:49 PM, David Stanek wrote:

Exactly. This is the direction I have been going. Functional tests 
are written using the public APIs using the client.

I would also add that I don't like that the Keystone unit tests are 
so database heavy. I would not want MySQL or ant RDBMS to be a 
requirement for running the tests.

is that because you'd prefer that the unit tests were more isolated, 
or just that an external service is being used?

I've done some work with extensive mocking of SQL databases; 
specifically mocking at the ORM level.  It is nice when you get it to 
run, but it's also a much bigger job to write fine-grained mocks like 
that, the mocks can be brittle in relation to the code they're 
targeting, and you also need to come up with some solution to 
actually functional test your database access code.

I tend to think that having a mysqld service running is the lesser of 
two evils and you get a lot more code coverage by going all the way 
out to the DB.

What David is specifically referencing is that we want our functional 
tests to only require direct API access. There is almost no reason to 
need access to the DB backend. We have many ways to perform isolation 
where needed (tempest does a lot of this today).

The goal is to allow the functional test suite to run against any 
keystone deployment (be agnostic to db, non-db, etc driver used). This 
makes environment setup a separate concern the tests don't need to be 
involved in/aware of. It makes our functional tests more useful for 
validating a driver or configuration passes muster.

ah.  for sure.  I would think functional tests could run against a 
backend that was entirely mock / file-based.

If there are legitimately cases we need to test a specific db function 
in isolation we will make specific efforts to support it. Those are 
apt to be the exception to the rule.

--Morgan
Sent via mobile

On Mon, Apr 6, 2015, 12:42 Morgan Fainberg 
mailto:morgan.fainb...@gmail.com>> wrote:

> On Apr 6, 2015, at 09:20, Mike Bayer  wrote:
>
>
>
>> On 4/6/15 12:06 PM, Clint Byrum wrote:
>> Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08
-0700:
 On Saturday 04 April 2015 03:55:59 Morgan Fainberg wrote:
 I am looking forward to the Liberty cycle and seeing the
special casing we
 do for SQLite in our migrations (and elsewhere). My
inclination is that we
 should (similar to the deprecation of eventlet) deprecate
support for
 SQLite in Keystone. In Liberty we will have a full
functional test suite
 that can (and will) be used to validate everything against
much more real
 environments instead of in-process “eventlet-like”
test-keystone-services;
 the “Restful test cases” will no longer be part of the
standard unit tests
 (as they are functional testing). With this change I’m
inclined to say
 SQLite (being the non-production usable DB) what it is we
should look at
 dropping migration support for SQLite and the custom
work-arounds.

 Most deployers and developers (as far as I know) use
devstack and MySQL or
 Postgres to really suss out DB interactions.

 I am looking for feedback from the community on the general
stance for
 SQLite, and more specifically the benefit (if any) of
supporting it in
 Keystone.
>>> +1. Drop it and clean up tons of code used for support of
sqlite only.
>>>
>>> Doing tests with mysql is as easy, as with sqlite
("mysqladmin drop -f;
>>> mysqladmin create" for "reset"), and using it by default
will finally make
>>> people test their code on real rdbmses.
>> Please please please be careful with that and make sure the
database
>> name is _always_ random in tests... or even better, write a
fixture to
>> spin up a mysqld inside a private tempdir. That would be a
really cool
>> thing for oslo.db to provide actually.
>>
>> I'm just thinking some poor sap runs the test suite with the
wrong
>> .my.cnf in the wrong place and  there went keystone's db.
> The standard approach here is that tests based on the oslo.db
approach by default connect using a username openstack_citest on
localhost, which is then used to create databases of random
names. If you base your database tests on oslo.db, you get that
right now.  This username/host/etc is also configurable through
environment variables.  I don't see how my.cnf is involved in
this nor how it would impact someone's keystone database, unless
we're talking about tests that happen to load down and/or crash
the whole database server.
>
> spinning up a whole mysqld seems really heavy-handed and
un

Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

2015-04-06 Thread David Stanek

On Mon, Apr 6, 2015 at 2:41 PM, Mike Bayer  wrote:

>
>
> On 4/6/15 12:49 PM, David Stanek wrote:
>
> Exactly. This is the direction I have been going. Functional tests are
> written using the public APIs using the client.
>
> I would also add that I don't like that the Keystone unit tests are so
> database heavy. I would not want MySQL or ant RDBMS to be a requirement for
> running the tests.
>
> is that because you'd prefer that the unit tests were more isolated, or
> just that an external service is being used?
>

There are two types of testing that I'm interested in really promoting in
Keystone. I want to see functional tests that only use the published APIs
to trigger and observe behavior. I also want to see unit tests that are
small, fast and that test the business logic of the system.

I started working[1] on functional testing in the Kilo cycle. The spec[2]
talks about standing up Keystone in different configurations (MySQL, LDAP,
Federated, etc.) and then running a set of tests against that instance.
This will allow us the test any backend we want and confirm it works the
way we expect Keystone to work.

On the other hand I want the unit tests to be smaller and faster. The job
of the unit tests should be to test small isolated bits of code and help
guide/evaluate the code design. Except to test the SQL backends I don't see
a need for using a database and even then I'd like to get by without it.

> I've done some work with extensive mocking of SQL databases; specifically
> mocking at the ORM level.  It is nice when you get it to run, but it's also
> a much bigger job to write fine-grained mocks like that, the mocks can be
> brittle in relation to the code they're targeting, and you also need to
> come up with some solution to actually functional test your database access
> code.
>
> I tend to think that having a mysqld service running is the lesser of two
> evils and you get a lot more code coverage by going all the way out to the
> DB.
>

The simplicity of the Keystone design is actually very good for dealing
with this (controller -> manager -> backend). Since backends are where the
actually query work happens we can easily provide a fake for each subsystem
that we want to test. This would allow us the test the business rules in
the manager without a database. The reason that is good is that we'd
probably be better off requiring LDAP (if anything) for some of the
subsystems since that is what they are typically configured to use. I would
rather just leave that level of detail to the functional tests.

1.
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:functonal-testing,n,z
2. https://review.openstack.org/#/c/153300/l

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
__
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] [TC] [Docs] [congress] [murano] [magnum] Newest projects and docs

2015-04-06 Thread Anne Gentle

Hi all,

I did get clarity from the OpenStack Foundation that publishing to
docs.openstack.org with our branded templates is fine for those projects
newly governed by the TC. Follow the brand guidelines at
http://www.openstack.org/brand if you want to use that content with an
OpenStack brand for your commercial product.

In another communication I will outline what I believe a team of 15 that
supports docs from over 20 projects can actually handle, and what content
and projects will be prioritized by a centralized team.

Please ask any questions on the openstack-docs mailing list or on IRC.
We're here to make OpenStack better for lots of groups through great docs.

Thanks,
Anne

-- 
Anne Gentle
annegen...@justwriteclick.com
__
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] [qa] [devstack] Confusion about member roles in tempest/devstack

2015-04-06 Thread Matthew Treinish

On Mon, Apr 06, 2015 at 02:25:14PM -0400, David Kranz wrote:
> There have been a number of changes in tempest recently that seem to
> coordinate with devstack that are a bit unclear.

Well, the issue was that before tempest was making all sorts of incorrect
implicit assumptions about the underlying configuration. As part of the test
accounts part 2 bp [1] we needed to correct these and make things more explicit
which resulted in a number of changes around the configuration in tempest.

FWIW, I push to have detailed commit messages to try and make it clear from the
git log and explain the rationale behind changes like this.

> 
> The following values are defined in tempest config as defaults:
> 
> [auth]
> # Roles to assign to all users created by tempest (list value)
> #tempest_roles =

So this option is used to set roles on every user created by tenant isolation.
Outside of tenant isolation this option does nothing.

> 
> [object-storage]
> # Role to add to users created for swift tests to enable creating
> # containers (string value)
> #operator_role = Member
> 
> [orchestration]
> # Role required for users to be able to manage stacks (string value)
> #stack_owner_role = heat_stack_owner
> 
> These are the values created in tempest.conf by devstack:
> 
> [auth]
> 
> tempest_roles = Member
> 
> 
> [orchestration]
> stack_owner_role = _member_
> 
> So a couple of questions.
> 
> Why do we have Member and _member_, and what is the difference supposed to
> be?

IIRC _member_ is the default role with keystone v3 which is used to show
membership in a project. I'm sure Jamie or Morgan will correct me if I'm wrong
on this.

> 
> Experimentally, it seems that the tempest roles cannot be empty, so why is
> that the default?

So, I'm surprised by this, the tests which require the role Member to be set on
the created users should be specifically requesting this now. (as part of the
test accounts bp we had to make these expectations explicit) It should only be
required for the swift tests that do container manipulation.[2] I'm curious to
see what you're hitting here. The one thing is from the git log there may be
an interaction here depending on the keystone api version you're using. [3] My
guess is that it's needed for using keystone v2 in a v3 env, or vice versa, but
I'm sure Andrea will chime in if this is wrong.

> 
> The heat_stack_owner role used to be created in juno devstack but no longer.
> Is there a reason to leave this as the default?

IIRC, the use of explicit role was removed in kilo (and maybe backported into
juno?) and was replaced with the use of delegations. It removed the need for
an explicit role to manipulate heat stacks. The config option is necessary
because of branchless tempest considerations and that you might need a specific
role to perform stack operations. [4][5] The use of _member_ on master is to
indicate that the no special role is needed to perform stack operations. When
icehouse support goes eol we probably can remove this option from tempest.

-Matt Treinish

[1] 
http://specs.openstack.org/openstack/qa-specs/specs/test-accounts-continued.html
[2] 
http://git.openstack.org/cgit/openstack/tempest/commit/?id=8f26829e939a695732cd5a242dddf63a9a84ecb8
[3] 
http://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=72f026b60d350ede39e22e08b8f7f286fd0d2633
[4] 
http://git.openstack.org/cgit/openstack/tempest/commit/?id=db9721dfecd99421f89ca9e263a97271e5f79ca0
[5] 
http://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=886cbb2a86e475a7982df1d98ea8452d0f9873fd

pgpJCyBU3LDCN.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] [TripleO] Liberty Summit Topics etherpad

2015-04-06 Thread James Slagle

I've created an etherpad for for TripleO to track the topics we'd like
to discuss at the Liberty Summit:
https://etherpad.openstack.org/p/tripleo-liberty-proposed-sessions

It's also linked from the main Design Summit Planning wiki page:
https://wiki.openstack.org/wiki/Design_Summit/Planning

If you have something you'd like to propose to discuss, please add it
to the etherpad.

Thanks

-- 
-- James Slagle
--

__
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] Host maintenance notification


On 04/06/2015 12:52 PM, Matthew Treinish wrote:

On Mon, Apr 06, 2015 at 01:17:20PM -0500, Matt Riedemann wrote:

On 4/6/2015 9:46 AM, Chris Friesen wrote:

On 04/06/2015 07:56 AM, Ed Leafe wrote:

On Apr 6, 2015, at 1:21 AM, Chris Friesen 
wrote:


Please feel free to add a blueprint in Launchpad. I don't see this as
needing a full spec, really. It shouldn't be more than a few lines of
code to send a new notification message.


Wouldn't a new notification message count as an API change?  Or are we
saying that it's such a small API change that any discussion can
happen in
the blueprint?


I don't think that the notification system is the same as the API. It is
something that you can subscribe to or not, and is distinct from the API.


It's certainly not the same as the REST API.  I think an argument could
be made that the notification system is part of the API, where API is
defined more generally as "something that expresses a software component
in terms of its operations, inputs, outputs, and underlying types".

If we don't exercise any control over the contents of the notifications
messages, that would make it difficult for consumers of the
notifications to do anything interesting with them.  At a minimum it
might make sense to do something like REST API microversions, with a
version number and a place to look up what changed with each version.


The events and their payloads are listed in the wiki here [1].

In the past people have added new notifications with just bug reports, I'm
not sure a new spec is required for a host going into maintenance mode (as
long as it's new and not changing something).


Yeah, in it's current state without real versioning on notifications I think
just adding it with a bug is fine. If nova actually had a versioning mechanism
and made stability guarantees on notifications it would be a different story.


I'm fine either way...just wanted to be sure the decision was made consciously.

Chris


__
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] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

2015-04-06 Thread Ghe Rivero

Quoting Morgan Fainberg (2015-04-04 02:55:59)
> I am looking forward to the Liberty cycle and seeing the special casing we do
> for SQLite in our migrations (and elsewhere). My inclination is that we should
> (similar to the deprecation of eventlet) deprecate support for SQLite in
> Keystone. In Liberty we will have a full functional test suite that can (and
> will) be used to validate everything against much more real environments
> instead of in-process ?eventlet-like? test-keystone-services; the ?Restful 
> test
> cases? will no longer be part of the standard unit tests (as they are
> functional testing). With this change I?m inclined to say SQLite (being the
> non-production usable DB) what it is we should look at dropping migration
> support for SQLite and the custom work-arounds.
> 
> Most deployers and developers (as far as I know) use devstack and MySQL or
> Postgres to really suss out DB interactions.
> 
> I am looking for feedback from the community on the general stance for SQLite,
> and more specifically the benefit (if any) of supporting it in Keystone.
> 
> -- 
> Morgan Fainberg

+1

__
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] [Mistral] Upgrading to YAQL 1.0

2015-04-06 Thread Stan Lagun

The plan was to integrate YAQL 1.0 into Murano so that we could say it is
battle-proven, remove "beta" from version and release on PyPI. And then
probably release v1.0.1 that is YAQL with documentation :)

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis



On Mon, Apr 6, 2015 at 9:44 PM, Dmitri Zimine 
wrote:

> Renat,
>
> following up on the IRC meeting: I recalled one more item, and registered
> a blueprint - https://blueprints.launchpad.net/mistral/+spec/yaql-v1-0I
> think it’s good timing to do it in Kilo if YAQL 1.0 is announced; so I
> propose it for Kilo-rc1;
>
> One question is when YAQL 1.0 is going to move to Pypi? we can get it from
> github link for some time but ideally should use pypi. Alex, Stan, what’s
> the plan?
>
> DZ.
>
>
>
__
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] Host maintenance notification

2015-04-06 Thread Matthew Treinish

On Mon, Apr 06, 2015 at 01:17:20PM -0500, Matt Riedemann wrote:
> 
> 
> On 4/6/2015 9:46 AM, Chris Friesen wrote:
> >On 04/06/2015 07:56 AM, Ed Leafe wrote:
> >>On Apr 6, 2015, at 1:21 AM, Chris Friesen 
> >>wrote:
> >>
> Please feel free to add a blueprint in Launchpad. I don't see this as
> needing a full spec, really. It shouldn't be more than a few lines of
> code to send a new notification message.
> >>>
> >>>Wouldn't a new notification message count as an API change?  Or are we
> >>>saying that it's such a small API change that any discussion can
> >>>happen in
> >>>the blueprint?
> >>
> >>I don't think that the notification system is the same as the API. It is
> >>something that you can subscribe to or not, and is distinct from the API.
> >
> >It's certainly not the same as the REST API.  I think an argument could
> >be made that the notification system is part of the API, where API is
> >defined more generally as "something that expresses a software component
> >in terms of its operations, inputs, outputs, and underlying types".
> >
> >If we don't exercise any control over the contents of the notifications
> >messages, that would make it difficult for consumers of the
> >notifications to do anything interesting with them.  At a minimum it
> >might make sense to do something like REST API microversions, with a
> >version number and a place to look up what changed with each version.
> 
> The events and their payloads are listed in the wiki here [1].
> 
> In the past people have added new notifications with just bug reports, I'm
> not sure a new spec is required for a host going into maintenance mode (as
> long as it's new and not changing something).

Yeah, in it's current state without real versioning on notifications I think
just adding it with a bug is fine. If nova actually had a versioning mechanism
and made stability guarantees on notifications it would be a different story.

> 
> And yes, we have to be careful about making changes to existing
> notifications (the event name or the payload) since we have to treat them
> like APIs, but (1) they aren't versioned today and (2) we don't have any
> kind of integration testing on the events that I'm aware of, unless it's
> through something like ceilometer trying to do something with them in a
> tempest scenario test, but I doubt that.

There are a couple of notification tests in tempest [2][3] but only 1 which uses
nova. But, this actually re-raises something which I brought up last summer
about how we need real versioning on notifications, and having real functional
testing of the notifications if we are going to rely on them and enable external
consumption. IMO, just testing it implicitly in tempest through ceilometer is
the wrong approach. It makes sense to have this kind of testing in tempest after
we have direct testing of notifications, but until that and real stability
guarantees are in place for notifications it makes testing it in tempest
problematic. (which just mirrors the experience of consumers of the
notifications)

We previously haven't blocked any of this testing in tempest, but the fact that
only 4 notification tests have been added of which 2 are skipped and the other 2
have been problematic at some point make me very hesitant about adding more
until we have the missing pieces in place.

> 
> [1] https://wiki.openstack.org/wiki/SystemUsageData
> 

-Matt Treinish

[2] 
http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/telemetry/test_telemetry_notification_api.py
[3] 
http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/test_swift_telemetry_middleware.py

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

Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

2015-04-06 Thread Morgan Fainberg



> On Apr 6, 2015, at 11:41, Mike Bayer  wrote:
> 
> 
> 
>> On 4/6/15 12:49 PM, David Stanek wrote:
>> Exactly. This is the direction I have been going. Functional tests are 
>> written using the public APIs using the client.
>> 
>> I would also add that I don't like that the Keystone unit tests are so 
>> database heavy. I would not want MySQL or ant RDBMS to be a requirement for 
>> running the tests.
>> 
> is that because you'd prefer that the unit tests were more isolated, or just 
> that an external service is being used?
> 
> I've done some work with extensive mocking of SQL databases; specifically 
> mocking at the ORM level.  It is nice when you get it to run, but it's also a 
> much bigger job to write fine-grained mocks like that, the mocks can be 
> brittle in relation to the code they're targeting, and you also need to come 
> up with some solution to actually functional test your database access code.
> 
> I tend to think that having a mysqld service running is the lesser of two 
> evils and you get a lot more code coverage by going all the way out to the DB.
> 

What David is specifically referencing is that we want our functional tests to 
only require direct API access. There is almost no reason to need access to the 
DB backend. We have many ways to perform isolation where needed (tempest does a 
lot of this today). 

The goal is to allow the functional test suite to run against any keystone 
deployment (be agnostic to db, non-db, etc driver used). This makes environment 
setup a separate concern the tests don't need to be involved in/aware of. It 
makes our functional tests more useful for validating a driver or configuration 
passes muster. 

If there are legitimately cases we need to test a specific db function in 
isolation we will make specific efforts to support it. Those are apt to be the 
exception to the rule. 

--Morgan
Sent via mobile 

> 
> 
>> 
>>> On Mon, Apr 6, 2015, 12:42 Morgan Fainberg  
>>> wrote:
>>> 
>>> 
>>> > On Apr 6, 2015, at 09:20, Mike Bayer  wrote:
>>> >
>>> >
>>> >
>>> >> On 4/6/15 12:06 PM, Clint Byrum wrote:
>>> >> Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700:
>>>  On Saturday 04 April 2015 03:55:59 Morgan Fainberg wrote:
>>>  I am looking forward to the Liberty cycle and seeing the special 
>>>  casing we
>>>  do for SQLite in our migrations (and elsewhere). My inclination is 
>>>  that we
>>>  should (similar to the deprecation of eventlet) deprecate support for
>>>  SQLite in Keystone. In Liberty we will have a full functional test 
>>>  suite
>>>  that can (and will) be used to validate everything against much more 
>>>  real
>>>  environments instead of in-process “eventlet-like” 
>>>  test-keystone-services;
>>>  the “Restful test cases” will no longer be part of the standard unit 
>>>  tests
>>>  (as they are functional testing). With this change I’m inclined to say
>>>  SQLite (being the non-production usable DB) what it is we should look 
>>>  at
>>>  dropping migration support for SQLite and the custom work-arounds.
>>> 
>>>  Most deployers and developers (as far as I know) use devstack and 
>>>  MySQL or
>>>  Postgres to really suss out DB interactions.
>>> 
>>>  I am looking for feedback from the community on the general stance for
>>>  SQLite, and more specifically the benefit (if any) of supporting it in
>>>  Keystone.
>>> >>> +1. Drop it and clean up tons of code used for support of sqlite only.
>>> >>>
>>> >>> Doing tests with mysql is as easy, as with sqlite ("mysqladmin drop -f;
>>> >>> mysqladmin create" for "reset"), and using it by default will finally 
>>> >>> make
>>> >>> people test their code on real rdbmses.
>>> >> Please please please be careful with that and make sure the database
>>> >> name is _always_ random in tests... or even better, write a fixture to
>>> >> spin up a mysqld inside a private tempdir. That would be a really cool
>>> >> thing for oslo.db to provide actually.
>>> >>
>>> >> I'm just thinking some poor sap runs the test suite with the wrong
>>> >> .my.cnf in the wrong place and  there went keystone's db.
>>> > The standard approach here is that tests based on the oslo.db approach by 
>>> > default connect using a username openstack_citest on localhost, which is 
>>> > then used to create databases of random names. If you base your database 
>>> > tests on oslo.db, you get that right now.   This username/host/etc is 
>>> > also configurable through environment variables.  I don't see how my.cnf 
>>> > is involved in this nor how it would impact someone's keystone database, 
>>> > unless we're talking about tests that happen to load down and/or crash 
>>> > the whole database server.
>>> >
>>> > spinning up a whole mysqld seems really heavy-handed and unnecessary.  
>>> > Not to mention the tests run on other backends as well such as Postgresql.
>>> >
>>> 
>>> The reasons outlined by both Cli

[openstack-dev] [Mistral] Upgrading to YAQL 1.0

2015-04-06 Thread Dmitri Zimine

Renat, 

following up on the IRC meeting: I recalled one more item, and registered a 
blueprint - https://blueprints.launchpad.net/mistral/+spec/yaql-v1-0I think 
it’s good timing to do it in Kilo if YAQL 1.0 is announced; so I propose it for 
Kilo-rc1;

One question is when YAQL 1.0 is going to move to Pypi? we can get it from 
github link for some time but ideally should use pypi. Alex, Stan, what’s the 
plan? 

DZ.  


__
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] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

2015-04-06 Thread Mike Bayer

On 4/6/15 12:49 PM, David Stanek wrote:

Exactly. This is the direction I have been going. Functional tests are 
written using the public APIs using the client.

I would also add that I don't like that the Keystone unit tests are so 
database heavy. I would not want MySQL or ant RDBMS to be a 
requirement for running the tests.

is that because you'd prefer that the unit tests were more isolated, or 
just that an external service is being used?

I've done some work with extensive mocking of SQL databases; 
specifically mocking at the ORM level.  It is nice when you get it to 
run, but it's also a much bigger job to write fine-grained mocks like 
that, the mocks can be brittle in relation to the code they're 
targeting, and you also need to come up with some solution to actually 
functional test your database access code.

I tend to think that having a mysqld service running is the lesser of 
two evils and you get a lot more code coverage by going all the way out 
to the DB.

On Mon, Apr 6, 2015, 12:42 Morgan Fainberg > wrote:

> On Apr 6, 2015, at 09:20, Mike Bayer mailto:mba...@redhat.com>> wrote:
>
>
>
>> On 4/6/15 12:06 PM, Clint Byrum wrote:
>> Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700:
 On Saturday 04 April 2015 03:55:59 Morgan Fainberg wrote:
 I am looking forward to the Liberty cycle and seeing the
special casing we
 do for SQLite in our migrations (and elsewhere). My
inclination is that we
 should (similar to the deprecation of eventlet) deprecate
support for
 SQLite in Keystone. In Liberty we will have a full functional
test suite
 that can (and will) be used to validate everything against
much more real
 environments instead of in-process “eventlet-like”
test-keystone-services;
 the “Restful test cases” will no longer be part of the
standard unit tests
 (as they are functional testing). With this change I’m
inclined to say
 SQLite (being the non-production usable DB) what it is we
should look at
 dropping migration support for SQLite and the custom
work-arounds.

 Most deployers and developers (as far as I know) use devstack
and MySQL or
 Postgres to really suss out DB interactions.

 I am looking for feedback from the community on the general
stance for
 SQLite, and more specifically the benefit (if any) of
supporting it in
 Keystone.
>>> +1. Drop it and clean up tons of code used for support of
sqlite only.
>>>
>>> Doing tests with mysql is as easy, as with sqlite ("mysqladmin
drop -f;
>>> mysqladmin create" for "reset"), and using it by default will
finally make
>>> people test their code on real rdbmses.
>> Please please please be careful with that and make sure the
database
>> name is _always_ random in tests... or even better, write a
fixture to
>> spin up a mysqld inside a private tempdir. That would be a
really cool
>> thing for oslo.db to provide actually.
>>
>> I'm just thinking some poor sap runs the test suite with the wrong
>> .my.cnf in the wrong place and  there went keystone's db.
> The standard approach here is that tests based on the oslo.db
approach by default connect using a username openstack_citest on
localhost, which is then used to create databases of random names.
If you base your database tests on oslo.db, you get that right
now.   This username/host/etc is also configurable through
environment variables.  I don't see how my.cnf is involved in this
nor how it would impact someone's keystone database, unless we're
talking about tests that happen to load down and/or crash the
whole database server.
>
> spinning up a whole mysqld seems really heavy-handed and
unnecessary.  Not to mention the tests run on other backends as
well such as Postgresql.
>

The reasons outlined by both Clint and Mike are why we won't be
attempting this until we are happy with our functional test suite.
But once we are happy dropping SQLite is on the table. The way I
see it the functional tests should be performed against a real
keystone server, even if it is one spun up for testing specifically.

Per test db creation / other such stuff will be part of that
discussion.
__
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 usag

[openstack-dev] [qa] [devstack] Confusion about member roles in tempest/devstack

2015-04-06 Thread David Kranz

There have been a number of changes in tempest recently that seem to 
coordinate with devstack that are a bit unclear.


The following values are defined in tempest config as defaults:

[auth]
# Roles to assign to all users created by tempest (list value)
#tempest_roles =

[object-storage]
# Role to add to users created for swift tests to enable creating
# containers (string value)
#operator_role = Member

[orchestration]
# Role required for users to be able to manage stacks (string value)
#stack_owner_role = heat_stack_owner

These are the values created in tempest.conf by devstack:

[auth]

tempest_roles = Member


[orchestration]
stack_owner_role = _member_

So a couple of questions.

Why do we have Member and _member_, and what is the difference supposed 
to be?


Experimentally, it seems that the tempest roles cannot be empty, so why 
is that the default?


The heat_stack_owner role used to be created in juno devstack but no 
longer. Is there a reason to leave this as the default?


Any explanations appreciated !

 -David


__
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] Host maintenance notification


On 04/06/2015 08:52 AM, Jay Pipes wrote:

On 04/05/2015 11:21 PM, Chris Friesen wrote:

On 04/05/2015 09:17 PM, Jay Pipes wrote:

On 03/30/2015 03:16 AM, Balázs Gibizer wrote:

Hi,

I have the following scenario. I have an application consisting of
multiple VMs on different compute hosts. The admin puts one of the
hosts into maintenance mode (nova-manage service disable ...) because
there will  be some maintenance activity on that host in the near
future. Is there a way to  get a notification from Nova when a host
is put into maintenance mode? If it is not the case today would the
nova community support such an addition to Nova?

As a subsequent question is there a way for an external system to
listen to such a notification published on the message bus?


Hi Gibi!

I don't believe there is a notification currently sent when a service is
disabled. I agree this would be a good (and pretty easy) addition to
Nova.

Please feel free to add a blueprint in Launchpad. I don't see this as
needing a
full spec, really. It shouldn't be more than a few lines of code to
send a new
notification message.


Wouldn't a new notification message count as an API change?  Or are we
saying that it's such a small API change that any discussion can happen
in the blueprint?

(I'm trying to figure out how this relates to
"http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html";
which says that any API change requires a spec.)


Hmm, good point. I think this is kinda borderline whether it's an API change,
but probably best to be safe and submit a small spec. Thanks, Chris.



Sorry for making more work for you Gibi. :)

Chris

__
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] Host maintenance notification

2015-04-06 Thread Matt Riedemann




On 4/6/2015 9:46 AM, Chris Friesen wrote:

On 04/06/2015 07:56 AM, Ed Leafe wrote:

On Apr 6, 2015, at 1:21 AM, Chris Friesen 
wrote:


Please feel free to add a blueprint in Launchpad. I don't see this as
needing a full spec, really. It shouldn't be more than a few lines of
code to send a new notification message.


Wouldn't a new notification message count as an API change?  Or are we
saying that it's such a small API change that any discussion can
happen in
the blueprint?


I don't think that the notification system is the same as the API. It is
something that you can subscribe to or not, and is distinct from the API.


It's certainly not the same as the REST API.  I think an argument could
be made that the notification system is part of the API, where API is
defined more generally as "something that expresses a software component
in terms of its operations, inputs, outputs, and underlying types".

If we don't exercise any control over the contents of the notifications
messages, that would make it difficult for consumers of the
notifications to do anything interesting with them.  At a minimum it
might make sense to do something like REST API microversions, with a
version number and a place to look up what changed with each version.

Chris

__
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



The events and their payloads are listed in the wiki here [1].

In the past people have added new notifications with just bug reports, 
I'm not sure a new spec is required for a host going into maintenance 
mode (as long as it's new and not changing something).


And yes, we have to be careful about making changes to existing 
notifications (the event name or the payload) since we have to treat 
them like APIs, but (1) they aren't versioned today and (2) we don't 
have any kind of integration testing on the events that I'm aware of, 
unless it's through something like ceilometer trying to do something 
with them in a tempest scenario test, but I doubt that.


[1] https://wiki.openstack.org/wiki/SystemUsageData

--

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][ec2-api] Need advice about running Tempest against stackforge/ec2-api

2015-04-06 Thread Andrey M . Pavlov



06.04.2015, 19:38, "Sean Dague" :
> On 04/06/2015 12:13 PM, Andrey M. Pavlov wrote:
>>  Hi,
>>
>>  We've got a couple of problems running original Tempest EC2 API test 
>> against new standalone stackforge/ec2-api project and
>>  I wanted to ask for some advice about how to deal with it.
>>
>>  Tempest now is running against our ec2-api after this review was closed -
>>  https://review.openstack.org/#/c/170258/
>>
>>  And now we face two problems (that can also be found in tempest logs of 
>> this review -
>>  https://review.openstack.org/#/c/170668/)
>>  For now I switched tempest gating job to non-voting until these problems 
>> are resolved in the following review -
>>  https://review.openstack.org/#/c/170646/
>>
>>  Problems are:
>>  1) 
>> tempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip
>>  this test tries to allocate address and disassociate it without association.
>>  Amazon allows to do it and does not throw error. But EC2 implementation in 
>> Nova throws error.
>>  We have the same test in our own test suite against stackforge/ec2-api (but 
>> it's not merged yet) and I checked it against Amazon.
>>  I suggest to remove this test from tempest as incompatible with Amazon.
>>  Also it can be skipped but for me it has no sense.
>
> This seems fine as a removal.

Ok. I'll create review.

>>  2) 
>> tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes
>>  This test registers three images by their manifests, run instance with 
>> image/kernel/ramdisk parameters,
>>  and ssh into this instance to check something.
>>  This is not the only test that runs instance with such parameters but this 
>> is the only one
>>  that ssh-s into such an instance.
>>  This instance runs but test can't ssh into it and it fails. Because this 
>> instance doesn't have ramdisk and kernel.
>>  It runs supplied with image property only. The VM comes up semi-functional 
>> and instance can't boot up as a result.
>>  Problem is in the ec2-api/nova communication. Nova public API doesn't 
>> support kernel and ramdisk parameters during instance creation.
>>
>>  Next I'll file a bug to ec2-api with this description.
>
> This seems problematic, because I think what you are saying is that the
> stackforge EC2 API can't start a working guest. This is the only one of
> the ec2 tests that actually validates the guest is running correctly IIRC.
>
> Is there an equivalent test that exists that you think would be better?
> I'm also not sure I understand where the breakdown is here in missing
> functionality.

EC2 API can start a working guest from one image(that has ramdisk/kernel 
properties)
And our functional tests have such tests. For example we have test that ssh-s 
into guest and checks correctness of userData.
But we use cirros image that has links to kernel/ramdisk.

Difference between running instance from image that has links to kernel/ramdisk 
(or image with ramdisk/kernel inside)
and running instance from three images - where image, kernel and ramdisk are 
placed separately.

>>  In the long run we should discuss adding this feature to public API but for 
>> now we'd like to put Tempest
>>  in our project back to voting state.
>>  We've got several options about what to do for this and we need some help 
>> to pick one (or several):
>>  1) skip this test in tempest and switch tempest back to voting state in our 
>> project.
>>  The problem is that this test is still also employed against nova's EC2 so 
>> it'll get skipped there as well.
>>  2) Leave it as non-voting until extension is added to nova.
>>  Great solution but it'll take way too long I understand.
>>  3) add special condition to skipping the test so that it's skipped only 
>> when employed against stackforge/ec2-api,
>>  while still working against nova if it's possible at all and not too much 
>> hassle.
>>
>>  Kind regards,
>>  Andrey.
>>
>>  __
>>  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

__
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] [oslo] not running for PTL for liberty cycle


+1000

You have done a great job Doug!  Thank you for your leadership!

Jay

On 04/03/2015 08:11 AM, Flavio Percoco wrote:

On 03/04/15 08:50 -0400, Doug Hellmann wrote:

Team,

I have decided not to run for PTL for Oslo for the next cycle.

Serving as PTL for the last three releases has been a rewarding 
experience, and I think we’ve made some great strides together as a 
team. Now it’s time for me to step down and let someone else take the 
lead position. I am still committed to the mission, and I will  be 
contributing to Oslo, but I do also want to work on some other 
projects that I won’t have time for if I stay in the PTL role. We 
have several good candidates for PTL on the team, and I expect us to 
have no trouble finding someone willing to step up and run.




FWIW, I believe you did an *AMAZING* job as Oslo PTL. It was an honor
to have you in that position. Thanks for your hard work.

Flavio



__
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][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

2015-04-06 Thread Joe Gordon

On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews 
wrote:

>
> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic  wrote:
>
>> Jay,
>>
>>
>> Not far, IMHO. 100ms difference in startup time isn't something we should
>>> spend much time optimizing. There's bigger fish to fry.
>>
>>
>> I agree that priority of this task shouldn't be critical or even high,
>> and that there are other places that can be improved in OpenStack.
>>
>> In other hand this one is as well big source of UX issues that we have in
>> OpenStack..
>>
>> For example:
>>
>> 1) You would like to run some command X times where X is pretty big
>> (admins likes to do this via bash loops). If you can execute all of them
>> for 1 and not 10 minutes you will get happier end user.
>>
>
> +1 I'm fully in support of this effort. Shaving 100ms off the startup time
> of a frequently used library means that you'll save that 100ms over and
> over, adding up to a huge win.
>
>

Another data point on how slow our libraries/CLIs can be:

$ time openstack -h

real0m2.491s
user0m2.378s
sys 0m0.111s



>
>> 2) Bash completion - should be online.
>> For example, it takes about 600-700ms to run Rally, so we need to have
>> hardcoded bash completion scripts, because otherwise it is too slow and not
>> consumable.
>>
>> There are other use cases where starting speed is crucial but IMHO
>> authors of libs should help to make projects faster and users happier,
>> especially when it is quite simple task.
>>
>>
>>
>>> p.s. Boris, please don't hate me :)
>>
>>
>> I will ;)
>>
>>
>> Best regards,
>> Boris Pavlovic
>>
>>
>>
>>
>>
>>
>> On Mon, Apr 6, 2015 at 5:54 PM, Jay Pipes  wrote:
>>
>>> On 04/06/2015 07:02 AM, Brant Knudson wrote:
>>>
 On Sun, Apr 5, 2015 at 5:41 PM, Boris Pavlovic >>> > wrote:

 Brant,

 I run profimp with and without patch
 https://review.openstack.org/#/c/164066/:
 And it really works well:

 before 170ms:
 http://boris-42.github.io/keystone/before.html

 after 76ms:
 http://boris-42.github.io/keystone/after.html

 Looks like now the issue is that keystoneclient imports pbr.version so
 that it can get pbr to generate the __version__ value. Maybe pbr could
 be more efficient about the work it does on import, or we could figure
 out a different / lazy way to generate the version string.
 http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/
 keystoneclient/__init__.py#n35

 How far do we need to go with this?

>>>
>>> Not far, IMHO. 100ms difference in startup time isn't something we
>>> should spend much time optimizing. There's bigger fish to fry.
>>>
>>> Best,
>>> -jay
>>>
>>> p.s. Boris, please don't hate me :)
>>>
>>>
>>> 
>>> __
>>> 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] [mistral] Team meeting minutes - 04/06/2016

2015-04-06 Thread Renat Akhmerov

Thanks everyone for joining us today, it was a very good and productive meeting.

As usually,

Meeting minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-04-06-16.20.html
 

Full log: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-04-06-16.20.log.html
 


Thanks again and join us in one week on April 13 at the same time.

Renat Akhmerov
@ Mirantis Inc.



__
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] PTL Candidacy

2015-04-06 Thread Dean Troyer

I would like to announce my candidacy for OpenStackClient PTL.  I started
this project nearly three years ago in order to give CLI users a uniform
experience in interacting with OpenStack clouds.  OSC was recently the
first project added as part of the new governance model.

While response to OSC has always been good the active developer group has
generally been small and development slower than we would have liked.  I am
now in a position to change that and step up the pace of development and
broaden the contributor base.

The future of OSC holds some interesting problems to solve, including
adopting a single low-level API to provide the backend REST handlers and
addressing the issue of installation and a multitude of dependencies.  We
have the introduction of a cloud/client configuration ability coming soon
and client-side caching of tokens and other cloud data following after.
There is also some refinement to make running in interactive mode more
suitable as a Bash coprocess.  And as always, keeping up with the project
commands is still a top priority

I believe there are certain areas where a strong guiding hand provides a
better end result than only building on consensus, and user interface
design consistency is one of those areas.  So much so that I like to say
the 'C' in OSC stands for 'consistency'.  The rest of the backronym is left
as an exercise to the reader.

I would be honored to have your support.

Thanks
dt

-- 

Dean Troyer
dtro...@gmail.com
__
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] [cinder] Please check the log access

2015-04-06 Thread Mike Perez

On 12:34 Mon 06 Apr , Duncan Thomas wrote:
> Confirmed
> 
> On 6 April 2015 at 11:51, liuxinguo  wrote:
> 
> >  Hi Mike,
> >
> >
> >
> > Please check this patch at Patch Set 3 our CI have newly posted result:
> >
> > https://review.openstack.org/#/c/170770/‍
> >
> >
> >
> > · We have changed the report link to 8088 port and it can be
> > accessed successfully, needn’t to manually change the port to 8088 any
> > more.

Patch for readding Huawei 18000 volume driver has been posted.

https://review.openstack.org/170923

-- 
Mike Perez

__
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] [Documentation] Not running for Doc PTL

2015-04-06 Thread Andreas Jaeger


On 04/06/2015 05:54 PM, Jay Pipes wrote:

Anne, you've rocked for so many years as the documentation lead in
OpenStack. Thank you from the bottom of my heart for the effort you've
put in. We'll very much welcome your increased feedback in the API design.


+1000s!

Thanks a lot, Anne - and I'm glad you stay around,

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] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

2015-04-06 Thread David Stanek

Exactly. This is the direction I have been going. Functional tests are
written using the public APIs using the client.

I would also add that I don't like that the Keystone unit tests are so
database heavy. I would not want MySQL or ant RDBMS to be a requirement for
running the tests.

On Mon, Apr 6, 2015, 12:42 Morgan Fainberg 
wrote:

>
>
> > On Apr 6, 2015, at 09:20, Mike Bayer  wrote:
> >
> >
> >
> >> On 4/6/15 12:06 PM, Clint Byrum wrote:
> >> Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700:
>  On Saturday 04 April 2015 03:55:59 Morgan Fainberg wrote:
>  I am looking forward to the Liberty cycle and seeing the special
> casing we
>  do for SQLite in our migrations (and elsewhere). My inclination is
> that we
>  should (similar to the deprecation of eventlet) deprecate support for
>  SQLite in Keystone. In Liberty we will have a full functional test
> suite
>  that can (and will) be used to validate everything against much more
> real
>  environments instead of in-process “eventlet-like”
> test-keystone-services;
>  the “Restful test cases” will no longer be part of the standard unit
> tests
>  (as they are functional testing). With this change I’m inclined to say
>  SQLite (being the non-production usable DB) what it is we should look
> at
>  dropping migration support for SQLite and the custom work-arounds.
> 
>  Most deployers and developers (as far as I know) use devstack and
> MySQL or
>  Postgres to really suss out DB interactions.
> 
>  I am looking for feedback from the community on the general stance for
>  SQLite, and more specifically the benefit (if any) of supporting it in
>  Keystone.
> >>> +1. Drop it and clean up tons of code used for support of sqlite only.
> >>>
> >>> Doing tests with mysql is as easy, as with sqlite ("mysqladmin drop -f;
> >>> mysqladmin create" for "reset"), and using it by default will finally
> make
> >>> people test their code on real rdbmses.
> >> Please please please be careful with that and make sure the database
> >> name is _always_ random in tests... or even better, write a fixture to
> >> spin up a mysqld inside a private tempdir. That would be a really cool
> >> thing for oslo.db to provide actually.
> >>
> >> I'm just thinking some poor sap runs the test suite with the wrong
> >> .my.cnf in the wrong place and  there went keystone's db.
> > The standard approach here is that tests based on the oslo.db approach
> by default connect using a username openstack_citest on localhost, which is
> then used to create databases of random names. If you base your database
> tests on oslo.db, you get that right now.   This username/host/etc is also
> configurable through environment variables.  I don't see how my.cnf is
> involved in this nor how it would impact someone's keystone database,
> unless we're talking about tests that happen to load down and/or crash the
> whole database server.
> >
> > spinning up a whole mysqld seems really heavy-handed and unnecessary.
> Not to mention the tests run on other backends as well such as Postgresql.
> >
>
> The reasons outlined by both Clint and Mike are why we won't be attempting
> this until we are happy with our functional test suite. But once we are
> happy dropping SQLite is on the table. The way I see it the functional
> tests should be performed against a real keystone server, even if it is one
> spun up for testing specifically.
>
> Per test db creation / other such stuff will be part of that discussion.
> __
> 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] [cinder] Please use 8088 port to access Huawei Volume CI's log instead of 80 port

2015-04-06 Thread Mike Perez

On 07:37 Mon 06 Apr , liuxinguo wrote:
> Hi Duncan,
> 
> For the 80 port of our log server is blocked by some reason, I have updated
> my apache configuretion to use 8088 port.
> Hence, please change to access our CI logs use 8088 port.
> For example, when you access
> http://182.138.104.27/huawei-18000-iscsi-dsvm-tempest-full/89, please change 
> to use 8088 port like
> http://182.138.104.27:8088/huawei-18000-iscsi-dsvm-tempest-full/89/ .
> 
> I make an apology for the
> inconvenient to access the CI logs:).

As mentioned in our conversation on #openstack-cinder, you should be changing
your CI to post links with port 8088, not expect people to know this.

-- 
Mike Perezs

__
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] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

2015-04-06 Thread Morgan Fainberg



> On Apr 6, 2015, at 09:20, Mike Bayer  wrote:
> 
> 
> 
>> On 4/6/15 12:06 PM, Clint Byrum wrote:
>> Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700:
 On Saturday 04 April 2015 03:55:59 Morgan Fainberg wrote:
 I am looking forward to the Liberty cycle and seeing the special casing we
 do for SQLite in our migrations (and elsewhere). My inclination is that we
 should (similar to the deprecation of eventlet) deprecate support for
 SQLite in Keystone. In Liberty we will have a full functional test suite
 that can (and will) be used to validate everything against much more real
 environments instead of in-process “eventlet-like” test-keystone-services;
 the “Restful test cases” will no longer be part of the standard unit tests
 (as they are functional testing). With this change I’m inclined to say
 SQLite (being the non-production usable DB) what it is we should look at
 dropping migration support for SQLite and the custom work-arounds.
 
 Most deployers and developers (as far as I know) use devstack and MySQL or
 Postgres to really suss out DB interactions.
 
 I am looking for feedback from the community on the general stance for
 SQLite, and more specifically the benefit (if any) of supporting it in
 Keystone.
>>> +1. Drop it and clean up tons of code used for support of sqlite only.
>>> 
>>> Doing tests with mysql is as easy, as with sqlite ("mysqladmin drop -f;
>>> mysqladmin create" for "reset"), and using it by default will finally make
>>> people test their code on real rdbmses.
>> Please please please be careful with that and make sure the database
>> name is _always_ random in tests... or even better, write a fixture to
>> spin up a mysqld inside a private tempdir. That would be a really cool
>> thing for oslo.db to provide actually.
>> 
>> I'm just thinking some poor sap runs the test suite with the wrong
>> .my.cnf in the wrong place and  there went keystone's db.
> The standard approach here is that tests based on the oslo.db approach by 
> default connect using a username openstack_citest on localhost, which is then 
> used to create databases of random names. If you base your database tests on 
> oslo.db, you get that right now.   This username/host/etc is also 
> configurable through environment variables.  I don't see how my.cnf is 
> involved in this nor how it would impact someone's keystone database, unless 
> we're talking about tests that happen to load down and/or crash the whole 
> database server.
> 
> spinning up a whole mysqld seems really heavy-handed and unnecessary.  Not to 
> mention the tests run on other backends as well such as Postgresql.
> 

The reasons outlined by both Clint and Mike are why we won't be attempting this 
until we are happy with our functional test suite. But once we are happy 
dropping SQLite is on the table. The way I see it the functional tests should 
be performed against a real keystone server, even if it is one spun up for 
testing specifically. 

Per test db creation / other such stuff will be part of that discussion. 
__
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][ec2-api] Need advice about running Tempest against stackforge/ec2-api

2015-04-06 Thread Sean Dague

On 04/06/2015 12:13 PM, Andrey M. Pavlov wrote:
> Hi,
> 
> We've got a couple of problems running original Tempest EC2 API test against 
> new standalone stackforge/ec2-api project and
> I wanted to ask for some advice about how to deal with it.
> 
> Tempest now is running against our ec2-api after this review was closed -
> https://review.openstack.org/#/c/170258/
> 
> And now we face two problems (that can also be found in tempest logs of this 
> review -
> https://review.openstack.org/#/c/170668/)
> For now I switched tempest gating job to non-voting until these problems are 
> resolved in the following review - 
> https://review.openstack.org/#/c/170646/
> 
> Problems are:
> 1) 
> tempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip
> this test tries to allocate address and disassociate it without association.
> Amazon allows to do it and does not throw error. But EC2 implementation in 
> Nova throws error.
> We have the same test in our own test suite against stackforge/ec2-api (but 
> it's not merged yet) and I checked it against Amazon.
> I suggest to remove this test from tempest as incompatible with Amazon.
> Also it can be skipped but for me it has no sense.

This seems fine as a removal.

> 2) 
> tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes
> This test registers three images by their manifests, run instance with 
> image/kernel/ramdisk parameters,
> and ssh into this instance to check something.
> This is not the only test that runs instance with such parameters but this is 
> the only one
> that ssh-s into such an instance.
> This instance runs but test can't ssh into it and it fails. Because this 
> instance doesn't have ramdisk and kernel.
> It runs supplied with image property only. The VM comes up semi-functional 
> and instance can't boot up as a result.
> Problem is in the ec2-api/nova communication. Nova public API doesn't support 
> kernel and ramdisk parameters during instance creation.
> 
> Next I'll file a bug to ec2-api with this description.

This seems problematic, because I think what you are saying is that the
stackforge EC2 API can't start a working guest. This is the only one of
the ec2 tests that actually validates the guest is running correctly IIRC.

Is there an equivalent test that exists that you think would be better?
I'm also not sure I understand where the breakdown is here in missing
functionality.

> In the long run we should discuss adding this feature to public API but for 
> now we'd like to put Tempest
> in our project back to voting state.
> We've got several options about what to do for this and we need some help to 
> pick one (or several):
> 1) skip this test in tempest and switch tempest back to voting state in our 
> project.
> The problem is that this test is still also employed against nova's EC2 so 
> it'll get skipped there as well.
> 2) Leave it as non-voting until extension is added to nova.
> Great solution but it'll take way too long I understand.
> 3) add special condition to skipping the test so that it's skipped only when 
> employed against stackforge/ec2-api, 
> while still working against nova if it's possible at all and not too much 
> hassle.
> 
> Kind regards,
> Andrey.
> 
> __
> 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] [oslo] not running for PTL for liberty cycle


On 04/06/2015 09:05 AM, Ben Nemec wrote:

As everyone else has said, you did a fantastic job as PTL.  Oslo is in a
much better place today because of your leadership.


Big +1.

-jay


On 04/03/2015 07:50 AM, Doug Hellmann wrote:

Team,

I have decided not to run for PTL for Oslo for the next cycle.

Serving as PTL for the last three releases has been a rewarding experience, and 
I think we’ve made some great strides together as a team. Now it’s time for me 
to step down and let someone else take the lead position. I am still committed 
to the mission, and I will  be contributing to Oslo, but I do also want to work 
on some other projects that I won’t have time for if I stay in the PTL role. We 
have several good candidates for PTL on the team, and I expect us to have no 
trouble finding someone willing to step up and run.

Thanks,
Doug


__
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] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

2015-04-06 Thread Mike Bayer




On 4/6/15 12:06 PM, Clint Byrum wrote:

Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700:

On Saturday 04 April 2015 03:55:59 Morgan Fainberg wrote:

I am looking forward to the Liberty cycle and seeing the special casing we
do for SQLite in our migrations (and elsewhere). My inclination is that we
should (similar to the deprecation of eventlet) deprecate support for
SQLite in Keystone. In Liberty we will have a full functional test suite
that can (and will) be used to validate everything against much more real
environments instead of in-process “eventlet-like” test-keystone-services;
the “Restful test cases” will no longer be part of the standard unit tests
(as they are functional testing). With this change I’m inclined to say
SQLite (being the non-production usable DB) what it is we should look at
dropping migration support for SQLite and the custom work-arounds.

Most deployers and developers (as far as I know) use devstack and MySQL or
Postgres to really suss out DB interactions.

I am looking for feedback from the community on the general stance for
SQLite, and more specifically the benefit (if any) of supporting it in
Keystone.

+1. Drop it and clean up tons of code used for support of sqlite only.

Doing tests with mysql is as easy, as with sqlite ("mysqladmin drop -f;
mysqladmin create" for "reset"), and using it by default will finally make
people test their code on real rdbmses.


Please please please be careful with that and make sure the database
name is _always_ random in tests... or even better, write a fixture to
spin up a mysqld inside a private tempdir. That would be a really cool
thing for oslo.db to provide actually.

I'm just thinking some poor sap runs the test suite with the wrong
.my.cnf in the wrong place and  there went keystone's db.
The standard approach here is that tests based on the oslo.db approach 
by default connect using a username openstack_citest on localhost, which 
is then used to create databases of random names. If you base your 
database tests on oslo.db, you get that right now.   This 
username/host/etc is also configurable through environment variables.  I 
don't see how my.cnf is involved in this nor how it would impact 
someone's keystone database, unless we're talking about tests that 
happen to load down and/or crash the whole database server.


spinning up a whole mysqld seems really heavy-handed and unnecessary.  
Not to mention the tests run on other backends as well such as Postgresql.







__
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][ec2-api] Need advice about running Tempest against stackforge/ec2-api

2015-04-06 Thread Andrey M . Pavlov

Hi,

We've got a couple of problems running original Tempest EC2 API test against
new standalone stackforge/ec2-api project and
I wanted to ask for some advice about how to deal with it.

Tempest now is running against our ec2-api after this review was closed -
https://review.openstack.org/#/c/170258/

And now we face two problems (that can also be found in tempest logs of this
review -
https://review.openstack.org/#/c/170668/)
For now I switched tempest gating job to non-voting until these problems are
resolved in the following review -
https://review.openstack.org/#/c/170646/

Problems are:
1)
tempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip
this test tries to allocate address and disassociate it without association.
Amazon allows to do it and does not throw error. But EC2 implementation in Nova
throws error.
We have the same test in our own test suite against stackforge/ec2-api (but
it's not merged yet) and I checked it against Amazon.
I suggest to remove this test from tempest as incompatible with Amazon.
Also it can be skipped but for me it has no sense.

2)
tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes
This test registers three images by their manifests, run instance with
image/kernel/ramdisk parameters,
and ssh into this instance to check something.
This is not the only test that runs instance with such parameters but this is
the only one
that ssh-s into such an instance.
This instance runs but test can't ssh into it and it fails. Because this
instance doesn't have ramdisk and kernel.
It runs supplied with image property only. The VM comes up semi-functional and
instance can't boot up as a result.
Problem is in the ec2-api/nova communication. Nova public API doesn't support
kernel and ramdisk parameters during instance creation.

Next I'll file a bug to ec2-api with this description.

In the long run we should discuss adding this feature to public API but for now
we'd like to put Tempest
in our project back to voting state.
We've got several options about what to do for this and we need some help to
pick one (or several):
1) skip this test in tempest and switch tempest back to voting state in our
project.
The problem is that this test is still also employed against nova's EC2 so
it'll get skipped there as well.
2) Leave it as non-voting until extension is added to nova.
Great solution but it'll take way too long I understand.
3) add special condition to skipping the test so that it's skipped only when
employed against stackforge/ec2-api,
while still working against nova if it's possible at all and not too much
hassle.

Kind regards,
Andrey.

Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

2015-04-06 Thread Clint Byrum

Excerpts from Boris Bobrov's message of 2015-04-03 18:29:08 -0700:
> On Saturday 04 April 2015 03:55:59 Morgan Fainberg wrote:
> > I am looking forward to the Liberty cycle and seeing the special casing we
> > do for SQLite in our migrations (and elsewhere). My inclination is that we
> > should (similar to the deprecation of eventlet) deprecate support for
> > SQLite in Keystone. In Liberty we will have a full functional test suite
> > that can (and will) be used to validate everything against much more real
> > environments instead of in-process “eventlet-like” test-keystone-services;
> > the “Restful test cases” will no longer be part of the standard unit tests
> > (as they are functional testing). With this change I’m inclined to say
> > SQLite (being the non-production usable DB) what it is we should look at
> > dropping migration support for SQLite and the custom work-arounds.
> > 
> > Most deployers and developers (as far as I know) use devstack and MySQL or
> > Postgres to really suss out DB interactions.
> > 
> > I am looking for feedback from the community on the general stance for
> > SQLite, and more specifically the benefit (if any) of supporting it in
> > Keystone.
> 
> +1. Drop it and clean up tons of code used for support of sqlite only.
> 
> Doing tests with mysql is as easy, as with sqlite ("mysqladmin drop -f; 
> mysqladmin create" for "reset"), and using it by default will finally make 
> people test their code on real rdbmses.
> 

Please please please be careful with that and make sure the database
name is _always_ random in tests... or even better, write a fixture to
spin up a mysqld inside a private tempdir. That would be a really cool
thing for oslo.db to provide actually.

I'm just thinking some poor sap runs the test suite with the wrong
.my.cnf in the wrong place and  there went keystone's db.

__
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] [oslo] not running for PTL for liberty cycle

2015-04-06 Thread Ben Nemec

As everyone else has said, you did a fantastic job as PTL.  Oslo is in a
much better place today because of your leadership.

-Ben

On 04/03/2015 07:50 AM, Doug Hellmann wrote:
> Team,
> 
> I have decided not to run for PTL for Oslo for the next cycle.
> 
> Serving as PTL for the last three releases has been a rewarding experience, 
> and I think we’ve made some great strides together as a team. Now it’s time 
> for me to step down and let someone else take the lead position. I am still 
> committed to the mission, and I will  be contributing to Oslo, but I do also 
> want to work on some other projects that I won’t have time for if I stay in 
> the PTL role. We have several good candidates for PTL on the team, and I 
> expect us to have no trouble finding someone willing to step up and run.
> 
> Thanks,
> Doug
> 
> 
> __
> 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] [neutron] [QoS] QoS weekly meeting

2015-04-06 Thread Miguel Ángel Ajo

I’d like to co-organized a QoS weekly meeting with Sean M. Collins,

In the last few years, the interest for QoS support has increased, Sean has 
been leading
this effort [1] and we believe we should get into a consensus about how to 
model an extension
to let vendor plugins implement QoS capabilities on network ports and tenant 
networks, and
how to extend agents, and the reference implementation & others [2]

As per discussion we’ve had during the last few months [3], I believe we 
should start simple, but
prepare a model allowing future extendibility, to allow for example specific 
traffic rules (per port,
per IP, etc..), congestion notification support [4], …

It’s the first time I’m trying to organize an openstack/neutron meeting, 
so, I don’t know what’s the
best way to do it, or find the best timeslot. I guess interested people may 
have a saying, so I’ve  
looped anybody I know is interested in the CC of this mail.  


Miguel Ángel Ajo

[1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api
[2] 
https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing
[3] 
https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231
[4] 
https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification

__
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] [Documentation] Not running for Doc PTL

Anne, you've rocked for so many years as the documentation lead in 
OpenStack. Thank you from the bottom of my heart for the effort you've 
put in. We'll very much welcome your increased feedback in the API design.


All the best,
-jay

On 04/06/2015 08:43 AM, Anne Gentle wrote:

Hi all,

I want to be sure you all know I don't plan to run for Documentation
PTL. I will certainly continue to provide leadership for documentation
for OpenStack. I would like to ensure continuity for documentation, by
giving the opportunity for more leaders to step up.

I'll be shifting focus to API design and documentation this release.
Thanks so much for letting me experiment with open source docs and learn
so much along the way. The docs team has done amazing work and will
continue to do so, with excellent examples of servant leadership
throughout the team.

Thanks,
Anne

--
Anne Gentle
annegen...@justwriteclick.com 


__
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][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

2015-04-06 Thread Morgan Fainberg

By the way, this review in question has merged and will be part of the
(soon) next release of keystone client.

--Morgan

On Monday, April 6, 2015, Dolph Mathews  wrote:

>
> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic  > wrote:
>
>> Jay,
>>
>>
>> Not far, IMHO. 100ms difference in startup time isn't something we should
>>> spend much time optimizing. There's bigger fish to fry.
>>
>>
>> I agree that priority of this task shouldn't be critical or even high,
>> and that there are other places that can be improved in OpenStack.
>>
>> In other hand this one is as well big source of UX issues that we have in
>> OpenStack..
>>
>> For example:
>>
>> 1) You would like to run some command X times where X is pretty big
>> (admins likes to do this via bash loops). If you can execute all of them
>> for 1 and not 10 minutes you will get happier end user.
>>
>
> +1 I'm fully in support of this effort. Shaving 100ms off the startup time
> of a frequently used library means that you'll save that 100ms over and
> over, adding up to a huge win.
>
>
>>
>> 2) Bash completion - should be online.
>> For example, it takes about 600-700ms to run Rally, so we need to have
>> hardcoded bash completion scripts, because otherwise it is too slow and not
>> consumable.
>>
>> There are other use cases where starting speed is crucial but IMHO
>> authors of libs should help to make projects faster and users happier,
>> especially when it is quite simple task.
>>
>>
>>
>>> p.s. Boris, please don't hate me :)
>>
>>
>> I will ;)
>>
>>
>> Best regards,
>> Boris Pavlovic
>>
>>
>>
>>
>>
>>
>> On Mon, Apr 6, 2015 at 5:54 PM, Jay Pipes > > wrote:
>>
>>> On 04/06/2015 07:02 AM, Brant Knudson wrote:
>>>
 On Sun, Apr 5, 2015 at 5:41 PM, Boris Pavlovic >>> 
 > wrote:

 Brant,

 I run profimp with and without patch
 https://review.openstack.org/#/c/164066/:
 And it really works well:

 before 170ms:
 http://boris-42.github.io/keystone/before.html

 after 76ms:
 http://boris-42.github.io/keystone/after.html

 Looks like now the issue is that keystoneclient imports pbr.version so
 that it can get pbr to generate the __version__ value. Maybe pbr could
 be more efficient about the work it does on import, or we could figure
 out a different / lazy way to generate the version string.
 http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/
 keystoneclient/__init__.py#n35

 How far do we need to go with this?

>>>
>>> Not far, IMHO. 100ms difference in startup time isn't something we
>>> should spend much time optimizing. There's bigger fish to fry.
>>>
>>> Best,
>>> -jay
>>>
>>> p.s. Boris, please don't hate me :)
>>>
>>>
>>> 
>>> __
>>> 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] Problem about Juno Keystone Identity V3

2015-04-06 Thread Amy Zhang

Hi guys,

I only did Keystone, so I am not sure about other services, like nova or
else. For Keystone Identity switch, basically, you need to add V3 endpoint
and set up some variables. You can check this link:
http://www.cloudkb.net/how-to-change-keystone-api-v2-v3/.

We finally found out what I did wrong when I switched from V2 to V3. For
icehouse, I used keystone command to created v3 endpoint, it worked well.
However, for some reason, it didn't work for Juno. For Juno, you have to
use openstack command to create v3 endpoint, and it works perfect. So
problem solved. Cheers!

Thanks for all! :)

On Sat, Apr 4, 2015 at 10:41 PM, Adam Young  wrote:

>  On 04/03/2015 11:09 AM, Amy Zhang wrote:
>
> Hi guys,
>
>  I have done switching Keystone Identity V2 to V3 in Icehouse and it
> works perfect. However, I use the same way to switch Keystone Identity V2
> to V3 in Juno, it doesn't work. It give me the error: "ERROR: openstack
> Internal Server Error (HTTP 500)".
>
>  I traced back to the code, find the error comes from apache, but it
> doesn't make any sense that apache has problem, it might be some problem of
> keystone which lead to error of apache.
>
>  Does any one have any idea of it? Thanks!
> --
> Best regards,
> Amy (Yun Zhang)
>
>
> __
> 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
>
>  Bet she's hitting token size issues, as that is an issue in the header
> going between mod_ WSGI and HTTPD.  Try switching to UUID tokens.
>
> __
> 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
>
>

-- 
Best regards,
Amy (Yun Zhang)
__
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] [Documentation] Not running for Doc PTL

2015-04-06 Thread Anne Gentle

Hi all,

I want to be sure you all know I don't plan to run for Documentation PTL. I
will certainly continue to provide leadership for documentation for
OpenStack. I would like to ensure continuity for documentation, by giving
the opportunity for more leaders to step up.

I'll be shifting focus to API design and documentation this release. Thanks
so much for letting me experiment with open source docs and learn so much
along the way. The docs team has done amazing work and will continue to do
so, with excellent examples of servant leadership throughout the team.

Thanks,
Anne

-- 
Anne Gentle
annegen...@justwriteclick.com
__
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][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

2015-04-06 Thread Dolph Mathews

On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic  wrote:

> Jay,
>
>
> Not far, IMHO. 100ms difference in startup time isn't something we should
>> spend much time optimizing. There's bigger fish to fry.
>
>
> I agree that priority of this task shouldn't be critical or even high, and
> that there are other places that can be improved in OpenStack.
>
> In other hand this one is as well big source of UX issues that we have in
> OpenStack..
>
> For example:
>
> 1) You would like to run some command X times where X is pretty big
> (admins likes to do this via bash loops). If you can execute all of them
> for 1 and not 10 minutes you will get happier end user.
>

+1 I'm fully in support of this effort. Shaving 100ms off the startup time
of a frequently used library means that you'll save that 100ms over and
over, adding up to a huge win.


>
> 2) Bash completion - should be online.
> For example, it takes about 600-700ms to run Rally, so we need to have
> hardcoded bash completion scripts, because otherwise it is too slow and not
> consumable.
>
> There are other use cases where starting speed is crucial but IMHO authors
> of libs should help to make projects faster and users happier, especially
> when it is quite simple task.
>
>
>
>> p.s. Boris, please don't hate me :)
>
>
> I will ;)
>
>
> Best regards,
> Boris Pavlovic
>
>
>
>
>
>
> On Mon, Apr 6, 2015 at 5:54 PM, Jay Pipes  wrote:
>
>> On 04/06/2015 07:02 AM, Brant Knudson wrote:
>>
>>> On Sun, Apr 5, 2015 at 5:41 PM, Boris Pavlovic >> > wrote:
>>>
>>> Brant,
>>>
>>> I run profimp with and without patch
>>> https://review.openstack.org/#/c/164066/:
>>> And it really works well:
>>>
>>> before 170ms:
>>> http://boris-42.github.io/keystone/before.html
>>>
>>> after 76ms:
>>> http://boris-42.github.io/keystone/after.html
>>>
>>> Looks like now the issue is that keystoneclient imports pbr.version so
>>> that it can get pbr to generate the __version__ value. Maybe pbr could
>>> be more efficient about the work it does on import, or we could figure
>>> out a different / lazy way to generate the version string.
>>> http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/
>>> keystoneclient/__init__.py#n35
>>>
>>> How far do we need to go with this?
>>>
>>
>> Not far, IMHO. 100ms difference in startup time isn't something we should
>> spend much time optimizing. There's bigger fish to fry.
>>
>> Best,
>> -jay
>>
>> p.s. Boris, please don't hate me :)
>>
>>
>> 
>> __
>> 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][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

2015-04-06 Thread Boris Pavlovic

Jay,

Not far, IMHO. 100ms difference in startup time isn't something we should
> spend much time optimizing. There's bigger fish to fry.

I agree that priority of this task shouldn't be critical or even high, and
that there are other places that can be improved in OpenStack.

In other hand this one is as well big source of UX issues that we have in
OpenStack..

For example:

1) You would like to run some command X times where X is pretty big (admins
likes to do this via bash loops). If you can execute all of them for 1 and
not 10 minutes you will get happier end user.

2) Bash completion - should be online.
For example, it takes about 600-700ms to run Rally, so we need to have
hardcoded bash completion scripts, because otherwise it is too slow and not
consumable.

There are other use cases where starting speed is crucial but IMHO authors
of libs should help to make projects faster and users happier, especially
when it is quite simple task.

> p.s. Boris, please don't hate me :)

I will ;)

Best regards,
Boris Pavlovic

On Mon, Apr 6, 2015 at 5:54 PM, Jay Pipes  wrote:

> On 04/06/2015 07:02 AM, Brant Knudson wrote:
>
>> On Sun, Apr 5, 2015 at 5:41 PM, Boris Pavlovic > > wrote:
>>
>> Brant,
>>
>> I run profimp with and without patch
>> https://review.openstack.org/#/c/164066/:
>> And it really works well:
>>
>> before 170ms:
>> http://boris-42.github.io/keystone/before.html
>>
>> after 76ms:
>> http://boris-42.github.io/keystone/after.html
>>
>> Looks like now the issue is that keystoneclient imports pbr.version so
>> that it can get pbr to generate the __version__ value. Maybe pbr could
>> be more efficient about the work it does on import, or we could figure
>> out a different / lazy way to generate the version string.
>> http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/
>> keystoneclient/__init__.py#n35
>>
>> How far do we need to go with this?
>>
>
> Not far, IMHO. 100ms difference in startup time isn't something we should
> spend much time optimizing. There's bigger fish to fry.
>
> Best,
> -jay
>
> p.s. Boris, please don't hate me :)
>
>
> __
> 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] Utilizing the KMIP plugin

2015-04-06 Thread Christopher N Solis


Hello!

Sorry to Kaitlin Farr for not responding directly to your e-mail.
My openstack settings were misconfigured and I was not receiving e-mail
from the dev mailing list.
Thanks for looking into the issue.

I double checked the permissions at the bottom of the kmip_plugin part in
the barbican-api.conf file
and they are set to 400.

I would also like to note that I do not think the code ever actually
entered the __init__ function
of KMIPSecretStore. I put a breakpoint in the __init__ function but the
debugger never gets open.
The error occurs and returns without ever seeming to enter the init
function.

Here are the parts of the barbican-api.conf file that concern the
kmip_plugin:
.
[secretstore]
namespace = barbican.secretstore.plugin
enabled_secretstore_plugins = kmip_plugin
.
[kmip_plugin]
username = '**'
password = '**'
host = 
port = 
keyfile = '/etc/barbican/rootCA.key'
certfile = '/etc/barbican/rootCA.pem'
ca_certs = '/etc/barbican/rootCA.pem'
...

Thank You!!

Regards,
Christopher Solis__
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] [Ironic] [RFC/FFE] Finishing state machine work for Kilo

2015-04-06 Thread Devananda van der Veen

Hi!

The situation you describe is the same that concerned me with regards to
stable/juno compatibility. As soon as the client library started passing a
version header by default, it exposed Kilo changes to all users. Anyone
testing from trunk would have experienced that when 99ab landed.

I just tagged release 0.5.0 of python-ironicclient which includes that
change. It therefor passes X-OpenStack-Ironic-API-Version == 1.6 (this is
your #2 below). 3rd party apps that pin to < 0.5 release of
python-ironicclient will continue to get juno-esque states. I'll announce
this in a separate thread shortly.

As far as whether to default newly created nodes to AVAILABLE, MANAGEABLE,
or ENROLLED - yea, we didn't finish the state machine work this cycle - I'd
rather not introduce a change to the default state now, then change it
again in a few months, leading to further confusion.

As far as your #3, you raise a good point. Passing the version header by
default is a potentially incompatible change with prior versions of the
client. While the CLI and library API didn't change in an incompatible way,
they expose the client to new server behavior... perhaps this should be our
1.0 release of python-ironicclient? Or perhaps, since it's still in the 0.x
range, we should wait until we know the state machine work is done and
*then* tag a 1.0 release of the client?

Re: documenting this, besides release notes, emails, and changelogs - what
would you like to see? I'm happy to put the release notes for the client
into our developer docs, along with a page on upgrading from juno to kilo
that we need to write.

-Deva

On Fri, Apr 3, 2015 at 1:31 AM Dmitry Tantsur  wrote:

> Hi all!
>
> Today I got an internal email, stating that new ironicclient brakes
> ironic-discoverd. Indeed, after rebase to the latest ironicclient git
> master, discoverd started receiving "AVAILABLE" state instead of "None"
> for newly enrolled nodes. It's not a valid state for introspection,
> valid are "MANAGEABLE" (discoverd stand-alone usage), "INSPECTING"
> (discoverd via Ironic driver) and None (Juno + discoverd stand-alone).
> Looks like despite introducing microversions we did manage to break
> 3rdparty apps relying on states... Also we're in a bit weird situation
> where nodes appear ready for scheduling, despite us having a special
> state for managing nodes _before_ being ready for scheduling.
>
> I find the situation pretty confusing, and I'd like your comments on the
> following proposal to be implemented before RC1:
>
> 1. add new micro-version 1.7. nodes created by API with this version
> will appear in state MANAGEABLE;
> 2. make a client release with current API version set to 1.6 (thus
> excluding change #1 from users of this version);
> 3. set current API version for ironicclient to 1.7 and release
> ironicclient version 2.0.0 to designate behavior changes;
> 4. document the whole thingy properly
>
> #1 should be a small change, but it definitely requires FFE.
> Thoughts?
>
> Dmitry
>
> __
> 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] [Manila] Nominate Clinton Knight for core team

2015-04-06 Thread Ben Swartzlander


On 04/02/2015 09:16 AM, Ben Swartzlander wrote:
Clinton Knight (cknight on IRC) has been working on OpenStack for the 
better part of the year, and starting in February, he shifted his 
focus from Cinder to Manila. I think everyone is already aware of his 
high quality contributions and code reviews. I would like to nominate 
him to join the Manila core reviewer team.




Normally I would wait until the meeting, but since the feedback has been 
overwhelmingly positive...


Welcome Clinton to the Manila core reviewer team!



-Ben Swartzlander
Manila PTL


__ 


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][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp


On 04/06/2015 07:02 AM, Brant Knudson wrote:

On Sun, Apr 5, 2015 at 5:41 PM, Boris Pavlovic mailto:bo...@pavlovic.me>> wrote:

Brant,

I run profimp with and without patch
https://review.openstack.org/#/c/164066/:
And it really works well:

before 170ms:
http://boris-42.github.io/keystone/before.html

after 76ms:
http://boris-42.github.io/keystone/after.html

Looks like now the issue is that keystoneclient imports pbr.version so
that it can get pbr to generate the __version__ value. Maybe pbr could
be more efficient about the work it does on import, or we could figure
out a different / lazy way to generate the version string.
http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/__init__.py#n35

How far do we need to go with this?


Not far, IMHO. 100ms difference in startup time isn't something we 
should spend much time optimizing. There's bigger fish to fry.


Best,
-jay

p.s. Boris, please don't hate me :)

__
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] Host maintenance notification


On 04/05/2015 11:21 PM, Chris Friesen wrote:

On 04/05/2015 09:17 PM, Jay Pipes wrote:

On 03/30/2015 03:16 AM, Balázs Gibizer wrote:

Hi,

I have the following scenario. I have an application consisting of
multiple VMs on different compute hosts. The admin puts one of the
hosts into maintenance mode (nova-manage service disable ...) because
there will  be some maintenance activity on that host in the near
future. Is there a way to  get a notification from Nova when a host
is put into maintenance mode? If it is not the case today would the
nova community support such an addition to Nova?

As a subsequent question is there a way for an external system to
listen to such a notification published on the message bus?


Hi Gibi!

I don't believe there is a notification currently sent when a service is
disabled. I agree this would be a good (and pretty easy) addition to
Nova.

Please feel free to add a blueprint in Launchpad. I don't see this as
needing a
full spec, really. It shouldn't be more than a few lines of code to
send a new
notification message.


Wouldn't a new notification message count as an API change?  Or are we
saying that it's such a small API change that any discussion can happen
in the blueprint?

(I'm trying to figure out how this relates to
"http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html";
which says that any API change requires a spec.)


Hmm, good point. I think this is kinda borderline whether it's an API 
change, but probably best to be safe and submit a small spec. Thanks, Chris.



Also, if the notification messages are considered part of the API,
should they be versioned?


Personally, I believe they should, and I've said that on this mailing 
list before :)


http://lists.openstack.org/pipermail/openstack-dev/2015-January/054716.html

Best,
-jay

__
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] Host maintenance notification