date:20151123




On 23/11/2015 11:14 AM, AFEK, Ifat (Ifat) wrote:

I guess I would like to do both: create a new alarm definition, then
trigger it (call alarm_actions), and possibly later on set its state
back to OK (call ok_action).
I understood that currently all alarm triggering is internal in AODH,
according to threshold/events/combination alarm rules. Would it be
possible to add a new kind of rule, that will allow triggering the
alarm externally?

what type of rule?

i have https://review.openstack.org/#/c/247211 which would theoretically 
allow you to push an action into queue which would then trigger 
appropriate REST call. not sure if it helps you plug into Aodh easier or 
not?


--
gord


__
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] Security Groups OVS conntrack support

2015-11-23 Thread Kevin Benton

Security groups already use connection tracking. It's just done via a linux
bridge right now because the versions of OVS shipped with most distros have
no native conntrack support.

On Mon, Nov 23, 2015 at 2:55 AM, Tapio Tallgren 
wrote:

> Hi,
>
> Sorry for the stupid question, but how will I use the connection tracking
> in security groups? Is there an extension to the Neutron API call "add
> security group rule" that allows for connection tracking, or this for FWaaS
> only?
>
> -Tapio
>
> On Mon, Nov 23, 2015 at 12:39 PM Fawad Khaliq  wrote:
>
>> On Mon, Nov 23, 2015 at 3:08 PM, Jakub Libosvar 
>> wrote:
>>
>>> On 11/22/2015 07:28 PM, Gal Sagie wrote:
>>> > Hi Fawad,
>>> >
>>> > From what i could understand from Miguel Angel Ajo, someone is working
>>> > on this integration and it
>>> > is suppose to be delivered as part of Mitaka.
>>> > I don't remember the person name, Miguel will sure update shortly.
>>> >
>>> > Gal.
>>>
>>> Hi Fawad, Gal,
>>>
>>> I'm the person working on ovs firewall. There is reported an rfe bug [1]
>>> to tracking it.
>>>
>>
>> Hi Kuba,
>>
>> Great. We (Kuryr team) wanted insight into the plans for this support.
>> Thanks for the note and link to the bug. I think we are all set to take the
>> discussions further.
>>
>> Fawad
>>
>>
>>> Kuba
>>>
>>> [1] https://bugs.launchpad.net/neutron/+bug/1461000
>>> >
>>> > On Sun, Nov 22, 2015 at 7:05 PM, Fawad Khaliq >> > > wrote:
>>> >
>>> > Folks,
>>> >
>>> > Is there a plan to add conntrack support to the security groups for
>>> > the OVS driver in Mitaka cycle?
>>> >
>>> > My understanding is that it is being actively worked on for
>>> > networking-ovn but no concrete plan for support in the OVS Neutron
>>> > driver yet.
>>> >
>>> > Thanks,
>>> > Fawad Khaliq
>>> >
>>> >
>>> >
>>>  __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > <
>>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Best Regards ,
>>> >
>>> > The G.
>>> >
>>> >
>>> >
>>> __
>>> > 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
>
>


-- 
Kevin Benton
__
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] Learning to Debug the Gate

2015-11-23 Thread Anita Kuno

On 11/18/2015 06:03 PM, Mikhail Medvedev wrote:
> We had a mini tutorial today in #openstack-infra, were Clark Boylan
> explained how one can bring up an environment to debug logstash-2.0.
> This is tangential to "debugging the gate", but still could be useful to
> better understand logstash/es pipeline. 
> 
> I did condense the conversation into the doc, excuse any grammar /
> punctuation that I missed:
> 
> http://paste.openstack.org/show/479346/
> 

Thanks for this post, Mikhail.

Continuing on with our learning, today we ask the question, "Is it in
Logstash?"
http://logstash.openstack.org

The answer is in this file:
http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/files/logstash/jenkins-log-client.yaml
which is the yaml file logstash.openstack.org uses to get the logs for
indexing.

Thanks for following along,
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-dev] [Monasca]

2015-11-23 Thread Fabio Giannetti (fgiannet)

Guys,
  I added https://review.openstack.org/#/c/248882/ for review.
This should create a stable/kilo release for all the Monasca components.
Please review
Thanks,

Fabio


__
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] [puppet] [ceph] Puppet Ceph CI

2015-11-23 Thread Andrew Woodward

I think I have a good lead on the recent failures in openstack / swift /
radosgw integration component that we have since disabled. It looks like
there is a oslo.config version upgrade conflict in the Juno repo we where
using for CentOS. I think moving to Kilo will help sort this out, but at
the same time I think it would be prudent to separate the Ceph v.s.
OpenStack integration into separate jobs so that we have a better idea of
which is a problem. If there is census for this, I'd need some direction /
help, as well as set them up as non-voting for now.

Looking into this I also found that the only place that we do integration
any of the cephx logic was in the same test so we will need to create a
component for it in the ceph integration as well as use it in the OpenStack
side.

Lastly un-winding the integration failure seemed overly complex. Is there a
way that we can correlate the test status inside the job at a high level
besides the entire job passed / failed without breaking them into separate
jobs?
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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] Do we need to have a mid-cycle?

2015-11-23 Thread Jim Rollenhagen

On Mon, Nov 16, 2015 at 06:05:54AM -0800, Jim Rollenhagen wrote:
> 
> Another idea I floated last week was to do a virtual midcycle of sorts.
> Treat it like a normal midcycle in that everyone tells their management
> "I'm out for 3-4 days for the midcycle", but they don't travel anywhere.
> We come up with an agenda, see if there's any planning/syncing work to
> do, or if it's all just hacking on code/reviews.
> 
> Then we can set up some hangouts (or similar) to get people in the same
> "room" working on things. Time zones will get weird, but we tend to
> split into smaller groups at the midcycle anyway; this is just more
> timezone-aligned. We can also find windows where time zones overlap when
> we want to go across those boundaries. Disclaimer: people may need to
> work some weird hours to do this well.
> 
> I think this might get a little bit bumpy, but if it goes relatively
> well we can try to improve on it for the future. Worst case, it's a
> total failure and is roughly equivalent to the "no midcycle" option.

Nobody has objected, so we're going to roll with this. See y'all there. :)

// jim

__
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] Should we make qpid/proton optional dependencies? (please say yes)

2015-11-23 Thread Robert Collins

On 23 November 2015 at 22:33, Victor Stinner  wrote:
> Hi,
>
> Would it be possible to use the "extra dependencies" thing in setup.cfg?
> Robert Collins started a similar change for Oslo DB for make DB drivers
> optional:
> https://review.openstack.org/#/c/184328/
>
> Sadly, this change was not merged yet.
>
> @Robert: any progress on this change?
>
> It would allow to ask for "Oslo Messaging with Qpid support" in service
> dependencies, without knowning the exact required Python packages for Qpid.

The yaks go deep; we (me, Nakato, StevenK, dims) have been working
through the issues in getting this live.

Most recently (yesterday!) we got a bugfix into pip to let you have
the same thing turn up in both requirements.txt (install_requires) and
a second dependency such as an extras reference - without that, the
idiom we wanted to use won't work if any dep turns up unconditionally
and optionally - thats in pip 8.0 which isn't released yet.

We also have a requirements syncing bug which dims has a patch in
progress for, needed to sync properly with extras references.

I *think* that once both those things happen (pip 8 is released, the
sync bug is landed) that the extras stuff will be unblocked and we can
walk it forward.

-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] [oslo] A special thank you to Davanum (Dims)

2015-11-23 Thread Amrith Kumar

Yes, let's talk about dims while he isn't here. I'll second what Michael and 
Steve have to say. Dims has been a great guy to work with and he's been a great 
resource.

On one occasion, I needed some openstack folks to help (in person) at very 
short notice. Dims (and Kamesh, also of Mirantis) drove over an hour each and 
we did a very well received presentation about OpenStack!

So yes, ++ to all the adjectives!

-amrith

From: Steve Martinelli [mailto:steve...@ca.ibm.com]
Sent: Monday, November 23, 2015 11:23 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [oslo] A special thank you to Davanum (Dims)


Michael Krotscheck > wrote on 
2015/11/23 10:55:04 AM:

> From: Michael Krotscheck >
> To: "OpenStack Development Mailing List (not for usage questions)"
> >
> Date: 2015/11/23 10:56 AM
> Subject: [openstack-dev] [oslo] A special thank you to Davanum (Dims)
>
> Have you ever wanted to thank someone directly, but they're not on
> IRC so you can't pester them there? Well, dims isn't on IRC right
> now, so he has to put up with being told he's awesome in public :).
>
> Thank you, dims, for helping me out on my work in oslo middleware.

> You've been calm, helpful, eternally patient, friendly, and nothing
> short of amazing.

++ to all those adjectives, dims is pretty awesome and incredibly helpful



> The straw that broke the camel's back, in this
> case, was that you fixed a bug, which I introduced, quietly and
> quickly, without any kind of big public drama.
>
> Thank you for that, and for everything else that I mentioned. You,
> sir, are a better man than I. :)
>
> Michael
> __
> 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


stevemar
__
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] Licenses

2015-11-23 Thread Amrith Kumar

I believe that Swapnil Kulkarni took over that role.

-amrith

From: Armando Dominguez [mailto:armando.doming...@rackspace.com]
Sent: Monday, November 23, 2015 12:46 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Licenses

Hey All,

Sorry for hitting the entire list, I'm just trying to find out who took over 
the license handling from Andrew Melton? I'm looking for a Pycharm license.

Thanks,
Armando
__
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] [stable] Stable team PTL nominations are open

2015-11-23 Thread Matt Riedemann




On 11/23/2015 11:11 AM, Thierry Carrez wrote:

Hi everyone,

We discussed setting up a standalone stable maintenance team and as part
of this effort we'll be organizing PTL elections over the coming weeks.

We held a preliminary meeting today to converge on team scope and
election mechanisms. The stable team mission is to:

* Define and enforce the common stable branch policy
* Educate and accompany projects as they use stable branches
* Keep CI working on stable branches
* Mentoring/growing the stable maintenance team
* Create and improve stable tooling/automation

Anyone who successfully contributed a stable branch backport over the
last year (on any active stable branch) is considered a stable
contributor and can vote in the Stable PTL election.

If you're interested, please reply to this thread with your
self-nomination (and your platform) in the coming week. Deadline for
self-nomination is 23:59 UTC on Monday, Nov 30. Elections will then be
held if needed the week after.

Thanks!



This is basically a copy of my previous self-nomination reply [1] but 
will post it here again for completeness.


Background:

* I've been stable-maint-core since April. I primarily focus on nova 
stable branches but also get into other projects when necessary for 
critical bugs and blocking gate issues.
* Much of my focus is on the CI issues, i.e. Tony's tangled web of 
onions. I already deal enough in QA on trunk that it's a natural 
extension to stable branches.

* python-novaclient release liaison.
* I already do quite a bit of stable branch maintenance internally 
(which is how I got involved with it upstream too). So I have incentive 
to keep it working.


This is basically what I see for PTL of a stable maint team:

1. Helping projects deal with stable branch policy and process. We are 
decentralizing now but I suspect there will still be a lot of learning 
and cat herding needed in individual projects. This includes being 
around to help (I'm always in #openstack-stable) and helping to 
coordinate point releases as needed.


2. Keeping the CI system working on stable. This is already something 
I've been doing on stable for a long time so that just continues. It 
also means keeping a finger on how the periodic nightly jobs are doing 
and getting projects involved/aware when their stable branches are 
failing (bringing that up in the mailing list, project meetings or a 
cross project meeting as needed). An extension of this is seeing what we 
can do to try and keep stable branches around longer, which is clearly 
something the operator community has been wanting.


3. Mentoring. A big part of this thread is talking about a lack of 
resources to work on stable branch issues (usually CI). So part of 
mentoring here is identifying and helping people that are wanting to 
work in this space. A perfect example is tonyb and the work he's done 
the past several months on tracking gate failures and blocking issues. 
It also includes keeping track of who's doing a good job with reviews 
and seeing if they are ready for core.


4. Identifying official tags for a project, which doesn't just mean they 
have a stable branch but that they abide by the stable branch policy 
(what's appropriate to backport) and that they are maintaining their 
stable branches; this means actually reviewing proposed changes, being 
proactive about backporting high severity fixes, and keeping their CI 
jobs clean.


5. Looking for ways to improve processes and tooling. One thing that has 
come up in this thread was a need for tooling to identify backportable 
changes (e.g. a high severity bug is marked as backport potential in 
launchpad but no one has done the backport yet). I'm also not entirely 
sure we have something today that is tracking stable branch review stats 
so that we can identify people that are doing (or cores not doing) reviews.


So this is a bit long-winded but it's what I see as being important for 
a separate team and PTL to do in this space. If we're going to do this, 
I want to make sure these things are covered and I think I'm in a 
position to do that.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/079694.html


--

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] [keystone][all] Move from active distrusting model to trusting model

2015-11-23 Thread Clint Byrum

Excerpts from Thierry Carrez's message of 2015-11-23 09:17:06 -0800:
> Morgan Fainberg wrote:
> > [...]
> > With all that said, here is the proposal I would like to set forth:
> > 
> > 1. Code reviews still need 2x Core Reviewers (no change)
> > 2. Code can be developed by a member of the same company as both core
> > reviewers (and approvers).
> > 3. If the trust that is being given via this new policy is violated, the
> > code can [if needed], be reverted (we are using git here) and the actors
> > in question can lose core status (PTL discretion) and the policy can be
> > changed back to the "distrustful" model described above.
> > 
> > I hope that everyone weighs what it means within the community to start
> > moving to a trusting-of-our-peers model. I think this would be a net win
> > and I'm willing to bet that it will remove noticeable roadblocks [and
> > even make it easier to have an organization work towards stability fixes
> > when they have the resources dedicated to it].
> > 
> > Thanks for your time reading this.
> 
> +1
> 
> There are so many ways to abuse strict rules that it's better to have a
> loose, trust-by-default policy and a strong history of fixing the
> mistakes and abuses whenever they arise.
> 

I second this response, third the position that we should trust each
other first.

All of the objections that have been raised boil down to that fundamental
issue.

If we are going to distrust people, let's have a reason, not a theory. How
about evidence of instances when _three_ employees from a company colluded
to merge a bad change in any OpenStack project.

__
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] A special thank you to Davanum (Dims)

2015-11-23 Thread Davanum Srinivas

Michael,

Thanks!

-- Dims

On Mon, Nov 23, 2015 at 10:55 AM, Michael Krotscheck
 wrote:
> Have you ever wanted to thank someone directly, but they're not on IRC so
> you can't pester them there? Well, dims isn't on IRC right now, so he has to
> put up with being told he's awesome in public :).
>
> Thank you, dims, for helping me out on my work in oslo middleware. You've
> been calm, helpful, eternally patient, friendly, and nothing short of
> amazing. The straw that broke the camel's back, in this case, was that you
> fixed a bug, which I introduced, quietly and quickly, without any kind of
> big public drama.
>
> Thank you for that, and for everything else that I mentioned. You, sir, are
> a better man than I. :)
>
> Michael
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

Re: [openstack-dev] [Neutron] Security Groups OVS conntrack support

2015-11-23 Thread Russell Bryant

On 11/23/2015 02:16 PM, Kevin Benton wrote:
> Security groups already use connection tracking. It's just done via a
> linux bridge right now because the versions of OVS shipped with most
> distros have no native conntrack support.

This post discusses it in the context of OVN, but gets down to showing
what the flows look like.  It also includes a link to a presentation
about ovs+conntrack given at the OpenStack Summit in Vancouver.

http://blog.russellbryant.net/2015/10/22/openstack-security-groups-using-ovn-acls/

The most recent talk on this topic was "The State of Stateful Services"
at the OVS Conference last week:

http://openvswitch.org/support/ovscon2015/16/1620-stringer.pdf
https://www.youtube.com/watch?v=PV2rxxb6lwQ

-- 
Russell Bryant

__
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][glance] Add Sabari Kumar Murugesan <smuruge...@vmware.com>


Greetings,

I'd like to propose adding Sabari Kumar Murugesan to the glance-core
team. Sabari has been contributing for quite a bit to the project with
great reviews and he's also been providing great feedback in matters
related to the design of the service, libraries and other areas of the
team.

I believe he'd be a great addition to the glance-core team as he has
demonstrated a good knowledge of the code, service and project's
priorities.

If Sabari accepts to join and there are no objections from other
members of the community, I'll proceed to add Sabari to the team in a
week from now.

Thanks,
Flavio

--
@flaper87
Flavio Percoco


signature.asc
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] [nova] Versioned notifications... who cares about the version?

2015-11-23 Thread Andrew Laski

On 11/23/15 at 04:43pm, Balázs Gibizer wrote:

From: Andrew Laski [mailto:and...@lascii.com]
Sent: November 23, 2015 17:03

On 11/23/15 at 08:54am, Ryan Rossiter wrote:
>
>
>On 11/23/2015 5:33 AM, John Garbutt wrote:
>>On 20 November 2015 at 09:37, Balázs Gibizer
>> wrote:
>>>
>>>

>>

>>There is a bit I am conflicted/worried about, and thats when we start
>>including verbatim, DB objects into the notifications. At least you
>>can now quickly detect if that blob is something compatible with your
>>current parsing code. My preference is really to keep the
>>Notifications as a totally separate object tree, but I am sure there
>>are many cases where that ends up being seemingly stupid duplicate
>>work. I am not expressing this well in text form :(
>Are you saying we don't want to be willy-nilly tossing DB objects
>across the wire? Yeah that was part of the rug-pulling of just having
>the payload contain an object. We're automatically tossing everything
>with the object then, whether or not some of that was supposed to be a
>secret. We could add some sort of property to the field like
>dont_put_me_on_the_wire=True (or I guess a notification_ready()
>function that helps an object sanitize itself?) that the notifications
>will look at to know if it puts that on the wire-serialized dict, but
>that's adding a lot more complexity and work to a pile that's already
>growing rapidly.

I don't want to be tossing db objects across the wire.  But I also am not
convinced that we should be tossing the current objects over the wire either.
You make the point that there may be things in the object that shouldn't be
exposed, and I think object version bumps is another thing to watch out for.
So far the only object that has been bumped is Instance but in doing so no
notifications needed to change.  I think if we just put objects into
notifications we're coupling the notification versions to db or RPC changes
unnecessarily.  Some times they'll move together but other times, like
moving flavor into instance_extra, there's no reason to bump notifications.

Sanitizing existing versioned objects before putting them to the wire is not 
hard to do.
You can see an example of doing it in
https://review.openstack.org/#/c/245678/8/nova/objects/service.py,cm L382.
We don't need extra effort to take care of minor version bumps because that 
does not
break a well written consumer. We do have to take care of the major version 
bumps
but that is a rare event and therefore can be handled one by one in a way John
suggested, by keep sending the previous major version for a while too.

That review is doing much of what I was suggesting.  There is a separate 
notification and payload object.  The issue I have is that within the 
ServiceStatusPayload the raw Service object and version is being dumped, 
with the filter you point out.  But I don't think that consumers really 
care about tracking Service object versions and dealing with 
compatibility there, it would be easier for them to track the 
ServiceStatusPayload version which can remain relatively stable even if 
Service is changing to adapt to db/RPC changes.

Note that I'm not against using objects for notifications and versioning, but I
picture having something like an InstanceNotification object which can
handle converting an Instance object into a suitable notification
version/format.

Converting between two object models is doable what I'm afraid of is that it
means we have to maintain two object models. Which also means If a new
field added to an internal object which needs to be in the related notification
then we have to add them in the notification model as well. So one field but
two places. That seems to be a duplication for me. I think we have to guess 
which
case will be more frequent
a) adding a new field to an internal object that does not need to be added to 
the
related notification. In this case having two separate models is better.
OR b) adding a new field to an internal object that needs to be added to the 
related
notification. In this case having one model and a filtering mechanism is better.

>>
>>Thanks,
>>John
>>
>>>Cheers,
>>>Gibi
--

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
>>
__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: OpenStack-dev-
requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>--
>Thanks,
>
>Ryan Rossiter (rlrossit)
>
>
>_
_
>OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [networking-ovs-dpdk]

2015-11-23 Thread Prathyusha Guduri

Hi Sean,

Thanks for your help before. It would be great if you look into another
issue too.

Am able to run stack.sh successfully and all services are up. But,
libvirt version was 1.2.2 and qemu version was 2.0.0

To satisfy the minimum requirement of qemu- version >=2.1 and
libvirt-version >= 1.2.10
I manually installed qemu and libvirt from respective sources.

Now
$ kvm --version
 /usr/bin/kvm: line 42: /tmp/qemu.orig: Permission denied
 QEMU emulator version 2.1.3, Copyright (c) 2003-2008 Fabrice Bellard

$ virsh --version
1.2.10

So basic requirement is satisfied.

Before creating an instance ran the below command,
$ nova flavor-key m1.tiny set "hw:mem_page_size=large"

Now created an instance
$ nova boot --flavor m1.tiny --image cirros-0.3.4-x86_64-uec --nic
net-id=445e2dc5-221b-48ea-aea4-d04dee12fc7f --security-group default
demo-instance1

It gives the ERROR :

2015-11-23 13:19:59.654 ERROR nova.virt.libvirt.host
[req-2d9d060d-1934-4e9e-af1c-010e177bea11 None None] Connection to libvirt
failed: error from service: CheckAuthorization: Did not receive a reply.
Possible causes include: the remote application did not send a reply, the
message bus security policy blocked the reply, the reply timeout expired,
or the network connection was broken.
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host Traceback (most recent
call last):
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File
"/opt/stack/nova/nova/virt/libvirt/host.py", line 527, in get_connection
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host conn =
self._get_connection()
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File
"/opt/stack/nova/nova/virt/libvirt/host.py", line 514, in _get_connection
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host wrapped_conn =
self._get_new_connection()
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File
"/opt/stack/nova/nova/virt/libvirt/host.py", line 466, in
_get_new_connection
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host wrapped_conn =
self._connect(self._uri, self._read_only)
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File
"/opt/stack/nova/nova/virt/libvirt/host.py", line 320, in _connect
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host libvirt.openAuth,
uri, auth, flags)
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 141, in
proxy_call
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host rv = execute(f,
*args, **kwargs)
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 122, in
execute
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host six.reraise(c, e,
tb)
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 80, in
tworker
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host rv = meth(*args,
**kwargs)
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File
"/usr/local/lib/python2.7/dist-packages/libvirt.py", line 105, in openAuth
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host if ret is
None:raise libvirtError('virConnectOpenAuth() failed')
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host libvirtError: error
from service: CheckAuthorization: Did not receive a reply. Possible causes
include: the remote application did not send a reply, the message bus
security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host
Traceback (most recent call last):

I suspect this is because, I manually installed libvirt and qemu. My doubt
is why devstack is not installing a correct version when it is supposed to.
why a version less than min requirement is being installed???
Now that because am installing manually, there might be a problem with
groups - devstack creates some group and installs but manual installation
doesn't bother about that groups.
Can you please suggest a way on how do avoid that???

Also, I just want to make sure that the agent running is
neutron-openvswitch only. No ovsdpdk agent running.
$ ps -Al | grep neutron
0 S  1000  8882  8859  3  80   0 - 49946 ep_pol pts/34   00:02:24
neutron-openvsw

But
$ neutron agent-list
3385a430-5738-43cb-b853-059add5ab602 | DPDK OVS Agent |
ubuntu-Precision-Tower-5810 | :-)   | True   |
neutron-openvswitch-agent

So this implies that dpdk agent is running right??? I remember reading in
launchpad bugs that ovsdpdk agent is removed and that now openvswitch takes
care of everything. Just wanted to confirm that my setup has ovs-dpdk
running.

Regards,
Prathyusha

On Wed, Nov 18, 2015 at 7:23 PM, James Page  wrote:

> Hi Sean
>
> On Wed, Nov 18, 2015 at 12:30 PM, Mooney, Sean K 
> wrote:
>
>> Hi james
>>
>> Yes we are planning on testing the packaged release to see if it is
>> compatible with our ml2 driver

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

gord chung said on Fri, Nov 20, 2015 at 01:32:02PM -0500:
> On 20/11/15 11:33 AM, Alexis Lee wrote:
> >why would a producer spit out non-useful datapoints? If no-one cares
> >or will ever care, it simply shouldn't be included.
> 
> ... right now the
> producer is just sending out a grab bag of data that it thinks is
> important but doesn't define who the audience is. ...
>
> ... whoever the producer of notifications is, it should know it's
> audience.

Here I, with cdent, have to disagree. The criterion has to be
"potentially useful to someone", rather than tailoring production to the
known audience.

> >The problem is knowing what each consumer thinks is interesting and that
> >isn't something that can be handled by the producer.

^ this is important.

> the notification consumption service in ceilometer is essentially
> just a pipeline that normalises select incoming notifications into a
> data model(s) and pushes that model to whoever wants it (a known
> consumer is the storage service but it's configurable to allow other
> consumers).

It sounds like Ceilometer is performing a mapping function then and has
to be responsible for knowing how to do that. IE Ceilometer has to
express an opinion on relevance and presentation. This is inevitably
going to be a pain in the butt to maintain, but it's Ceilometer's job,
not the services, since it's Ceilometer trying to express an opinion.


Alexis (lxsli)
-- 
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

__
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] How are Tenant VMs' traffic routed to Service VMs

2015-11-23 Thread Yang, Yi Y

Sam, Thanks, But I failed to install two compute nodes if tacker is enabled, 
I’m not sure if tacker depends on Netron L3, can you share local.conf for two 
compute nodes case with tacker enabled.

From: Sam Hague [mailto:sha...@redhat.com]
Sent: Friday, November 20, 2015 9:19 PM
To: Yang, Yi Y 
Cc: openstack-dev@lists.openstack.org; Flavio Fernandes ; 
Tim Rozet ; Andre Fredette 
Subject: Re: [openstack-dev] [Neutron] How are Tenant VMs' traffic routed to 
Service VMs

Yi,

yes, you just create a router and connect the two networks to it. The router 
will ensure traffic works between the two networks/subnets. Add the router and 
then just add each subnet to the router. Something like the below:

neutron net-create vx-net --provider:network_type vxlan 
--provider:segmentation_id 1500
neutron net-create vx-net2 --provider:network_type vxlan 
--provider:segmentation_id 1501
neutron subnet-create vx-net 10.100.5.0/24 --name 
vx-subnet --dns-nameserver 8.8.8.8
neutron subnet-create vx-net2 10.100.6.0/24 --name 
vx-subnet2 --dns-nameserver 8.8.8.8

neutron net-create ext-net
neutron router-interface-add ext-rtr vx-subnet
neutron router-interface-add ext-rtr vx-subnet2

Thanks, Sam

On Fri, Nov 20, 2015 at 2:52 AM, Yang, Yi Y 
> wrote:
Hi, folks

I'm trying tacker to start some service VMs as Service Function VNF by "heat" 
tenant user, service VMs have special Neutron net & subnet, other common tenant 
VMs will have their own Neutron net & subnet, my question is how to route the 
traffic to service VMs in Openstack environment, DVR or router?

I integrated Opendaylight and used Opendaylight ML2 driver 
(https://github.com/openstack/networking-odl), in that case, I used its L3 
routing plugin instead of Neutron L3, I also integrated ovsdb, from ovsdb 
perspective, ARP response and L3 routing are done by openflow tables, so can 
openflow tables do the same thing to routing the traffic between tenant VMs and 
service VMs?

Network topology looks like the below diagram.

+--+

+--+
|Compute Node 1 |
|Compute Node 2   |
|   ||  
  |
|   ||  
  |
|   ||  
  |
|   ||  
  |
|   ||  
  |
|   ++  +-+   | 
   |   ++   +-+|
|   |Tenant VM1  |  |Service VMx  |   ||
   |Tenant VM2  |   |Service VMy||
|   | 10.0.0.3 |  | 11.0.0.3|   ||  
 | 10.0.0.4 |   | 11.0.0.4   ||
|   ||  ||   || 
  ||   |  ||
|   ||  ||   || 
  ||   |  ||
|   ||  ||   || 
  ||   |  ||
|   +---eth0---+  +eth0--+   |  
  |   +---eth0---+   +--eth0-+|
|  |   | || 
 |   | |
|  |   | || 
 |   | |
| tap0tap1   || 
tap0tap1|
|  |ovs| || 
  |ovs| |
|  +-br-int+ |  
  |   +br-int+ |
||   || 
|  |
|  ++---+ | 
   |   ++---+|
|  |   | ||

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

2015-11-23 Thread Mathieu Rohon

Thanks ihar!

On Thu, Nov 19, 2015 at 2:32 PM, Ihar Hrachyshka 
wrote:

> UPD: now that we have some understanding what’s needed from l2 agent
> extension mechanism to cater for interested subprojects (and now that we
> see that probably the agent in focus right now is OVS only), we may move to
> RFE step. I reported the following RFE for the feature:
>
> https://bugs.launchpad.net/neutron/+bug/1517903
>
> It may require BP if drivers team will request one.
>
> Cheers,
>
> Ihar
>
> Ihar Hrachyshka  wrote:
>
> Reviving the thread.
>>
>> On the design summit session dedicated to agent and plugin extensions [1]
>> the following was stated for l2 agent extensions (I appreciate if someone
>> checks me on the following though):
>>
>> - current l2 agent extensions mechanism lacks insight into agent details
>> like bridges or vlan maps;
>>
>> - in some cases, we don’t care about extension portability across
>> multiple agents, so it’s not of concern if some of them use implementation
>> details like bridges to set specific flows, or to wire up some additional
>> ports to them;
>>
>> - that said, we still don’t want extensions to have unlimited access to
>> agent details; the rationale for hard constraints on what is seen inside
>> extensions is that we cannot support backwards compatibility for *all*
>> possible internal attributes of an agent; instead, we should explicitly
>> define where we can make an effort to provide stable API into agent
>> details, and what’s, on contrary, beyond real life use cases and hence can
>> be left to be broken/refactored as neutron developers see fit; this API can
>> be agent specific though;
>>
>> - agent details that are to be passed into extensions should be driven by
>> actual use cases. There were several subprojects mentioned in the session
>> that are assumed to lack enough access to agent attributes to do their job
>> without patching core ovs agent files. Those are: BGP-VPN, SFC, (anything
>> else?) Those subprojects that are interested in extending l2 agent
>> extension framework are expected to come up with a list of things missing
>> in current implementation, so that neutron developers can agree on proper
>> abstractions to provide missing details to extensions. For that goal, I set
>> up a new etherpad to collect feedback from subprojects [2].
>>
>> Once we collect use cases there and agree on agent API for extensions
>> (even if per agent type), we will implement it and define as stable API,
>> then pass objects that implement the API into extensions thru extension
>> manager. If extensions support multiple agent types, they can still
>> distinguish between which API to use based on agent type string passed into
>> extension manager.
>>
>> I really hope we start to collect use cases early so that we have time to
>> polish agent API and make it part of l2 extensions earlier in Mitaka cycle.
>>
>> [1]: https://etherpad.openstack.org/p/mitaka-neutron-core-extensibility
>> [2]: https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion
>>
>> Ihar
>>
>> Ihar Hrachyshka  wrote:
>>
>> On 30 Sep 2015, at 12:53, Miguel Angel Ajo  wrote:



 Ihar Hrachyshka wrote:

> On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote:
>>
>> Hi Ihar,
>>
>> Ihar Hrachyshka :
>>
>>> Miguel Angel Ajo :

> Do you have a rough idea of what operations you may need to do?
>
 Right now, what bagpipe driver for networking-bgpvpn needs to
 interact with is:
 - int_br OVSBridge (read-only)
 - tun_br OVSBridge (add patch port, add flows)
 - patch_int_ofport port number (read-only)
 - local_vlan_map dict (read-only)
 - setup_entry_for_arp_reply method (called to add static ARP
 entries)

>>> Sounds very tightly coupled to OVS agent.
>>>
 Please bear in mind, the extension interface will be available from
> different agent types
> (OVS, SR-IOV, [eventually LB]), so this interface you're talking
> about could also serve as
> a translation driver for the agents (where the translation is
> possible), I totally understand
> that most extensions are specific agent bound, and we must be able
> to identify
> the agent we're serving back exactly.
>
 Yes, I do have this in mind, but what we've identified for now
 seems to be OVS specific.

>>> Indeed it does. Maybe you can try to define the needed pieces in
>>> high level actions, not internal objects you need to access to. Like ‘-
>>> connect endpoint X to Y’, ‘determine segmentation id for a network’ etc.
>>>
>> I've been thinking about this, but would tend to reach the conclusion
>> that the things we need to interact with are pretty hard to abstract out
>> into something that would be

Re: [openstack-dev] [Glance] M-1 Bugs/Reviews squash day


On 19/11/15 10:32 -0300, Flavio Percoco wrote:

On 16/11/15 16:45 -0300, Flavio Percoco wrote:

Greetings,

At our last meeting, we discussed the idea of having a Bug/Reviews
squash day before the end of M-1. I'm sending this email out to
propose that we do this work on one of the following dates:

- Friday November 20th (ALL TZs)
- Monday November 23rd (ALL TZs)

I realize that next week is Thanksgiving in the US and some folks
might want to take the whole week. Please, do vote before Wednesday
18th so we can prepare for Friday and/or monday.

Poll link: http://doodle.com/poll/mt7hwswtmcvmetdn


The Bug/Review squash day will be Monday November 23rd. You can check
the results in the poll link.



Gentle reminder that this is *TODAY* :D

Here's an etherpad where I'll be putting some notes and guidance as we
go (I should've sent this out on Friday, sorry). Please, put the
bugs/reviews you work on as part of this squash day in that etherpad!

https://etherpad.openstack.org/p/glance-review-bug-squash-day

Thanks,
Flavio


Thanks and looking forwrd to Monday!
Flavio

--
@flaper87
Flavio Percoco





__
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



--
@flaper87
Flavio Percoco


signature.asc
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] [nova] Migration progress

2015-11-23 Thread John Garbutt

On 23 November 2015 at 08:36, Paul Carlton  wrote:
> John
>
> At the live migration sub team meeting I undertook to look at the issue
> of progress reporting.
>
> The use cases I'm envisaging are...
>
> As a user I want to know how much longer my instance will be migrating
> for.
>
> As an operator I want to identify any migration that are making slow
>  progress so I can expedite their progress or abort them.

+1

Agreed with this need.

Proposals to add pause and cancel clearly make this need more acute.

> The current implementation reports on the instance's migration with
> respect to memory transfer, using the total memory and memory remaining
> fields from libvirt to report the percentage of memory still to be
> transferred.  Due to the instance writing to pages already transferred
> this percentage can go up as well as down.  Daniel has done a good job
> of generating regular log records to report progress and highlight lack
> of progress but from the API all a user/operator can see is the current
> percentage complete.  By observing this periodically they can identify
> instance migrations that are struggling to migrate memory pages fast
> enough to keep pace with the instance's memory updates.
>
> The problem is that at present we have only one field, the instance
> progress, to record progress.  With a live migration there are measures
> of progress, how much of the ephemeral disks (not needed for shared
> disk setups) have been copied and how much of the memory has been
> copied. Both can go up and down as the instance writes to pages already
> copied causing those pages to need to be copied again.  As Daniel says
> in his comments in the code, the disk size could dwarf the memory so
> reporting both in single percentage number is problematic.
>
> We could add an additional progress item to the instance object, i.e.
> disk progress and memory progress but that seems odd to have an
> additional progress field only for this operation so this is probably
> a non starter!
>
> For operations staff with access to log files we could report disk
> progress as well as memory in the log file, however that does not
> address the needs of users and whilst log files are the right place for
> support staff to look when investigating issues operational tooling
> is much better served by notification messages.
>
> Thus I'd recommend generating periodic notifications during a migration
> to report both memory and disk progress would be useful?  Cloud
> operators are likely to manage their instance migration activity using
> some orchestration tooling which could consume these notifications and
> deduce what challenges the instance migration is encountering and thus
> determine how to address any issues.

To be clear, our notifications are not designed to be consumed by end users.

> The use cases are only partially addressed by the current
> implementation, they can repeatedly get the server details and look at
> the progress percentage to see how quickly (or even if) it is
> increasing and determine how long the instance is likely to be
> migrating for.  However for an instance that has a large disk and/or
> is doing a high rate of disk i/o they may see the percentage complete
> (i.e. memory) repeatedly showing 90%+ but the instance migration does
> not complete.

Agreed reporting progress, particularly with live-migrate, is awful right now.

Long term, I have my eye on this work:
https://etherpad.openstack.org/p/liberty-cross-project-user-notifications

But we should work on getting a good conceptual model for the progress
that can be exposed using the above system.

> The nova spec https://review.openstack.org/#/c/248472/ suggests making
> detailed information available via the os-migrations object.  This is
> not a bad idea but I have some issues with the implementation that I
> will share on that spec.

We do also need something that works across all hypervisor types.

Lets talk more on that spec review.

Thanks,
johnthetubaguy

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

[openstack-dev] [devstack]Question about using Devstack

2015-11-23 Thread Young Yang

Hi,
I'm using devstack to deploy stable/Kilo in my Xenserver.
I successfully deploy devstack. But I found that every time I restart it,
devstack always run ./stack.sh to clear all my data and resintall all the
components.
So here comes  the questions.

1) Can I stop devstack from reinstalling after rebooting and just use the
openstack installed successfully last time.
I've tried  replacing the stack.sh with another blank shell script to stop
it running. Then  It didn't reinstall the services after rebooting.
However, some services didn't start successfully.

2) I found that devstack will exit if it is unable to connect the Internet
when rebooting.
Is there any way I can reboot devstack successfully without connection to
the Internet after I've install it successfully with connection to the
Internet.

Thanks in advance !  :)
__
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][nova]Move encryptors to os-brick

On Fri, Nov 20, 2015 at 02:44:17PM -0500, Ben Swartzlander wrote:
> On 11/20/2015 01:19 PM, Daniel P. Berrange wrote:
> >On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote:
> >>Brick does not have to take over the decisions in order to be a useful
> >>repository for the code. The motivation for this work is to avoid having
> >>the dm setup code copied wholesale into cinder, where it becomes difficult
> >>to keep in sync with the code in nova.
> >>
> >>Cinder needs a copy of this code since it is on the data path for certain
> >>operations (create from image, copy to image, backup/restore, migrate).
> >
> >A core goal of using volume encryption in Nova to provide protection for
> >tenant data, from a malicious storage service. ie if the decryption key
> >is only ever used by Nova on the compute node, then cinder only ever sees
> >ciphertext, never plaintext.  Thus if cinder is compromised, then it can
> >not compromise any data stored in any encrypted volumes.
> 
> There is a difference between the cinder service and the storage controller
> (or software system) that cinder manages. You can give the decryption keys
> to the cinder service without allowing the storage controller to see any
> plaintext.
> 
> As Walt says in the relevant patch [1], expecting cinder to do data
> management without ever performing I/O is unrealistic. The scenario where
> the compute admin doesn't trust the storage admin is understandable
> (although less important than other potential types of attacks IMO) but the
> scenario where the guy managing nova doesn't trust the guy managing cinder
> makes no sense at all.

So you are implicitly saying here that the cinder admin is different from
the storage admin. While that certainly may often be true, I strugle to
categorically say it is always going to be true.

Furthermore it is not only about the trust of the cinder administrator,
but rather trust of the integrity of the cinder service. OpenStack has
a great many components that are open to attack, and it is prudent to
design the system such that successfull security attacks are confined
to as large a degree as possible. From this POV I think it is entirely
reasonable & indeed sensible for Nova to have minimal trust of Cinder
as a whole when it comes to tenant data security.

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

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

Re: [openstack-dev] [devstack]Question about using Devstack

2015-11-23 Thread Jordan Pittier

Hi

On Mon, Nov 23, 2015 at 11:58 AM, Young Yang  wrote:

> Hi,
> I'm using devstack to deploy stable/Kilo in my Xenserver.
> I successfully deploy devstack. But I found that every time I restart it,
> devstack always run ./stack.sh to clear all my data and resintall all the
> components.
> So here comes  the questions.
>
> 1) Can I stop devstack from reinstalling after rebooting and just use the
> openstack installed successfully last time.
> I've tried  replacing the stack.sh with another blank shell script to stop
> it running. Then  It didn't reinstall the services after rebooting.
> However, some services didn't start successfully.
>
No. As far as I know, if you reboot your server you need to relaunch
./stack.sh. . Because, but not only, your IP address (on which some
services bind to) could have changed.

>
> 2) I found that devstack will exit if it is unable to connect the Internet
> when rebooting.
> Is there any way I can reboot devstack successfully without connection to
> the Internet after I've install it successfully with connection to the
> Internet.
>
After a successful install, you can start devstack again with the "offline
mode": OFFLINE=yes ./stack.sh

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

Re: [openstack-dev] [nova] FKs in the DB

Matt Riedemann said on Fri, Nov 20, 2015 at 12:58:55PM -0600:
> On 11/20/2015 10:19 AM, Alexis Lee wrote:
> >Should we drive one way or the other, or just put up with mixed-mode?
> For the record, I hate the mixed mode.

+1

> >What should be the policy for new relations?
> I prefer consistency, so if we're adding new relationships I'd
> prefer to see that they have foreign keys.

This seems to align with what Mike's saying. I'll see about a patch to
add a FK to bw_usage_cache. I have a horrible feeling dansmith will be
smacking me on the nose soon but c'est la vie Nova.

> >Do the answers to these questions depend on having a sane and
> >comprehensive archive/purge system in place?
> 
> I'm not sure. The problems this is causing with archive/purge is
> that I thought to fix archive all we had to do was reverse sort the
> tables, which was working until it turned out we weren't soft
> deleting instance_actions. But now it also turns out that we aren't
> soft deleting bw_usage_cache *and* we don't have a FKey from that
> back to the instances table, so it's just completely orphaned and
> never archived or deleted, thus leaving that task up to the
> xenserver operator (since the xenserver driver is the only one that
> implements the virt driver API to populate this table).
> 
> So again, now we have to have special hack code paths in the
> archive/purge code to account for this mixed mode schema.

Are you using the schema to decide how to archive/purge? I thought you
just had a big list of tables?

Anyway it seems like having the FK is both more consistent and makes
your life easier, so let's add it.


Alexis (lxsli)
-- 
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

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

Re: [openstack-dev] [devstack]Question about using Devstack

Hi,

Devstack is intended for development, so when you reboot it is not expecting to 
be able to preserve any information, and will give you a fresh environment to 
continue development on.

The XenServer devstack installation uses a separate VM, but devstack is 
automatically run at boot, as there is no information preserved.  It should 
also delete any VMs that were running from the previous devstack run while it 
is starting up.


1)  Unfortunately not; starting of the services is tightly coupled with the 
setup and there is an assumption that *anything* may have changed (from IPs to 
configuration in localrc)

2)  Possibly; but my understanding is it would be quite tricky.  Devstack 
assumes access to the Ubuntu repositories as well as various other sources for 
pip, URLs for images and probably others.

I know that Mirantis OpenStack can work without internet access 
(https://www.mirantis.com/blog/using-fuel-control-repositories-openstack-deployment/)
 and there is a XenServer plugin for Fuel available from 
https://www.mirantis.com/products/openstack-drivers-and-plugins/fuel-plugins/
Check out 
https://www.citrix.com/blogs/2015/10/23/deploying-mirantis-openstack-on-a-single-xenserver/
 for an easy guide to set this environment up on a single XenServer host, or 
https://git.openstack.org/cgit/openstack/fuel-plugin-xenserver/plain/doc/user-guide.pdf?h=6.1
 for the user guide

Thanks,

Bob

From: Young Yang [mailto:afe.yo...@gmail.com]
Sent: 23 November 2015 10:59
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [devstack]Question about using Devstack

Hi,
I'm using devstack to deploy stable/Kilo in my Xenserver.
I successfully deploy devstack. But I found that every time I restart it, 
devstack always run ./stack.sh to clear all my data and resintall all the 
components.
So here comes  the questions.

1) Can I stop devstack from reinstalling after rebooting and just use the 
openstack installed successfully last time.
I've tried  replacing the stack.sh with another blank shell script to stop it 
running. Then  It didn't reinstall the services after rebooting.  However, some 
services didn't start successfully.

2) I found that devstack will exit if it is unable to connect the Internet when 
rebooting.
Is there any way I can reboot devstack successfully without connection to the 
Internet after I've install it successfully with connection to the Internet.

Thanks in advance !  :)
__
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][nova]Move encryptors to os-brick

On Fri, Nov 20, 2015 at 11:34:29AM -0800, Walter A. Boring IV wrote:
> On 11/20/2015 10:19 AM, Daniel P. Berrange wrote:
> >On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote:
> >>Brick does not have to take over the decisions in order to be a useful
> >>repository for the code. The motivation for this work is to avoid having
> >>the dm setup code copied wholesale into cinder, where it becomes difficult
> >>to keep in sync with the code in nova.
> >>
> >>Cinder needs a copy of this code since it is on the data path for certain
> >>operations (create from image, copy to image, backup/restore, migrate).
> >A core goal of using volume encryption in Nova to provide protection for
> >tenant data, from a malicious storage service. ie if the decryption key
> >is only ever used by Nova on the compute node, then cinder only ever sees
> >ciphertext, never plaintext.  Thus if cinder is compromised, then it can
> >not compromise any data stored in any encrypted volumes.
> >
> >If cinder is looking to get access to the dm-seutp code, this seems to
> >imply that cinder will be getting access to the plaintext data, which
> >feels to me like it de-values the volume encryption feature somewhat.
> >
> >I'm fuzzy on the details of just what code paths cinder needs to be
> >able to convert from plaintext to ciphertext or vica-verca, but in
> >general I think it is desirable if we can avoid any such operation
> >in cinder, and keep it so that only Nova compute nodes ever see the
> >decrypted data.
> Being able to limit the number of points where an encrypted volume can be
> used unencrypted
> is obviously a good goal.
> Unfortunately, it's entirely unrealistic to expect Cinder to never be able
> to have access that access.
>
> Cinder currently needs access to write data to volumes that are encrypted
> for several operations.
> 
> 1) copy volume to image

If a volume is encrypted and it is being copied to an image, IMHO we
should not aim to decrypt it. We should copy the data as is and mark
the image as encrypted in glance, and then use it as is next time the
image is needed.

FYI, Nova is already aiming to consider both the glance data storage
and the glance service as a whole, as untrustworthy. The first step
in this is using cryptographic signatures to detect unauthorized
image data modification by a compromised glance. Encryption will be
a later step in the process.

> 2) copy image to volume

This is semi-plausible as a place where Cinder needs to go from
unencrypted image data to encrypted volume data, when a user is
creating a volume from an image ahead of time, distinct from any
VM boot attempt. In such a case it is desirable that Cinder not
be able to request any existing volume keys from the key server,
merely have the ability to upload new keys and throw away its
local copy thereafter.

> 3) backup

Cinder should really not try to decrypt volumes when backing them
up. If it conversely wants to encrypt volumes during backup, it
can do so with separate backup keys, distinct from those used for
primary volume encryption for use at runtime.

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

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

Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

2015-11-23 Thread Ihar Hrachyshka

UPD: note that there turned out to be complications with using  
#openstack-meeting-2 for the meeting, so we’ll have it in  
#openstack-meeting-3 this week, and I’ll follow up on getting the -2  
channel an official status this week. I will join the -2 channel anyway to  
update folks who could miss the notice.


Ihar

Ihar Hrachyshka  wrote:

UPD: I have added an agenda page for the subteam:  
https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam


Feel free to fill in, and see you all on Mon 15:00 UTC.

Ihar

Ihar Hrachyshka  wrote:


Thanks everyone for responses.

It seems like Mon 15:00 UTC works for all of us, so I pushed the  
following patch to book #openstack-meeting-2 room weekly:


https://review.openstack.org/246949

Ihar

Rossella Sblendido  wrote:


Hi Ihar,

same for me, all options are ok!

cheers,

Rossella

On 11/12/2015 11:00 PM, Martin Hickey wrote:

Hi Ihar,

Any of those options would suit me, thanks.

Cheers,
Martin




From:   Ihar Hrachyshka 
To: "OpenStack Development Mailing List (not for usage questions)"
 
Date:   12/11/2015 21:39
Subject:Re: [openstack-dev] [neutron][upgrade] new 'all things
 upgrade'   subteam



Artur  wrote:


My TZ is UTC +1:00.
Do we have any favorite day? Maybe Tuesday?


I believe Tue is already too packed with irc meetings to be considered  
(we


have, for the least, main neutron meetings and neutron-drivers meetings
there).

We have folks in US and Central Europe and Russia and Japan… I believe  
the


best time would be somewhere around 13:00 to 15:00 UTC (that time would
still be ‘before midnight' for Japan; afternoon for Europe, and  
morning for


US East Coast).

I have checked neutron meetings at [1], and I see that we have 13:00 UTC
slots free for all days; 14:00 UTC slot available for Thu; and 15:00 UTC
slots for Mon and Fri (I don’t believe we want to have it on Fri  
though).

Also overall Mondays are all free.

Should I create a doodle for those options? Or are there any alternative
suggestions?

[1]:
http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/meetings

Ihar

__
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 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] [devstack]Question about using Devstack

Ah yes - I’d forgotten about OFFLINE=True (shows how often I use it!)

If you set this in your localrc file then yes, in theory it should work offline 
– but will still generate a new environment when you reboot the VM.

Bob

From: yatin kumbhare [mailto:yatinkumbh...@gmail.com]
Sent: 23 November 2015 11:24
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [devstack]Question about using Devstack

Use OFFLINE=True in localrc - by this you can run devstack without internet 
access.

Use rejoin-stack.sh - this will create all your screens, and will not delete 
your data.

make sure rabbitmq and mysql is runnig.

Always do ./unstack.sh before reboot, this will cleanup resources. check screen 
-ls, the stack screen should have been deleted.

if not, run ./unstack.sh again.

Regards,
Yatin

On Mon, Nov 23, 2015 at 4:38 PM, Jordan Pittier 
> wrote:
Hi

On Mon, Nov 23, 2015 at 11:58 AM, Young Yang 
> wrote:
Hi,
I'm using devstack to deploy stable/Kilo in my Xenserver.
I successfully deploy devstack. But I found that every time I restart it, 
devstack always run ./stack.sh to clear all my data and resintall all the 
components.
So here comes  the questions.

1) Can I stop devstack from reinstalling after rebooting and just use the 
openstack installed successfully last time.
I've tried  replacing the stack.sh with another blank shell script to stop it 
running. Then  It didn't reinstall the services after rebooting.  However, some 
services didn't start successfully.
No. As far as I know, if you reboot your server you need to relaunch 
./stack.sh. . Because, but not only, your IP address (on which some services 
bind to) could have changed.

2) I found that devstack will exit if it is unable to connect the Internet when 
rebooting.
Is there any way I can reboot devstack successfully without connection to the 
Internet after I've install it successfully with connection to the Internet.
After a successful install, you can start devstack again with the "offline 
mode": OFFLINE=yes ./stack.sh

Thanks in advance !  :)

__
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] [nova] FKs in the DB

Julien Danjou said on Fri, Nov 20, 2015 at 05:52:59PM +0100:
> On Fri, Nov 20 2015, Alexis Lee wrote:
> > We just had a fun discussion in IRC about whether foreign keys are evil.
> > Initially I thought this was crazy but mordred made some good points. To
> > paraphrase, that if you have a scale-out app already it's easier to
> > manage integrity in your app than scale-out your persistence layer.
> 
> That's interesting. Could you explain how it is easier to achieve the
> level of data integrity provided by a RDBMS implementing ACID in your
> own application?

What I said is that it can be easier (not easy) to manage integrity in
your app than scale-out your persistence layer (which gets very
hard/costly). It's harder to achieve the same level of integrity in your
app without using RDBMS constraints as with them. However, data
integrity /can/ be preserved in other ways than RDBMS constraints, while
persistence layer performance caps that of the whole system. Assuming
you've added enough workers to find the limit.

Alexis (lxsli)
-- 
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

__
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] Security Groups OVS conntrack support

2015-11-23 Thread Fawad Khaliq

On Mon, Nov 23, 2015 at 3:08 PM, Jakub Libosvar  wrote:

> On 11/22/2015 07:28 PM, Gal Sagie wrote:
> > Hi Fawad,
> >
> > From what i could understand from Miguel Angel Ajo, someone is working
> > on this integration and it
> > is suppose to be delivered as part of Mitaka.
> > I don't remember the person name, Miguel will sure update shortly.
> >
> > Gal.
>
> Hi Fawad, Gal,
>
> I'm the person working on ovs firewall. There is reported an rfe bug [1]
> to tracking it.
>

Hi Kuba,

Great. We (Kuryr team) wanted insight into the plans for this support.
Thanks for the note and link to the bug. I think we are all set to take the
discussions further.

Fawad


> Kuba
>
> [1] https://bugs.launchpad.net/neutron/+bug/1461000
> >
> > On Sun, Nov 22, 2015 at 7:05 PM, Fawad Khaliq  > > wrote:
> >
> > Folks,
> >
> > Is there a plan to add conntrack support to the security groups for
> > the OVS driver in Mitaka cycle?
> >
> > My understanding is that it is being actively worked on for
> > networking-ovn but no concrete plan for support in the OVS Neutron
> > driver yet.
> >
> > Thanks,
> > Fawad Khaliq
> >
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Best Regards ,
> >
> > The G.
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Bug day! Yeah!

2015-11-23 Thread Martin Pavlásek

Count with me tomorrow! :-)

Martin


On 20/11/15 01:02, Lin Hua Cheng wrote:
> Great, I'll be around next Tuesday.
>
> -Lin
>
> On Thu, Nov 19, 2015 at 12:53 PM, Rob Cresswell (rcresswe)  > wrote:
>
> As requested,
> https://etherpad.openstack.org/p/horizon-bug-day
>
> Rob
>
> From: Richard Jones  >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  >
> Date: Thursday, 19 November 2015 20:39
> To: "OpenStack Development Mailing List (not for usage questions)"
>  >
> Subject: Re: [openstack-dev] [Horizon] Bug day! Yeah!
>
> Let's do it. I'd like to suggest we use an etherpad to keep track of what
> people have done. If it's not created when I start my day, I'll make one.
>
>
>  Richard
>
> On 19 November 2015 at 22:19, Rob Cresswell (rcresswe)  > wrote:
>
> Hey folks,
>
> Our bug list is… rather large. We’ve discussed having a bug day, where
> as a community we all dedicate some time to triaging bugs and
> discussing in the IRC channel as we go.
>
> First off, see the docs about bug
> triage: https://wiki.openstack.org/wiki/BugTriage
>
> Secondly, lets pick a date. I’d suggest next Tuesday (24th November);
> if that doesn’t work for a good number of us, then the following
> Tuesday (1st December). Trying to account for Thanksgiving :)
>
> Rob
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Security Groups OVS conntrack support

2015-11-23 Thread Tapio Tallgren

Hi,

Sorry for the stupid question, but how will I use the connection tracking
in security groups? Is there an extension to the Neutron API call "add
security group rule" that allows for connection tracking, or this for FWaaS
only?

-Tapio

On Mon, Nov 23, 2015 at 12:39 PM Fawad Khaliq  wrote:

> On Mon, Nov 23, 2015 at 3:08 PM, Jakub Libosvar 
> wrote:
>
>> On 11/22/2015 07:28 PM, Gal Sagie wrote:
>> > Hi Fawad,
>> >
>> > From what i could understand from Miguel Angel Ajo, someone is working
>> > on this integration and it
>> > is suppose to be delivered as part of Mitaka.
>> > I don't remember the person name, Miguel will sure update shortly.
>> >
>> > Gal.
>>
>> Hi Fawad, Gal,
>>
>> I'm the person working on ovs firewall. There is reported an rfe bug [1]
>> to tracking it.
>>
>
> Hi Kuba,
>
> Great. We (Kuryr team) wanted insight into the plans for this support.
> Thanks for the note and link to the bug. I think we are all set to take the
> discussions further.
>
> Fawad
>
>
>> Kuba
>>
>> [1] https://bugs.launchpad.net/neutron/+bug/1461000
>> >
>> > On Sun, Nov 22, 2015 at 7:05 PM, Fawad Khaliq > > > wrote:
>> >
>> > Folks,
>> >
>> > Is there a plan to add conntrack support to the security groups for
>> > the OVS driver in Mitaka cycle?
>> >
>> > My understanding is that it is being actively worked on for
>> > networking-ovn but no concrete plan for support in the OVS Neutron
>> > driver yet.
>> >
>> > Thanks,
>> > Fawad Khaliq
>> >
>> >
>> >
>>  __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > <
>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > Best Regards ,
>> >
>> > The G.
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] FKs in the DB

2015-11-23 Thread Jordan Pittier

Hi,

However, data
> integrity /can/ be preserved in other ways than RDBMS constraints, while
> persistence layer performance caps that of the whole system

Is the DB the limiting factor of openstack performance ? De we have hard
evidence of this ? We need numbers before acting otherwise it will be an
endless discussion.

When I look at the number of race conditions we had/have in OpenStack, it
seems scary to remove the FK in the DB. FK look like a "guardian" to me and
we should aim at enforcing more consistency/integrity, not the contrary.

Also, this is an open source project with contributors with different
skills and experience (beginners, part time contributor etc.). Maybe this
is something to also consider.

Jordan
__
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] Security Groups OVS conntrack support

2015-11-23 Thread Fawad Khaliq

Hi Tapio,

This is an improvement in the lower implementation layer where to support
security groups, previously, we needed to have both OVS and linux bridges.
With an improvement in OVS, this can be avoided and we will only need OVS
bridge. This does not affect the user interface to security groups in terms
of API nor it is a new functionality from a user point of view. Please see
this bug [1] for more details. Hope that clarifies.

P.S. Here's a link [2], which capture some internals of networking that you
might be interested in :-)

[1] https://bugs.launchpad.net/neutron/+bug/1461000
[2] https://www.rdoproject.org/networking/networking-in-too-much-detail/

Fawad Khaliq


On Mon, Nov 23, 2015 at 3:55 PM, Tapio Tallgren 
wrote:

> Hi,
>
> Sorry for the stupid question, but how will I use the connection tracking
> in security groups? Is there an extension to the Neutron API call "add
> security group rule" that allows for connection tracking, or this for FWaaS
> only?
>
> -Tapio
>
> On Mon, Nov 23, 2015 at 12:39 PM Fawad Khaliq  wrote:
>
>> On Mon, Nov 23, 2015 at 3:08 PM, Jakub Libosvar 
>> wrote:
>>
>>> On 11/22/2015 07:28 PM, Gal Sagie wrote:
>>> > Hi Fawad,
>>> >
>>> > From what i could understand from Miguel Angel Ajo, someone is working
>>> > on this integration and it
>>> > is suppose to be delivered as part of Mitaka.
>>> > I don't remember the person name, Miguel will sure update shortly.
>>> >
>>> > Gal.
>>>
>>> Hi Fawad, Gal,
>>>
>>> I'm the person working on ovs firewall. There is reported an rfe bug [1]
>>> to tracking it.
>>>
>>
>> Hi Kuba,
>>
>> Great. We (Kuryr team) wanted insight into the plans for this support.
>> Thanks for the note and link to the bug. I think we are all set to take the
>> discussions further.
>>
>> Fawad
>>
>>
>>> Kuba
>>>
>>> [1] https://bugs.launchpad.net/neutron/+bug/1461000
>>> >
>>> > On Sun, Nov 22, 2015 at 7:05 PM, Fawad Khaliq >> > > wrote:
>>> >
>>> > Folks,
>>> >
>>> > Is there a plan to add conntrack support to the security groups for
>>> > the OVS driver in Mitaka cycle?
>>> >
>>> > My understanding is that it is being actively worked on for
>>> > networking-ovn but no concrete plan for support in the OVS Neutron
>>> > driver yet.
>>> >
>>> > Thanks,
>>> > Fawad Khaliq
>>> >
>>> >
>>> >
>>>  __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > <
>>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Best Regards ,
>>> >
>>> > The G.
>>> >
>>> >
>>> >
>>> __
>>> > 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack]Question about using Devstack

2015-11-23 Thread Oleksii Zamiatin

On Mon, Nov 23, 2015 at 12:58 PM, Young Yang  wrote:

> Hi,
> I'm using devstack to deploy stable/Kilo in my Xenserver.
> I successfully deploy devstack. But I found that every time I restart it,
> devstack always run ./stack.sh to clear all my data and resintall all the
> components.
> So here comes  the questions.
>
> 1) Can I stop devstack from reinstalling after rebooting and just use the
> openstack installed successfully last time.
> I've tried  replacing the stack.sh with another blank shell script to stop
> it running. Then  It didn't reinstall the services after rebooting.
> However, some services didn't start successfully.
>

try rejoin-stack.sh - it is in the same folder as unstack.sh, stack.sh


>
> 2) I found that devstack will exit if it is unable to connect the Internet
> when rebooting.
> Is there any way I can reboot devstack successfully without connection to
> the Internet after I've install it successfully with connection to the
> Internet.
>
> Thanks in advance !  :)
>
> __
> 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] [devstack]Question about using Devstack

2015-11-23 Thread yatin kumbhare

Use OFFLINE=True in localrc - by this you can run devstack without internet
access.

Use rejoin-stack.sh - this will create all your screens, and will not
delete your data.

make sure rabbitmq and mysql is runnig.

Always do ./unstack.sh before reboot, this will cleanup resources. check
screen -ls, the stack screen should have been deleted.

if not, run ./unstack.sh again.

Regards,
Yatin


On Mon, Nov 23, 2015 at 4:38 PM, Jordan Pittier 
wrote:

> Hi
>
> On Mon, Nov 23, 2015 at 11:58 AM, Young Yang  wrote:
>
>> Hi,
>> I'm using devstack to deploy stable/Kilo in my Xenserver.
>> I successfully deploy devstack. But I found that every time I restart it,
>> devstack always run ./stack.sh to clear all my data and resintall all the
>> components.
>> So here comes  the questions.
>>
>> 1) Can I stop devstack from reinstalling after rebooting and just use the
>> openstack installed successfully last time.
>> I've tried  replacing the stack.sh with another blank shell script to
>> stop it running. Then  It didn't reinstall the services after rebooting.
>> However, some services didn't start successfully.
>>
> No. As far as I know, if you reboot your server you need to relaunch
> ./stack.sh. . Because, but not only, your IP address (on which some
> services bind to) could have changed.
>
>>
>> 2) I found that devstack will exit if it is unable to connect the
>> Internet when rebooting.
>> Is there any way I can reboot devstack successfully without connection to
>> the Internet after I've install it successfully with connection to the
>> Internet.
>>
> After a successful install, you can start devstack again with the "offline
> mode": OFFLINE=yes ./stack.sh
>
>>
>> Thanks in advance !  :)
>>
>> __
>> 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] [stable] Making stable maintenance its own OpenStack project team

2015-11-23 Thread Thierry Carrez

Thierry Carrez wrote:
> [...]
> I'm mostly away this week at a conference, but now that we have a list
> of names, we should set up a meeting early next week to further discuss
> team goals and initial leadership.

We'll be holding a preliminary meeting today (Monday) at 15:00 UTC in
#openstack-meeting-4, for those interested.

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [oslo] Should we make qpid/proton optional dependencies? (please say yes)

2015-11-23 Thread Victor Stinner


Hi,

Would it be possible to use the "extra dependencies" thing in setup.cfg? 
Robert Collins started a similar change for Oslo DB for make DB drivers 
optional:

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

Sadly, this change was not merged yet.

@Robert: any progress on this change?

It would allow to ask for "Oslo Messaging with Qpid support" in service 
dependencies, without knowning the exact required Python packages for Qpid.


Victor

Le 19/11/2015 19:22, Matt Riedemann a écrit :

I want to fix a thing in oslo.messaging but to my surprise I can't run
pep8. This is because python-qpid-proton tries to install qpid-proton
and it can't get that because the apache site where it's hosted is down.
[1]

The apache site for qpid has actually been down a lot lately, I
coincidentally know that because of trying to access QPID security
issues for backports to things like Grizzly - yay for me!

Anyway, depending on a 3rd party repo like this to get packages just to
run pep8/unit tests in oslo.messaging is the suck.  Can we make this
optional?  Isn't the qpid stuff in tree deprecated anyway?

[1] http://paste.openstack.org/show/479460/



__
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] [Fuel] [Fuel UI] Support of separate provisioning is blocked by backend issues

2015-11-23 Thread Evgeniy L

Hi,

I have several comments, just to make sure, that we are on the same page
here.
Current API calls for provisioning/deployment are used by developers and
fuel hackers,
and by design there was removed all validation. So shouldn't there be some
more
user friendly API calls which have validation? For example we don't run any
pre
deployment checks and network validation, you can even ask to deploy
offline nodes.
As result novice user can easily break her/his cluster.

Thanks,

On Fri, Nov 13, 2015 at 11:46 AM, Julia Aranovich 
wrote:

> Hi fuelers,
>
> Currently Fuel UI team is working on blueprint [1] to give Fuel UI user an
> ability to launch provisioning of environment nodes separately from
> deployment (without choosing particular nodes for now).
>
> In the process we were faced with the following issues. Some of them block
> the blueprint:
>
>- deployment constantly failed on environment with pre-provisioned
>nodes [2]
>- node pending_addition flag is reset to False for provisioned nodes
>[3]. This causes a lot of UX problems: provisioned node roles, disks,
>interfaces can not be reconfigured, node can not be deleted from
>environment, just can be marked as pending deletion (that requires
>environment deployment)
>- completed provisioning task has Null message. So, there is no to
>show the user after provisioning finished [4]
>- no notification comes on UI after provisioned finished [5]
>- fake provisioning task is also should be fixed: environment nodes
>stay in 'provisioning' status after provisioning finished [6]. This breaks
>fake Fuel UI workflow and brings difficulties in Fuel UI development.
>
> Could you please consider/fix the tickets and help to unblock the
> blueprint targeted for the current release.
>
> Also, you can check how provisioning works in Fuel UI on #547 custom 8.0
> ISO.
>
> Thank you!
> Julia
>
> [1]
> https://blueprints.launchpad.net/fuel/+spec/support-separate-provisioning-and-deployment-in-ui
> [2] https://bugs.launchpad.net/fuel/+bug/1515903
> [3] https://bugs.launchpad.net/fuel/+bug/1515898
> [4] https://bugs.launchpad.net/fuel/+bug/1515895
> [5] https://bugs.launchpad.net/fuel/+bug/1515891
> [6] https://bugs.launchpad.net/fuel/+bug/1515893
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Security Groups OVS conntrack support

2015-11-23 Thread Jakub Libosvar

On 11/22/2015 07:28 PM, Gal Sagie wrote:
> Hi Fawad,
> 
> From what i could understand from Miguel Angel Ajo, someone is working
> on this integration and it
> is suppose to be delivered as part of Mitaka.
> I don't remember the person name, Miguel will sure update shortly.
> 
> Gal.

Hi Fawad, Gal,

I'm the person working on ovs firewall. There is reported an rfe bug [1]
to tracking it.

Kuba

[1] https://bugs.launchpad.net/neutron/+bug/1461000
> 
> On Sun, Nov 22, 2015 at 7:05 PM, Fawad Khaliq  > wrote:
> 
> Folks,
> 
> Is there a plan to add conntrack support to the security groups for
> the OVS driver in Mitaka cycle? 
> 
> My understanding is that it is being actively worked on for
> networking-ovn but no concrete plan for support in the OVS Neutron
> driver yet.
> 
> Thanks,
> Fawad Khaliq
> 
> 
> __
> 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 ,
> 
> The G.
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [nova] Versioned notifications... who cares about the version?

2015-11-23 Thread John Garbutt

On 20 November 2015 at 09:37, Balázs Gibizer
 wrote:
>> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
>> Sent: November 19, 2015 23:29
>> On 11/19/2015 4:05 PM, Ryan Rossiter wrote:
>> > Reading through [1] I started getting worries in the back of my head
>> > about versioning these notifications. The main concern being how can
>> > the consumer know about the versions and what's different between
>> them?
>> > Because these versioned notification payloads hold live nova objects,
>> > there can be a lot of rug-pulling going on underneath these
>> > notifications. If the payload doesn't pin itself to a certain level of
>> > the object, a consumer can never be guaranteed the version of the
>> > payload's object they will be receiving. I ran through a few of the
>> > scenarios about irregular versions in the notifications subteam
>> > meeting on Tuesday [2].
>> >
>> > My question is do we care about the consumer? Or is it a case of
>> > "the consumer is always right" so we need to make sure we hand them
>> > super consistent, well-defined blobs across the wire? Consumers will
>> > have no idea of nova object internals, unless they feel like `python
>> > -c import nova`. I do think we get one piece of help from o.vo though.
>> > When the object is serialized, it hands the version with the object.
>> > So consumers can look at the object and say "oh, I got 1.4 I know what
>> > to do with this". But... they will have to implement their own compat
>> > logic. Everyone will have to implement their own compat logic.
>> >
>> > We could expose a new API for getting the schema for a specific
>> > version of a notification, so a consumer will know what they're
>> > getting with their notifications. But I think that made mriedem
>> > nauseous. We could make an oslo library that stuffs a shim in between
>> > o.vo and nova's notifications to help out with compat/versioning, but
>> > that sounds like a lot of work, especially because the end goal is still 
>> > not
>> clearly defined.
>>
>> The term is 'nauseated'. To be nauseous, you nauseate others. Which I might
>> do from time to time.
>>
>> Sorry, I'm channeling one of my wives' pet peeves because I say the same
>> thing. Sometimes just to annoy her.
>>
>> But yeah, I was made physically ill from that idea.
>>
>> >
>> > Thoughts?
>> >
>> > [1] https://review.openstack.org/#/c/247024
>> > [2]
>> > http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-
>> alt/%23ope
>> > nstack-meeting-alt.2015-11-17.log.html#t2015-11-17T20:22:29
>> >
>> >
>>
>> One idea I had was (and maybe this would be in a separate library like you're
>> talking about, i.e. nova-notifications), but if nova emits the notification 
>> with
>> the version and the consumer calls into the library that translates it into a
>> version they want, then get that transformed thing back.
>>
>> However, how does the consumer know what they want or what they can
>> handle? Do they pin a version in configuration somewhere? I could see
>> something like how we have upgrade levels pinned in nova so newer
>> conductor can backlevel things for older computes.
>>
>> I was also thinking about microversions and novaclient, but in that case
>> novaclient knows what max microversion it can handle and only requests up
>> to that version, and then nova-api handles the compat work. In the case of
>> notifications, nova is just broadcasting those so it's not doing any compat
>> work, but it's the only thing that knows *how* to do the compat work...
>>
>> So yeah, I'm lost.
>
> Minor version change shall not cause any problem for the consumer as the 
> payload is backward compatible between minor versions. So if the consumer 
> does not need the new field then he/she does not need to change anything in 
> his/her parser. As far as I know we had a single major object version in nova 
> so far so this is not a frequent event.  In case of major change I think we 
> can offer version pinning from nova via configuration as a future step.
>
> The library idea has the problem that it would be python lib and consumers 
> can be in any language. For me lib would be used for compat code but as I 
> mentioned above incompatibility is not that frequent. In the other hand 
> discoverability of notifications are more important for me. For that I can 
> suggest providing notification samples as a first step so the consumer can 
> see in the source tree what notifications are provided by the nova. As a 
> natural next step would be to provide not just samples but schemas for the 
> notifications. I haven't looked it too deep but I feel if we provide json 
> schema for the notifications then the consumer can generate an object model 
> from that schema without too much effort. It might not help directly with 
> backporting the payload but at least automate things around it. The json 
> schema has the benefit that it is language independent too.
>

So, on re-reading, I think we are missing some

Re: [openstack-dev] [nova] Migration progress

2015-11-23 Thread Paul Carlton




On 23/11/15 11:02, John Garbutt wrote:

On 23 November 2015 at 08:36, Paul Carlton  wrote:

John

At the live migration sub team meeting I undertook to look at the issue
of progress reporting.

The use cases I'm envisaging are...

As a user I want to know how much longer my instance will be migrating
for.

As an operator I want to identify any migration that are making slow
  progress so I can expedite their progress or abort them.

+1

Agreed with this need.

Proposals to add pause and cancel clearly make this need more acute.


The current implementation reports on the instance's migration with
respect to memory transfer, using the total memory and memory remaining
fields from libvirt to report the percentage of memory still to be
transferred.  Due to the instance writing to pages already transferred
this percentage can go up as well as down.  Daniel has done a good job
of generating regular log records to report progress and highlight lack
of progress but from the API all a user/operator can see is the current
percentage complete.  By observing this periodically they can identify
instance migrations that are struggling to migrate memory pages fast
enough to keep pace with the instance's memory updates.

The problem is that at present we have only one field, the instance
progress, to record progress.  With a live migration there are measures
of progress, how much of the ephemeral disks (not needed for shared
disk setups) have been copied and how much of the memory has been
copied. Both can go up and down as the instance writes to pages already
copied causing those pages to need to be copied again.  As Daniel says
in his comments in the code, the disk size could dwarf the memory so
reporting both in single percentage number is problematic.

We could add an additional progress item to the instance object, i.e.
disk progress and memory progress but that seems odd to have an
additional progress field only for this operation so this is probably
a non starter!

For operations staff with access to log files we could report disk
progress as well as memory in the log file, however that does not
address the needs of users and whilst log files are the right place for
support staff to look when investigating issues operational tooling
is much better served by notification messages.

Thus I'd recommend generating periodic notifications during a migration
to report both memory and disk progress would be useful?  Cloud
operators are likely to manage their instance migration activity using
some orchestration tooling which could consume these notifications and
deduce what challenges the instance migration is encountering and thus
determine how to address any issues.

To be clear, our notifications are not designed to be consumed by end users.

Yep, I see this as something cloud operations tooling could consume.
It does not address end user's needs.



The use cases are only partially addressed by the current
implementation, they can repeatedly get the server details and look at
the progress percentage to see how quickly (or even if) it is
increasing and determine how long the instance is likely to be
migrating for.  However for an instance that has a large disk and/or
is doing a high rate of disk i/o they may see the percentage complete
(i.e. memory) repeatedly showing 90%+ but the instance migration does
not complete.

Agreed reporting progress, particularly with live-migrate, is awful right now.

Long term, I have my eye on this work:
https://etherpad.openstack.org/p/liberty-cross-project-user-notifications

But we should work on getting a good conceptual model for the progress
that can be exposed using the above system.


The nova spec https://review.openstack.org/#/c/248472/ suggests making
detailed information available via the os-migrations object.  This is
not a bad idea but I have some issues with the implementation that I
will share on that spec.

We do also need something that works across all hypervisor types.

Lets talk more on that spec review.

Thanks,
johnthetubaguy


--
Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Mobile:+44 (0)7768 994283
Email:mailto:paul.carlt...@hpe.com
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN 
Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may be 
legally privileged. If you have received this message in error, you should delete it from 
your system immediately and advise the sender. To any recipient of this message within 
HP, unless otherwise stated you should consider this message and attachments as "HP 
CONFIDENTIAL".




smime.p7s
Description: S/MIME Cryptographic Signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

[openstack-dev] [Fuel] Important notice about running tests for python-fuelclient

2015-11-23 Thread Roman Prykhodchenko

Hi fulers!
I’d like to let you know that because of the bug [1] in tox 2.2.1 we had to 
change [2] tox.ini temporarily to unlock the gate until the author of tox is 
working on the fix for the problem. Those changes in tox.ini revoke all freedom 
of configuring how tests on one’s local environment are run, so all environment 
variables except FUEL_WEB_ROOT and TEST_NAILGUN_DB are ignored.
Please also note, that setting those two variables is now _mandatory_ — tests 
will fail with strange errors, if that is not done. I will keep you updated as 
soon as tox is fixed and the temporary changes to tox.ini are reverted.

- romcheg




signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [puppet] mime-types-data requires Ruby version >= 2.0

2015-11-23 Thread Iury Gregory

Move to ruby 2.0 is going to give us more problems? If yes, pin mime-types
=)

2015-11-23 5:20 GMT-03:00 Emilien Macchi :

> Because of [1], [2] and [3]: all beaker-rspec-dsvm-trusty jobs are broken.
>
> The only one option I see is to pin mime-types in beaker dependencies,
> because beaker needs frog and frog needs mime-types.
>
> Note beaker is currently broken for ubuntu trusty nodes, because of this
> change.
>
> [1]
> https://github.com/mime-types/mime-types-data/releases/tag/v3.2015.1120
> [2] https://github.com/mime-types/mime-types-data/blob/master/Rakefile#L16
> [3] fog requires mime-types (>= 0)
> --
> Emilien Macchi
>
>
> __
> 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
>
>


-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@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][nova]Move encryptors to os-brick

2015-11-23 Thread Duncan Thomas

Hi Daniel

Much of this got discussed before.

Encrypted images uploaded to glance aren't shareable, and there is
definitely a desire by many users to keep the usual glance functionality
while having encryption at rest in cinder for e.g. regulatory purposes.

There is also some desire to be able to migrate unencrypted volume types to
encrypted types inside cinder, which would require cinder to be able to
create an encrypted volume in a similar way to creating from an image.


Managing access to the key data is, as far as I'm aware, the job of e.g.
barbican/castellan, not nova per se. There are several usecases for
encryption, and several of the less paranoid make good sense without
requiring nova to be the only thing with access to the key material.


On 23 November 2015 at 13:21, Daniel P. Berrange 
wrote:

> On Fri, Nov 20, 2015 at 11:34:29AM -0800, Walter A. Boring IV wrote:
> > On 11/20/2015 10:19 AM, Daniel P. Berrange wrote:
> > >On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote:
> > >>Brick does not have to take over the decisions in order to be a useful
> > >>repository for the code. The motivation for this work is to avoid
> having
> > >>the dm setup code copied wholesale into cinder, where it becomes
> difficult
> > >>to keep in sync with the code in nova.
> > >>
> > >>Cinder needs a copy of this code since it is on the data path for
> certain
> > >>operations (create from image, copy to image, backup/restore, migrate).
> > >A core goal of using volume encryption in Nova to provide protection for
> > >tenant data, from a malicious storage service. ie if the decryption key
> > >is only ever used by Nova on the compute node, then cinder only ever
> sees
> > >ciphertext, never plaintext.  Thus if cinder is compromised, then it can
> > >not compromise any data stored in any encrypted volumes.
> > >
> > >If cinder is looking to get access to the dm-seutp code, this seems to
> > >imply that cinder will be getting access to the plaintext data, which
> > >feels to me like it de-values the volume encryption feature somewhat.
> > >
> > >I'm fuzzy on the details of just what code paths cinder needs to be
> > >able to convert from plaintext to ciphertext or vica-verca, but in
> > >general I think it is desirable if we can avoid any such operation
> > >in cinder, and keep it so that only Nova compute nodes ever see the
> > >decrypted data.
> > Being able to limit the number of points where an encrypted volume can be
> > used unencrypted
> > is obviously a good goal.
> > Unfortunately, it's entirely unrealistic to expect Cinder to never be
> able
> > to have access that access.
> >
> > Cinder currently needs access to write data to volumes that are encrypted
> > for several operations.
> >
> > 1) copy volume to image
>
> If a volume is encrypted and it is being copied to an image, IMHO we
> should not aim to decrypt it. We should copy the data as is and mark
> the image as encrypted in glance, and then use it as is next time the
> image is needed.
>
> FYI, Nova is already aiming to consider both the glance data storage
> and the glance service as a whole, as untrustworthy. The first step
> in this is using cryptographic signatures to detect unauthorized
> image data modification by a compromised glance. Encryption will be
> a later step in the process.
>
> > 2) copy image to volume
>
> This is semi-plausible as a place where Cinder needs to go from
> unencrypted image data to encrypted volume data, when a user is
> creating a volume from an image ahead of time, distinct from any
> VM boot attempt. In such a case it is desirable that Cinder not
> be able to request any existing volume keys from the key server,
> merely have the ability to upload new keys and throw away its
> local copy thereafter.
>
> > 3) backup
>
> Cinder should really not try to decrypt volumes when backing them
> up. If it conversely wants to encrypt volumes during backup, it
> can do so with separate backup keys, distinct from those used for
> primary volume encryption for use at runtime.
>
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [devstack]Question about using Devstack

2015-11-23 Thread Jordan Pittier

On Mon, Nov 23, 2015 at 1:29 PM, Young Yang  wrote:

> Really thanks for responsing so rapidly!!
>
> @ozamiatin
> I forget to mention that I've run rejoin-stack.sh and  manually started
> apache.
> However,  something is not still properly configured.  Such as  lvm volume
> group is not created.
>
> @jordan.pittier
> Really thanks for you  OFFLINE advice. It make some thing offline now. But
> it fails finally.
> It gives such error.
> I tried both OFFLINE=True and OFFLINE=yes in my local rc.
>
> venv create: /opt/stack/tempest/.tox/venv
>> venv installdeps: -r/opt/stack/tempest/requirements.txt,
>> -r/opt/stack/tempest/test-requirements.txt
>> ERROR: invocation failed (exit code 1), logfile:
>> /opt/stack/tempest/.tox/venv/log/venv-1.log
>> ERROR: actionid: venv
>> msg: getenv
>> cmdargs: [local('/opt/stack/tempest/.tox/venv/bin/pip'), 'install', '-U',
>> '-r/opt/stack/tempest/requirements.txt',
>> '-r/opt/stack/tempest/test-requirements.txt']
>> env: {'UPSTART_EVENTS': 'stopped', 'LOGNAME': 'stack', 'USER': 'stack',
>> 'os_RELEASE': '14.04', 'OS_REGION_NAME': 'RegionOne',
>> .. NOTICE I ignore some error here
>> 
>>  Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after
>> connection broken by 'ProtocolError('Connection aborted.', gaierror(-2,
>> 'Name or service not known'))': /simple/pbr/
>>   Could not find a version that satisfies the requirement pbr>=1.6 (from
>> -r /opt/stack/tempest/requirements.txt (line 1)) (from versions: )
>> No matching distribution found for pbr>=1.6 (from -r
>> /opt/stack/tempest/requirements.txt (line 1))
>> ERROR: could not install deps [-r/opt/stack/tempest/requirements.txt,
>> -r/opt/stack/tempest/test-requirements.txt]; v =
>> InvocationError('/opt/stack/tempest/.tox/venv/bin/pip install -U
>> -r/opt/stack/tempest/requirements.txt
>> -r/opt/stack/tempest/test-requirements.txt (see
>> /opt/stack/tempest/.tox/venv/log/venv-1.log)', 1)
>> ___ summary
>> 
>> ERROR:   venv: could not install deps
>> [-r/opt/stack/tempest/requirements.txt,
>> -r/opt/stack/tempest/test-requirements.txt]; v =
>> InvocationError('/opt/stack/tempest/.tox/venv/bin/pip install -U
>> -r/opt/stack/tempest/requirements.txt
>> -r/opt/stack/tempest/test-requirements.txt (see
>> /opt/stack/tempest/.tox/venv/log/venv-1.log)', 1)
>> Error on exit
>> World dumping... see /opt/stack/logs/worlddump-2015-11-23-121956.txt for
>> details
>
>
I think this could be a bug in devstack. In lib/tempest we call 'tox
-revenv -- verify-tempest-config' which forces to recreate the virtual env
and thus requires an internet connection. I am not sure what's the best way
to deal with it now, but you can try to comment out this particular line
or, if you don"t need tempest add a "disable_service tempest" in your
local.conf

>
>
> @Bob Ball
> Thanks your mirantis offline advice, I'll try it later :)
>
> @yatinkumbhare
> thanks, I'll try it latter.
>
> @jordan.pittier  @Bob Ball
> If I can ensure my IP address , localrc and everything else are not
> changed, is there any way I can achieve my goal?
>
>
>
>
> On Mon, Nov 23, 2015 at 7:07 PM, Oleksii Zamiatin 
> wrote:
>
>>
>>
>> On Mon, Nov 23, 2015 at 12:58 PM, Young Yang  wrote:
>>
>>> Hi,
>>> I'm using devstack to deploy stable/Kilo in my Xenserver.
>>> I successfully deploy devstack. But I found that every time I restart
>>> it, devstack always run ./stack.sh to clear all my data and resintall all
>>> the components.
>>> So here comes  the questions.
>>>
>>> 1) Can I stop devstack from reinstalling after rebooting and just use
>>> the openstack installed successfully last time.
>>> I've tried  replacing the stack.sh with another blank shell script to
>>> stop it running. Then  It didn't reinstall the services after rebooting.
>>> However, some services didn't start successfully.
>>>
>>
>> try rejoin-stack.sh - it is in the same folder as unstack.sh, stack.sh
>>
>>
>>>
>>> 2) I found that devstack will exit if it is unable to connect the
>>> Internet when rebooting.
>>> Is there any way I can reboot devstack successfully without connection
>>> to the Internet after I've install it successfully with connection to the
>>> Internet.
>>>
>>> Thanks in advance !  :)
>>>
>>>
>>> __
>>> 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] Location of TripleO REST API

2015-11-23 Thread Dmitry Tantsur


On 11/17/2015 04:31 PM, Tzu-Mainn Chen wrote:






On 10 November 2015 at 15:08, Tzu-Mainn Chen > wrote:

Hi all,

At the last IRC meeting it was agreed that the new TripleO REST API
should forgo the Tuskar name, and simply be called... the TripleO
API.  There's one more point of discussion: where should the API
live?  There are two possibilities:

a) Put it in tripleo-common, where the business logic lives.  If we
do this, it would make sense to rename tripleo-common to simply
tripleo.


+1 - I think this makes most sense if we are not going to support
the tripleo repo as a library.


Okay, this seems to be the consensus, which is great.

The leftover question is how to package the renamed repo.  'tripleo' is
already intuitively in use by tripleo-incubator.
In IRC, bnemec and trown suggested splitting the renamed repo into two
packages - 'python-tripleo' and 'tripleo-api',
which seems sensible to me.


-1, that would be inconsistent with what other projects are doing. I 
guess tripleo-incubator will die soon, and I think only tripleo devs 
have any intuition about it. For me tripleo == instack-undercloud.




What do others think?


Mainn


b) Put it in its own repo, tripleo-api


The first option made a lot of sense to people on IRC, as the
proposed
API is a very thin layer that's bound closely to the code in
tripleo-
common.  The major objection is that renaming is not trivial;
however
it was mentioned that renaming might not be *too* bad... as long as
it's done sooner rather than later.

What do people think?


Thanks,
Tzu-Mainn Chen


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

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



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




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




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

Re: [openstack-dev] [stable] Post-release bump after 2014.2.4?

2015-11-23 Thread Ihar Hrachyshka


Vincent Untz  wrote:


Le lundi 23 novembre 2015, à 13:17 +0100, Ihar Hrachyshka a écrit :

Vincent Untz  wrote:


Hi,

I know 2014.2.4 is (in theory) the last juno release, but I'd still
expect to see a post-release bump to 2014.2.5 in git, to avoid any
confusion as to what lives in git. This is especially useful if people
build new tarballs from git.

Any objection against this, before I send patches? :-)

Cheers,

Vincent


I probably miss something, but why do we care about what is in the
branch now that we don’t plan to merge anything more there? Is it to
accommodate for downstream consumers that may want to introduce more
patches on top of the upstream tag?


As I said: because people might keep generating tarballs from git, and
they'd expect to have a version that is correct. Yes, this is mostly
downstreams. (And not necessarily to introduce more patches, but just to
reflect the reality).

I would also argue that we care because we're leaving git in a state
that is kind of wrong (since the version is not correct).


Can you elaborate why it’s incorrect? It’s 2014.2.4 right? So that’s indeed  
what you get if you generate tarballs from latest commits in those  
branches; it should totally reflect the contents that are in official  
tarballs and hence have the same version.


Note that the question ‘what lives in git [branches]’ will be irrelevant  
once we drop those branches and merely leave juno-eol tags that, I assume,  
will point to exact tags that were used to generate the last tarballs. Or  
do you also suggest juno-eol != 2014.2.4?


Ihar

__
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] [Oslo][all] Major bump in oslo library version today (Drop py2.6)

2015-11-23 Thread Davanum Srinivas

So... Today Oslo libraries will be dropping python 2.6 support and
bumping up their Major versions.

Details are here:
https://review.openstack.org/#/c/248391/

Tested the py27/py34 tox targets for 8 openstack projects:
https://travis-ci.org/dims/

Thanks,
Dims

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

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

Re: [openstack-dev] [puppet] mime-types-data requires Ruby version >= 2.0

2015-11-23 Thread Emilien Macchi



On 11/23/2015 12:45 PM, Iury Gregory wrote:
> Move to ruby 2.0 is going to give us more problems? If yes, pin
> mime-types =)

Ruby 2.0 is not supported & shipped by Ubuntu Trusty (Current LTS). So
we have to support Ruby 1.x until Ubuntu 16.01 (next LTS), which should
be end of mitaka cycle.

> 
> 2015-11-23 5:20 GMT-03:00 Emilien Macchi  >:
> 
> Because of [1], [2] and [3]: all beaker-rspec-dsvm-trusty jobs are
> broken.
> 
> The only one option I see is to pin mime-types in beaker dependencies,
> because beaker needs frog and frog needs mime-types.
> 
> Note beaker is currently broken for ubuntu trusty nodes, because of this
> change.
> 
> [1]
> https://github.com/mime-types/mime-types-data/releases/tag/v3.2015.1120
> [2]
> https://github.com/mime-types/mime-types-data/blob/master/Rakefile#L16
> [3] fog requires mime-types (>= 0)
> --
> Emilien Macchi
> 
> 
> __
> 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
> 
> 
> 
> 
> -- 
> 
> ~
> /Att[]'s
> Iury Gregory Melo Ferreira 
> //Master student in Computer Science at UFCG/
> /E-mail:  iurygreg...@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
> 

-- 
Emilien Macchi



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

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

2015-11-23 Thread Aleksandr Maretskiy

Hi all,

as you know, Rally runs inside docker on Fuel master node, so docker
removal (good improvement) is a problem for Rally users.

To solve this, I'm planning to make native Rally installation on Fuel
master node that is running on CentOS 7,
and then make a step-by-step instruction how to make this installation.

So I hope docker removal will not make issues for Rally users.

On Mon, Nov 23, 2015 at 12:28 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> ETA:
>
> experimental ISO w/o docker: tonight
> spec: tomorrow night
>
>
>
> Vladimir Kozhukalov
>
> On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova <
> aurlap...@mirantis.com> wrote:
>
>> @Vova,
>> thanks for bringing this up.
>> The new approach without docker containers on master node really has many
>> advantages.
>>
>> @Igor,
>> regarding your question, I would say that we have many dependencies from
>> containers in CI/CD systems and test's codebase. The test alignment to the
>> new implementation won't be easy. In such things we should move forward
>> step by step.
>> As you know the first step is a spec file, can you give us a link to it?
>>
>>
>> Nastya.
>>
>> On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh 
>> wrote:
>>
>>> With CentOS7 we will have python2.7 at Fuel Admin node as a default
>>> version, I believe.
>>>
>>> --
>>> Best regards,
>>> Oleg Gelbukh,
>>> Principal Engineer
>>> Mirantis
>>>
>>> On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov <
>>> tnurlygaya...@mirantis.com> wrote:
>>>
 Hi Andrey,

 As far as I remember from the last usage of fuel master node, there was
> Centos + py26 installation. Python 2.6 is old enough and sometimes it is
> hard to launch some application on fuel node without docker (image with
> py27/py3). Are you planning to provide py27 at least or my note is 
> outdated
> and I can already use py27 from the box?

 We can install docker on master node anyway to run Rally / Tempest or
 other test suites and scripts from master node with Python 2.7 or something
 also.

 On Fri, Nov 20, 2015 at 5:20 PM, Andrey Kurilin 
 wrote:

> Hi!
> I'm not fuel developer, so opinion below is based on user-view.
> As far as I remember from the last usage of fuel master node, there
> was Centos + py26 installation. Python 2.6 is old enough and sometimes it
> is hard to launch some application on fuel node without docker (image with
> py27/py3). Are you planning to provide py27 at least or my note is 
> outdated
> and I can already use py27 from the box?
>
> On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> As might remember, we introduced Docker containers on the master node
>> a while ago when we implemented first version of Fuel upgrade feature. 
>> The
>> motivation behind was to make it possible to rollback upgrade process if
>> something goes wrong.
>>
>> Now we are at the point where we can not use our tarball based
>> upgrade approach any more and those patches that deprecate upgrade 
>> tarball
>> has been already merged. Although it is a matter of a separate 
>> discussion,
>> it seems that upgrade process rather should be based on kind of backup 
>> and
>> restore procedure. We can backup Fuel data on an external media, then we
>> can install new version of Fuel from scratch and then it is assumed 
>> backed
>> up Fuel data can be applied over this new Fuel instance. The procedure
>> itself is under active development, but it is clear that rollback in this
>> case would be nothing more than just restoring from the previously backed
>> up data.
>>
>> As for Docker containers, still there are potential advantages of
>> using them on the Fuel master node, but our current implementation of the
>> feature seems not mature enough to make us benefit from the
>> containerization.
>>
>> At the same time there are some disadvantages like
>>
>>- it is tricky to get logs and other information (for example,
>>rpm -qa) for a service like shotgun which is run inside one of 
>> containers.
>>- it is specific UX when you first need to run dockerctl shell
>>{container_name} and then you are able to debug something.
>>- when building IBP image we mount directory from the host file
>>system into mcollective container to make image build faster.
>>- there are config files and some other files which should be
>>shared among containers which introduces unnecessary complexity to the
>>whole system.
>>- our current delivery approach assumes we wrap into rpm/deb
>>packages every single piece of the Fuel system. Docker images are not 
>> an
>>exception. And as far as they depend on

Re: [openstack-dev] [Fuel] Important notice about running tests for python-fuelclient

2015-11-23 Thread Maciej Kwiek

Missing links from this email:
[1]
https://bitbucket.org/hpk42/tox/issues/285/tox-220-breaks-some-toxini-config-files
[2] https://review.openstack.org/#/c/247452/6

On Mon, Nov 23, 2015 at 12:45 PM, Roman Prykhodchenko  wrote:

> Hi fulers!
> I’d like to let you know that because of the bug [1] in tox 2.2.1 we had
> to change [2] tox.ini temporarily to unlock the gate until the author of
> tox is working on the fix for the problem. Those changes in tox.ini revoke
> all freedom of configuring how tests on one’s local environment are run, so
> all environment variables except FUEL_WEB_ROOT and TEST_NAILGUN_DB are
> ignored.
> Please also note, that setting those two variables is now _mandatory_ —
> tests will fail with strange errors, if that is not done. I will keep you
> updated as soon as tox is fixed and the temporary changes to tox.ini are
> reverted.
>
> - romcheg
>
>
>
> __
> 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] [Fuel] [Fuel UI] Support of separate provisioning is blocked by backend issues

2015-11-23 Thread Vitaly Kramskikh

Evgeniy,

That's also a good point. Due to all these issues and need to significantly
change Nailgun for this feature we decided to move it out of 8.0 and come
back to it in the next release so that we can design and implement
everything properly.

2015-11-23 16:49 GMT+07:00 Evgeniy L :

> Hi,
>
> I have several comments, just to make sure, that we are on the same page
> here.
> Current API calls for provisioning/deployment are used by developers and
> fuel hackers,
> and by design there was removed all validation. So shouldn't there be some
> more
> user friendly API calls which have validation? For example we don't run
> any pre
> deployment checks and network validation, you can even ask to deploy
> offline nodes.
> As result novice user can easily break her/his cluster.
>
> Thanks,
>
> On Fri, Nov 13, 2015 at 11:46 AM, Julia Aranovich  > wrote:
>
>> Hi fuelers,
>>
>> Currently Fuel UI team is working on blueprint [1] to give Fuel UI user
>> an ability to launch provisioning of environment nodes separately from
>> deployment (without choosing particular nodes for now).
>>
>> In the process we were faced with the following issues. Some of them
>> block the blueprint:
>>
>>- deployment constantly failed on environment with pre-provisioned
>>nodes [2]
>>- node pending_addition flag is reset to False for provisioned nodes
>>[3]. This causes a lot of UX problems: provisioned node roles, disks,
>>interfaces can not be reconfigured, node can not be deleted from
>>environment, just can be marked as pending deletion (that requires
>>environment deployment)
>>- completed provisioning task has Null message. So, there is no to
>>show the user after provisioning finished [4]
>>- no notification comes on UI after provisioned finished [5]
>>- fake provisioning task is also should be fixed: environment nodes
>>stay in 'provisioning' status after provisioning finished [6]. This breaks
>>fake Fuel UI workflow and brings difficulties in Fuel UI development.
>>
>> Could you please consider/fix the tickets and help to unblock the
>> blueprint targeted for the current release.
>>
>> Also, you can check how provisioning works in Fuel UI on #547 custom 8.0
>> ISO.
>>
>> Thank you!
>> Julia
>>
>> [1]
>> https://blueprints.launchpad.net/fuel/+spec/support-separate-provisioning-and-deployment-in-ui
>> [2] https://bugs.launchpad.net/fuel/+bug/1515903
>> [3] https://bugs.launchpad.net/fuel/+bug/1515898
>> [4] https://bugs.launchpad.net/fuel/+bug/1515895
>> [5] https://bugs.launchpad.net/fuel/+bug/1515891
>> [6] https://bugs.launchpad.net/fuel/+bug/1515893
>>
>>
>> __
>> 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
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] [rating] CloudKitty 23rd meeting agenda

2015-11-23 Thread Stéphane Albert

Hi,

I'm back from Japan, we'll start having regular meetings again.

Here's today's agenda:

* New contributions
* Gnocchi support
* Pending reviews
* Road to version 0.5
* Next version goals

During this meeting we need to iron out remaining bugs to prepare
release 0.5. As soon as this version is released we'll move forward and
transition to the Mitaka cycle.
I want to define every version goals and migration/update possibilities.
We'll deprecate old code and transition to new and robust one.

Feel free to join us at 2PM UTC today.

Cheers

__
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] [stable] Post-release bump after 2014.2.4?

2015-11-23 Thread Ihar Hrachyshka


Vincent Untz  wrote:


Hi,

I know 2014.2.4 is (in theory) the last juno release, but I'd still
expect to see a post-release bump to 2014.2.5 in git, to avoid any
confusion as to what lives in git. This is especially useful if people
build new tarballs from git.

Any objection against this, before I send patches? :-)

Cheers,

Vincent


I probably miss something, but why do we care about what is in the branch  
now that we don’t plan to merge anything more there? Is it to accommodate  
for downstream consumers that may want to introduce more patches on top of  
the upstream tag?


Ihar

__
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] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

2015-11-23 Thread AFEK, Ifat (Ifat)

Hi,

We have a couple of questions regarding AODH alarms.

In Vitrage[1] project we have two use cases that involve Ceilometer: 

1. Import Ceilometer alarms, as well as alarms and resources from other sources 
(Nagios, Zabbix, Nova, Heat, etc.), and produce RCA insights about the 
connection between different alarms.
2. Raise "deduced alarms". For example, in case we detect a high memory 
consumption on a host, we would like to raise deduced alarms saying "instance 
might be suffering due to high memory consumption on the host" on all related 
instances. Then, we can further deduce that applications running on these 
instances might also be affected, and raise alarms on them as well.

Initially we planned to raise these deduced alarms in AODH, so other Openstack 
components may consume them as well. Then, when we looked at AODH alarms 
documentation, we noticed that there is currently no way of raising custom 
alarms. We saw only three types of alarms: threshold alarms, combination alarms 
and event alarms.

So, our questions are: 

* Is there an alternative way of raising alarms in AODH?
* Do you think custom alarms belong in AODH? Are you interested in adding this 
capability to AODH? 

We would be happy to hear your vision and thoughts about it.


Thanks,
Ifat and Alexey.


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




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

Re: [openstack-dev] [devstack]Question about using Devstack

2015-11-23 Thread Young Yang

Really thanks for responsing so rapidly!!

@ozamiatin
I forget to mention that I've run rejoin-stack.sh and  manually started
apache.
However,  something is not still properly configured.  Such as  lvm volume
group is not created.

@jordan.pittier
Really thanks for you  OFFLINE advice. It make some thing offline now. But
it fails finally.
It gives such error.
I tried both OFFLINE=True and OFFLINE=yes in my local rc.

venv create: /opt/stack/tempest/.tox/venv
> venv installdeps: -r/opt/stack/tempest/requirements.txt,
> -r/opt/stack/tempest/test-requirements.txt
> ERROR: invocation failed (exit code 1), logfile:
> /opt/stack/tempest/.tox/venv/log/venv-1.log
> ERROR: actionid: venv
> msg: getenv
> cmdargs: [local('/opt/stack/tempest/.tox/venv/bin/pip'), 'install', '-U',
> '-r/opt/stack/tempest/requirements.txt',
> '-r/opt/stack/tempest/test-requirements.txt']
> env: {'UPSTART_EVENTS': 'stopped', 'LOGNAME': 'stack', 'USER': 'stack',
> 'os_RELEASE': '14.04', 'OS_REGION_NAME': 'RegionOne',
> .. NOTICE I ignore some error here
> 
>  Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after
> connection broken by 'ProtocolError('Connection aborted.', gaierror(-2,
> 'Name or service not known'))': /simple/pbr/
>   Could not find a version that satisfies the requirement pbr>=1.6 (from
> -r /opt/stack/tempest/requirements.txt (line 1)) (from versions: )
> No matching distribution found for pbr>=1.6 (from -r
> /opt/stack/tempest/requirements.txt (line 1))
> ERROR: could not install deps [-r/opt/stack/tempest/requirements.txt,
> -r/opt/stack/tempest/test-requirements.txt]; v =
> InvocationError('/opt/stack/tempest/.tox/venv/bin/pip install -U
> -r/opt/stack/tempest/requirements.txt
> -r/opt/stack/tempest/test-requirements.txt (see
> /opt/stack/tempest/.tox/venv/log/venv-1.log)', 1)
> ___ summary
> 
> ERROR:   venv: could not install deps
> [-r/opt/stack/tempest/requirements.txt,
> -r/opt/stack/tempest/test-requirements.txt]; v =
> InvocationError('/opt/stack/tempest/.tox/venv/bin/pip install -U
> -r/opt/stack/tempest/requirements.txt
> -r/opt/stack/tempest/test-requirements.txt (see
> /opt/stack/tempest/.tox/venv/log/venv-1.log)', 1)
> Error on exit
> World dumping... see /opt/stack/logs/worlddump-2015-11-23-121956.txt for
> details




@Bob Ball
Thanks your mirantis offline advice, I'll try it later :)

@yatinkumbhare
thanks, I'll try it latter.

@jordan.pittier  @Bob Ball
If I can ensure my IP address , localrc and everything else are not
changed, is there any way I can achieve my goal?




On Mon, Nov 23, 2015 at 7:07 PM, Oleksii Zamiatin 
wrote:

>
>
> On Mon, Nov 23, 2015 at 12:58 PM, Young Yang  wrote:
>
>> Hi,
>> I'm using devstack to deploy stable/Kilo in my Xenserver.
>> I successfully deploy devstack. But I found that every time I restart it,
>> devstack always run ./stack.sh to clear all my data and resintall all the
>> components.
>> So here comes  the questions.
>>
>> 1) Can I stop devstack from reinstalling after rebooting and just use the
>> openstack installed successfully last time.
>> I've tried  replacing the stack.sh with another blank shell script to
>> stop it running. Then  It didn't reinstall the services after rebooting.
>> However, some services didn't start successfully.
>>
>
> try rejoin-stack.sh - it is in the same folder as unstack.sh, stack.sh
>
>
>>
>> 2) I found that devstack will exit if it is unable to connect the
>> Internet when rebooting.
>> Is there any way I can reboot devstack successfully without connection to
>> the Internet after I've install it successfully with connection to the
>> Internet.
>>
>> Thanks in advance !  :)
>>
>> __
>> 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] [Fuel] Getting rid of Docker containers on the Fuel master node

2015-11-23 Thread Matthew Mosesohn

Bogdan brings up a good point. fuel-createmirror in its current state pulls
down an Ubuntu container and uses apt utilities inside. I know it's being
replaced, but it's one instance of an item that might be overlooked by this
process.

On Mon, Nov 23, 2015 at 3:27 PM, Bogdan Dobrelya 
wrote:

> On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
> > Hi all,
> >
> > as you know, Rally runs inside docker on Fuel master node, so docker
> > removal (good improvement) is a problem for Rally users.
> >
> > To solve this, I'm planning to make native Rally installation on Fuel
> > master node that is running on CentOS 7,
> > and then make a step-by-step instruction how to make this installation.
> >
> > So I hope docker removal will not make issues for Rally users.
>
> I believe the most backwards compatible scenario is to keep the docker
> installed while removing the fuel-* docker things back to the host OS.
> So nothing would prevent user from pulling and running whichever docker
> containers he wants to put on the Fuel master node. Makes sense?
>
> >
> > On Mon, Nov 23, 2015 at 12:28 PM, Vladimir Kozhukalov
> > > wrote:
> >
> > ETA:
> >
> > experimental ISO w/o docker: tonight
> > spec: tomorrow night
> >
> >
> >
> > Vladimir Kozhukalov
> >
> > On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova
> > > wrote:
> >
> > @Vova,
> > thanks for bringing this up.
> > The new approach without docker containers on master node really
> > has many advantages.
> >
> > @Igor,
> > regarding your question, I would say that we have many
> > dependencies from containers in CI/CD systems and test's
> > codebase. The test alignment to the new implementation won't be
> > easy. In such things we should move forward step by step.
> > As you know the first step is a spec file, can you give us a
> > link to it?
> >
> >
> > Nastya.
> >
> > On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh
> > > wrote:
> >
> > With CentOS7 we will have python2.7 at Fuel Admin node as a
> > default version, I believe.
> >
> > --
> > Best regards,
> > Oleg Gelbukh,
> > Principal Engineer
> > Mirantis
> >
> > On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov
> >  > > wrote:
> >
> > Hi Andrey,
> >
> > As far as I remember from the last usage of fuel
> > master node, there was Centos + py26 installation.
> > Python 2.6 is old enough and sometimes it is hard to
> > launch some application on fuel node without docker
> > (image with py27/py3). Are you planning to provide
> > py27 at least or my note is outdated and I can
> > already use py27 from the box?
> >
> > We can install docker on master node anyway to run Rally
> > / Tempest or other test suites and scripts from master
> > node with Python 2.7 or something also.
> >
> > On Fri, Nov 20, 2015 at 5:20 PM, Andrey Kurilin
> > >
> > wrote:
> >
> > Hi!
> > I'm not fuel developer, so opinion below is based on
> > user-view.
> > As far as I remember from the last usage of fuel
> > master node, there was Centos + py26 installation.
> > Python 2.6 is old enough and sometimes it is hard to
> > launch some application on fuel node without docker
> > (image with py27/py3). Are you planning to provide
> > py27 at least or my note is outdated and I can
> > already use py27 from the box?
> >
> > On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov
> >  > > wrote:
> >
> > Dear colleagues,
> >
> > As might remember, we introduced Docker
> > containers on the master node a while ago when
> > we implemented first version of Fuel upgrade
> > feature. The motivation behind was to make it
> > possible to rollback upgrade process if
> > something goes wrong.
> >
> > Now we are at the point where we can not use our
> >

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

2015-11-23 Thread Aleksandr Maretskiy

On Mon, Nov 23, 2015 at 2:27 PM, Bogdan Dobrelya 
wrote:

> On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
> > Hi all,
> >
> > as you know, Rally runs inside docker on Fuel master node, so docker
> > removal (good improvement) is a problem for Rally users.
> >
> > To solve this, I'm planning to make native Rally installation on Fuel
> > master node that is running on CentOS 7,
> > and then make a step-by-step instruction how to make this installation.
> >
> > So I hope docker removal will not make issues for Rally users.
>
> I believe the most backwards compatible scenario is to keep the docker
> installed while removing the fuel-* docker things back to the host OS.
> So nothing would prevent user from pulling and running whichever docker
> containers he wants to put on the Fuel master node. Makes sense?
>
>
Sounds good
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack]Question about using Devstack

2015-11-23 Thread Dmitry Tantsur


On 11/23/2015 12:07 PM, Oleksii Zamiatin wrote:



On Mon, Nov 23, 2015 at 12:58 PM, Young Yang > wrote:

Hi,
I'm using devstack to deploy stable/Kilo in my Xenserver.
I successfully deploy devstack. But I found that every time I
restart it, devstack always run ./stack.sh to clear all my data and
resintall all the components.
So here comes  the questions.

1) Can I stop devstack from reinstalling after rebooting and just
use the openstack installed successfully last time.
I've tried  replacing the stack.sh with another blank shell script
to stop it running. Then  It didn't reinstall the services after
rebooting.  However, some services didn't start successfully.


try rejoin-stack.sh - it is in the same folder as unstack.sh, stack.sh


Did it ever worked for someone? :)




2) I found that devstack will exit if it is unable to connect the
Internet when rebooting.
Is there any way I can reboot devstack successfully without
connection to the Internet after I've install it successfully with
connection to the Internet.

Thanks in advance !  :)

__
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] When to use parameters vs parameter_defaults

2015-11-23 Thread Jay Dobies


On 11/20/2015 07:05 PM, Ben Nemec wrote:

Thinking about this some more makes me wonder if we need a sample config
generator like oslo.config.  It would work off something similar to the
capabilities map, where you would say

SSL:
   templates:
 -puppet/extraconfig/tls/tls-cert-inject.yaml
   output:
 -environments/enable-ssl.yaml

And the tool would look at that, read all the params from
tls-cert-inject.yaml and generate the sample env file.  We'd have to be
able to do a few new things with the params in order for this to work:

-Need to specify whether a param is intended to be set as a top-level
param, parameter_defaults (which we informally do today with the Can be
overridden by parameter_defaults comment), or internal, to define params
that shouldn't be exposed in the sample config and are only intended as
an interface between templates.  There wouldn't be any enforcement of
the internal type, but Python relies on convention for its private
members so there's precedent. :-)


There is new functionality in Heat that will let you pass in a series of 
templates and environments and it will return:


- The list of top-level parameters, the same way template-validate 
always did

- A list of all nested parameters, keyed by resource.

Take a look at 
https://github.com/openstack/heat-specs/blob/master/specs/liberty/nested-validation.rst 
for details and an example.


That's not entirely what you're getting at, I realize that. I'm glad to 
see you suggest a convention-based approach because I think that's the 
only way we're going to be able to convey some of this information.


I think at the same time we add a mechanism to distinguish between 
internal and external parameters, we need to add something to indicate 
required v. optional.


With a nested stack, anything that's not part of the top-level parameter 
contract is defaulted. The problem is that it loses information on what 
is a valid default v. what's simply defaulted to pass validation.


I've been noticing this more and more on the vendor integrations. They 
have parameters that are required (such as a username) and others that 
are less likely to be changed (I can't think of an example, but I think 
everyone can see where I'm going with this).


So I think there are two sorts of things (at least, I'm also thinking 
off the top of my head) we'd like this tool/sample file to convey:


- Parameters a user would want to change, as compared to those used for 
internal data shuffling
- Information on if the user must supply a value, as compared to 
parameters with an actual default


All that said, I dig this idea of a tool that would generate a skeleton 
environment file.



-There would have to be some way to pick out only certain params from a
template, since I think there are almost certainly features that are
configured using a subset of say puppet/controller.yaml which obviously
can't just take the params from an entire file.  Although maybe this is
an indication that we could/should refactor the templates to move some
of these optional params into their own separate files (at this point I
think I should take a moment to mention that this is somewhat of a brain
dump, so I haven't thought through all of the implications yet and I'm
not sure it all makes sense).



The nice thing about generating these programmatically is we would
formalize the interface of the templates somewhat, and it would be
easier to keep sample envs in sync with the actual implementation.


You could go so far as to put CI on top of it like we do with the oslo 
config stuff, which would be neat.



You'd never have to worry about someone adding a param to a file but
forgetting to update the env (or at least it would be easy to catch and
fix when they did, just run "tox -e genconfig").

I'm not saying this is a simple or short-term solution, but I'm curious
what people think about setting this as a longer-term goal, because as I
think our discussion in Tokyo exposed, we're probably going to have a
bit of an explosion of sample envs soon and we're going to need some way
to keep them sane.

Some more comments inline.

On 11/19/2015 10:16 AM, Steven Hardy wrote:

On Mon, Nov 16, 2015 at 08:15:48PM +0100, Giulio Fidente wrote:

On 11/16/2015 04:25 PM, Steven Hardy wrote:

Hi all,

I wanted to start some discussion re $subject, because it's been apparrent
that we have a lack of clarity on this issue (and have done ever since we
started using parameter_defaults).


[...]


How do people feel about this example, and others like it, where we're
enabling common, but not mandatory functionality?


At first I was thinking about something as simple as: "don't use top-level
params for resources which the registry doesn't enable by default".

It seems to be somewhat what we tried to do with the existing pluggable
resources.

Also, not to hijack the thread but I wanted to add another question related
to a similar issue:

   Is there a reason to prefer use of parameters: instead

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

2015-11-23 Thread Li, Xiaoyan

Hi,

Except creating encrypted volume from images, uploading encrypted volumes to 
image, as Duncan said there is desire to migrate volumes between encrypted and 
unencrypted type.
https://review.openstack.org/#/c/248593/

And key magagment codes are duplicated in Cinder and Nova:
https://github.com/openstack/cinder/tree/master/cinder/keymgr
https://github.com/openstack/nova/tree/master/nova/keymgr

Best wishes
Lisa

From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
Sent: Monday, November 23, 2015 8:29 PM
To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

Hi Daniel
Much of this got discussed before.

Encrypted images uploaded to glance aren't shareable, and there is definitely a 
desire by many users to keep the usual glance functionality while having 
encryption at rest in cinder for e.g. regulatory purposes.
There is also some desire to be able to migrate unencrypted volume types to 
encrypted types inside cinder, which would require cinder to be able to create 
an encrypted volume in a similar way to creating from an image.

Managing access to the key data is, as far as I'm aware, the job of e.g. 
barbican/castellan, not nova per se. There are several usecases for encryption, 
and several of the less paranoid make good sense without requiring nova to be 
the only thing with access to the key material.

On 23 November 2015 at 13:21, Daniel P. Berrange 
> wrote:
On Fri, Nov 20, 2015 at 11:34:29AM -0800, Walter A. Boring IV wrote:
> On 11/20/2015 10:19 AM, Daniel P. Berrange wrote:
> >On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote:
> >>Brick does not have to take over the decisions in order to be a useful
> >>repository for the code. The motivation for this work is to avoid having
> >>the dm setup code copied wholesale into cinder, where it becomes difficult
> >>to keep in sync with the code in nova.
> >>
> >>Cinder needs a copy of this code since it is on the data path for certain
> >>operations (create from image, copy to image, backup/restore, migrate).
> >A core goal of using volume encryption in Nova to provide protection for
> >tenant data, from a malicious storage service. ie if the decryption key
> >is only ever used by Nova on the compute node, then cinder only ever sees
> >ciphertext, never plaintext.  Thus if cinder is compromised, then it can
> >not compromise any data stored in any encrypted volumes.
> >
> >If cinder is looking to get access to the dm-seutp code, this seems to
> >imply that cinder will be getting access to the plaintext data, which
> >feels to me like it de-values the volume encryption feature somewhat.
> >
> >I'm fuzzy on the details of just what code paths cinder needs to be
> >able to convert from plaintext to ciphertext or vica-verca, but in
> >general I think it is desirable if we can avoid any such operation
> >in cinder, and keep it so that only Nova compute nodes ever see the
> >decrypted data.
> Being able to limit the number of points where an encrypted volume can be
> used unencrypted
> is obviously a good goal.
> Unfortunately, it's entirely unrealistic to expect Cinder to never be able
> to have access that access.
>
> Cinder currently needs access to write data to volumes that are encrypted
> for several operations.
>
> 1) copy volume to image
If a volume is encrypted and it is being copied to an image, IMHO we
should not aim to decrypt it. We should copy the data as is and mark
the image as encrypted in glance, and then use it as is next time the
image is needed.

FYI, Nova is already aiming to consider both the glance data storage
and the glance service as a whole, as untrustworthy. The first step
in this is using cryptographic signatures to detect unauthorized
image data modification by a compromised glance. Encryption will be
a later step in the process.

> 2) copy image to volume

This is semi-plausible as a place where Cinder needs to go from
unencrypted image data to encrypted volume data, when a user is
creating a volume from an image ahead of time, distinct from any
VM boot attempt. In such a case it is desirable that Cinder not
be able to request any existing volume keys from the key server,
merely have the ability to upload new keys and throw away its
local copy thereafter.

> 3) backup

Cinder should really not try to decrypt volumes when backing them
up. If it conversely wants to encrypt volumes during backup, it
can do so with separate backup keys, distinct from those used for
primary volume encryption for use at runtime.

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

Re: [openstack-dev] [nova] FKs in the DB

Jordan Pittier said on Mon, Nov 23, 2015 at 11:59:35AM +0100:
> Is the DB the limiting factor of openstack performance ? De we have hard
> evidence of this ? We need numbers before acting otherwise it will be an
> endless discussion.

Properly parallelised workers scale linearly. Persistent systems scale
slower because achieving consistency requires at least NlogN commlinks
between persistence nodes. This generally makes them the slowest part of
any well-engineered system running at the limit.

This is in the abstract though. You're right, we shouldn't get excited
about theoretical gains until we have Clint's numbers. It's quite likely
we're hitting ourselves in the face algorithmically. If constraints are
an issue, we can start removing the binding ones while retaining the
app-level constraints and normal form.

> When I look at the number of race conditions we had/have in OpenStack, it
> seems scary to remove the FK in the DB. FK look like a "guardian" to me and
> we should aim at enforcing more consistency/integrity, not the contrary.

It's always scary leaving the nest. That is the proper reaction! Still
doesn't mean we should stay home forever, just be cautious.

> Also, this is an open source project with contributors with different
> skills and experience (beginners, part time contributor etc.). Maybe this
> is something to also consider.

What are you saying?


Alexis (lxsli)
-- 
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

__
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] Post-release bump after 2014.2.4?

2015-11-23 Thread Vincent Untz

Hi,

I know 2014.2.4 is (in theory) the last juno release, but I'd still
expect to see a post-release bump to 2014.2.5 in git, to avoid any
confusion as to what lives in git. This is especially useful if people
build new tarballs from git.

Any objection against this, before I send patches? :-)

Cheers,

Vincent

-- 
Les gens heureux ne sont pas pressés.

__
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] Call for review focus

2015-11-23 Thread Rossella Sblendido

On 11/20/2015 03:54 AM, Armando M. wrote:

On 19 November 2015 at 18:26, Assaf Muller > wrote:

On Wed, Nov 18, 2015 at 9:14 PM, Armando M. > wrote:
> Hi Neutrites,
>
> We are nearly two weeks away from the end of Mitaka 1.
>
> I am writing this email to invite you to be mindful to what you review,
> especially in the next couple of weeks. Whenever you have the time to 
review
> code, please consider giving priority to the following:
>
> Patches that target blueprints targeted for Mitaka;
> Patches that target bugs that are either critical or high;
> Patches that target rfe-approved 'bugs';
> Patches that target specs that have followed the most current submission
> process;

Is it possible to create Gerrit dashboards for patches that answer these
criteria, and then persist the links in Neutron's dashboards devref
page?
http://docs.openstack.org/developer/neutron/dashboards/index.html
That'd be super useful.

We should look into that, but to be perfectly honest I am not sure how
easy it would be, since we'd need to cross-reference content that lives
into gerrit as well as launchpad. Would that even be possible?

To cross-reference we can use the bug ID or the blueprint name.

I created a script that queries launchpad to get:
1) Bug number of the bugs tagged with approved-rfe
2) Bug number of the critical/high bugs
3) list of blueprints targeted for the current milestone (mitaka-1)

With this info the script builds a .dash file that can be used by 
gerrit-dash-creator [2] to produce a dashboard url .

The script prints also the queries that can be used in gerrit UI 
directly, e.g.:

Critical/High Bugs
(topic:bug/1399249 OR topic:bug/1399280 OR topic:bug/1443421 OR 
topic:bug/1453350 OR topic:bug/1462154 OR topic:bug/1478100 OR 
topic:bug/1490051 OR topic:bug/1491131 OR topic:bug/1498790 OR 
topic:bug/1505575 OR topic:bug/1505843 OR topic:bug/1513678 OR 
topic:bug/1513765 OR topic:bug/1514810)

This is the dashboard I get right now [3]

I tried in many ways to get Gerrit to filter patches if the commit 
message contains a bug ID. Something like:

(message:"#1399249" OR message:"#1399280" OR message:"#1443421" OR 
message:"#1453350" OR message:"#1462154" OR message:"#1478100" OR 
message:"#1490051" OR message:"#1491131" OR message:"#1498790" OR 
message:"#1505575" OR message:"#1505843" OR message:"#1513678" OR 
message:"#1513765" OR message:"#1514810")

but it doesn't work well, the result of the filter contains patches that 
have nothing to do with the bugs queried.

That's why I had to filter using the topic.

CAVEAT: To make the dashboard work, bug fixes must use the topic 
"bug/ID" and patches implementing a blueprint the topic "bp/name". If a 
patch is not following this convention it won't be showed in the 
dashboard, since the topic is used as filter. Most of us use this 
convention already anyway so I hope it's not too much of a burden.

Feedback is appreciated :)

[1] https://review.openstack.org/248645
[2] https://github.com/openstack/gerrit-dash-creator
[3] https://goo.gl/sglSbp

Btw, I was looking at the current blueprint assignments [1] for Mitaka:
there are some blueprints that still need assignee, approver and
drafter; we should close the gap. If there are volunteers, please reach
out to me.

Thanks,
Armando

[1] https://blueprints.launchpad.net/neutron/mitaka/+assignments

>
> Everything else should come later, no matter how easy or interesting it is
> to review; remember that as a community we have the collective duty to 
work
> towards a common (set of) target(s), as being planned in collaboration 
with
> the Neutron Drivers team and the larger core team.
>
> I would invite submitters to ensure that the Launchpad resources
> (blueprints, and bug report) capture the most updated view in terms of
> patches etc. Work with your approver to help him/her be focussed where it
> matters most.
>
> Finally, we had plenty of discussions at the design summit, and some of
> those discussions will have to be followed up with actions (aka code in
> OpenStack lingo). Even though, we no longer have deadlines for feature
> submission, I strongly advise you not to leave it last minute. We can only
> handle so much work for any given release, and past experience tells us 
that
> we can easily hit a breaking point at around the ~30 blueprint mark.
>
> Once we reached it, it's likely we'll have to start pushing back work for
> Mitaka and allow us some slack; things are fluid as we all know, and the
> random gate breakage is always lurking round the corner! :)
>
> Happy hacking,
> Armando
>
 >
__
 > OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [nova] Migration progress

On Mon, Nov 23, 2015 at 08:36:32AM +, Paul Carlton wrote:
> John
> 
> At the live migration sub team meeting I undertook to look at the issue
> of progress reporting.
> 
> The use cases I'm envisaging are...
> 
> As a user I want to know how much longer my instance will be migrating
> for.
> 
> As an operator I want to identify any migration that are making slow
>  progress so I can expedite their progress or abort them.
> 
> The current implementation reports on the instance's migration with
> respect to memory transfer, using the total memory and memory remaining
> fields from libvirt to report the percentage of memory still to be
> transferred.  Due to the instance writing to pages already transferred
> this percentage can go up as well as down.  Daniel has done a good job
> of generating regular log records to report progress and highlight lack
> of progress but from the API all a user/operator can see is the current
> percentage complete.  By observing this periodically they can identify
> instance migrations that are struggling to migrate memory pages fast
> enough to keep pace with the instance's memory updates.
> 
> The problem is that at present we have only one field, the instance
> progress, to record progress.  With a live migration there are measures
> of progress, how much of the ephemeral disks (not needed for shared
> disk setups) have been copied and how much of the memory has been
> copied. Both can go up and down as the instance writes to pages already
> copied causing those pages to need to be copied again.  As Daniel says
> in his comments in the code, the disk size could dwarf the memory so
> reporting both in single percentage number is problematic.
> 
> We could add an additional progress item to the instance object, i.e.
> disk progress and memory progress but that seems odd to have an
> additional progress field only for this operation so this is probably
> a non starter!
> 
> For operations staff with access to log files we could report disk
> progress as well as memory in the log file, however that does not
> address the needs of users and whilst log files are the right place for
> support staff to look when investigating issues operational tooling
> is much better served by notification messages.
> 
> Thus I'd recommend generating periodic notifications during a migration
> to report both memory and disk progress would be useful?  Cloud
> operators are likely to manage their instance migration activity using
> some orchestration tooling which could consume these notifications and
> deduce what challenges the instance migration is encountering and thus
> determine how to address any issues.
> 
> The use cases are only partially addressed by the current
> implementation, they can repeatedly get the server details and look at
> the progress percentage to see how quickly (or even if) it is
> increasing and determine how long the instance is likely to be
> migrating for.  However for an instance that has a large disk and/or
> is doing a high rate of disk i/o they may see the percentage complete
> (i.e. memory) repeatedly showing 90%+ but the instance migration does
> not complete.
> 
> The nova spec https://review.openstack.org/#/c/248472/ suggests making
> detailed information available via the os-migrations object.  This is
> not a bad idea but I have some issues with the implementation that I
> will share on that spec.

As I mentioned in the spec, I won't support exposing anything other
than disk total + remaining via the API. All the other stats are
low level QEMU specific implementation details that I feel the public
API users have no business knowing about.

In general I think we need to be wary of exposing lots of info + knobs
via the API, as that direction essentially ends up forcing the problem
onto client application. The focus should really be on ensuring that
Nova consumes all these stats exposed by QEMU and makes decisions
itself based on that.

At most an external application should have information on the data
transfer progress. I'm not even convinced that applications should
need to be able to figure out if a live migration is stuck. I generally
think that any scenario in which a live migration can get stuck is a
bug in Nova's management of the migration process. IOW, the focus of
our efforts should be on ensuring Nova does the right thing to guarantee
that live migration will never get stuck. At which point an Nova client
user / application should really only care about the overall progress
of a live migration.

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

__
OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

2015-11-23 Thread Bogdan Dobrelya

On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
> Hi all,
> 
> as you know, Rally runs inside docker on Fuel master node, so docker
> removal (good improvement) is a problem for Rally users.
> 
> To solve this, I'm planning to make native Rally installation on Fuel
> master node that is running on CentOS 7,
> and then make a step-by-step instruction how to make this installation.
> 
> So I hope docker removal will not make issues for Rally users.

I believe the most backwards compatible scenario is to keep the docker
installed while removing the fuel-* docker things back to the host OS.
So nothing would prevent user from pulling and running whichever docker
containers he wants to put on the Fuel master node. Makes sense?

> 
> On Mon, Nov 23, 2015 at 12:28 PM, Vladimir Kozhukalov
> > wrote:
> 
> ETA:
> 
> experimental ISO w/o docker: tonight
> spec: tomorrow night
> 
> 
> 
> Vladimir Kozhukalov
> 
> On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova
> > wrote:
> 
> @Vova, 
> thanks for bringing this up. 
> The new approach without docker containers on master node really
> has many advantages. 
> 
> @Igor,
> regarding your question, I would say that we have many
> dependencies from containers in CI/CD systems and test's
> codebase. The test alignment to the new implementation won't be
> easy. In such things we should move forward step by step.
> As you know the first step is a spec file, can you give us a
> link to it?
> 
> 
> Nastya.
> 
> On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh
> > wrote:
> 
> With CentOS7 we will have python2.7 at Fuel Admin node as a
> default version, I believe.
> 
> --
> Best regards,
> Oleg Gelbukh,
> Principal Engineer
> Mirantis
> 
> On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov
>  > wrote:
> 
> Hi Andrey,
> 
> As far as I remember from the last usage of fuel
> master node, there was Centos + py26 installation.
> Python 2.6 is old enough and sometimes it is hard to
> launch some application on fuel node without docker
> (image with py27/py3). Are you planning to provide
> py27 at least or my note is outdated and I can
> already use py27 from the box?
> 
> We can install docker on master node anyway to run Rally
> / Tempest or other test suites and scripts from master
> node with Python 2.7 or something also.
> 
> On Fri, Nov 20, 2015 at 5:20 PM, Andrey Kurilin
> >
> wrote:
> 
> Hi!
> I'm not fuel developer, so opinion below is based on
> user-view.
> As far as I remember from the last usage of fuel
> master node, there was Centos + py26 installation.
> Python 2.6 is old enough and sometimes it is hard to
> launch some application on fuel node without docker
> (image with py27/py3). Are you planning to provide
> py27 at least or my note is outdated and I can
> already use py27 from the box?
> 
> On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov
>  > wrote:
> 
> Dear colleagues,
> 
> As might remember, we introduced Docker
> containers on the master node a while ago when
> we implemented first version of Fuel upgrade
> feature. The motivation behind was to make it
> possible to rollback upgrade process if
> something goes wrong. 
> 
> Now we are at the point where we can not use our
> tarball based upgrade approach any more and
> those patches that deprecate upgrade tarball has
> been already merged. Although it is a matter of
> a separate discussion, it seems that upgrade
> process rather should be based on kind of backup
> and restore procedure. We can backup Fuel data
> on an external media, then we can install new
>

Re: [openstack-dev] [openstack-ansible] Random ssh errors in gate check jobs

2015-11-23 Thread Jesse Pretorius

On 23 November 2015 at 01:36, Major Hayden  wrote:

> Hey folks,
>
> Some of my recent reviews have been frequent fliers in the land of CI gate
> jobs and I've spent a fair amount of time diagnosing random ssh failures to
> containers in AIO builds.  The error I get most often is this:
>
> SSH Error: data could not be sent to the remote host. Make sure this
> host can be reached over ssh
>
> After digging in Ansible code for a bit, I found the error within the ssh
> connection plugin[1].  It looks like an issue where the ssh connection is
> actually open but data cannot be sent to the subprocess.
>
> I messed around heavily with multiplexing, keys, GSSAPI, and more, but the
> errors randomly appear.  I've proposed a review[2] for a switch to paramiko
> transport mode for gate jobs only and it has run four times without ssh
> errors (although two builds had timeouts due to the repo build taking too
> long).
>
> The fifth build is running now and it seems to be moving along fairly
> quickly.
>
> [1]
> https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/connection/ssh.py#L245-L260
> [2] https://review.openstack.org/#/c/248361/

Thanks for digging into this Major. It is a royal pain and will likely be
resolved with the release of Ansible 2, but for now we're stuck with having
to work around the issue with what we have.

I wonder, is there a difference in results or performance between using
paramiko or turning ssh pipelining off?
__
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] Location of TripleO REST API

2015-11-23 Thread Dougal Matthews

On 17 November 2015 at 15:31, Tzu-Mainn Chen  wrote:

>
> --
>
>
>
> On 10 November 2015 at 15:08, Tzu-Mainn Chen  wrote:
>
>> Hi all,
>>
>> At the last IRC meeting it was agreed that the new TripleO REST API
>> should forgo the Tuskar name, and simply be called... the TripleO
>> API.  There's one more point of discussion: where should the API
>> live?  There are two possibilities:
>>
>> a) Put it in tripleo-common, where the business logic lives.  If we
>> do this, it would make sense to rename tripleo-common to simply
>> tripleo.
>>
>
> +1 - I think this makes most sense if we are not going to support the
> tripleo repo as a library.
>
>
> Okay, this seems to be the consensus, which is great.
>
> The leftover question is how to package the renamed repo.  'tripleo' is
> already intuitively in use by tripleo-incubator.
> In IRC, bnemec and trown suggested splitting the renamed repo into two
> packages - 'python-tripleo' and 'tripleo-api',
> which seems sensible to me.
>
> What do others think?
>

Yup, that sounds good. Eventually when the CLI is untangled from
tripleo_common we wont need the python-tripleo package as it wont ever be
used as a library.


>
>
> Mainn
>
>
> b) Put it in its own repo, tripleo-api
>>
>>
>> The first option made a lot of sense to people on IRC, as the proposed
>> API is a very thin layer that's bound closely to the code in tripleo-
>> common.  The major objection is that renaming is not trivial; however
>> it was mentioned that renaming might not be *too* bad... as long as
>> it's done sooner rather than later.
>>
>> What do people think?
>>
>>
>> Thanks,
>> Tzu-Mainn Chen
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Important notice about running tests for python-fuelclient

2015-11-23 Thread Roman Prykhodchenko

Maciej,

thank you very much for providing the links. Sorry for inconvenience.


- romcheg
> 23 лист. 2015 р. о 12:48 Maciej Kwiek  написав(ла):
> 
> Missing links from this email:
> [1] 
> https://bitbucket.org/hpk42/tox/issues/285/tox-220-breaks-some-toxini-config-files
>  
> 
> [2] https://review.openstack.org/#/c/247452/6 
> 
> 
> On Mon, Nov 23, 2015 at 12:45 PM, Roman Prykhodchenko  > wrote:
> Hi fulers!
> I’d like to let you know that because of the bug [1] in tox 2.2.1 we had to 
> change [2] tox.ini temporarily to unlock the gate until the author of tox is 
> working on the fix for the problem. Those changes in tox.ini revoke all 
> freedom of configuring how tests on one’s local environment are run, so all 
> environment variables except FUEL_WEB_ROOT and TEST_NAILGUN_DB are ignored.
> Please also note, that setting those two variables is now _mandatory_ — tests 
> will fail with strange errors, if that is not done. I will keep you updated 
> as soon as tox is fixed and the temporary changes to tox.ini are reverted.
> 
> - romcheg
> 
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [stable] Post-release bump after 2014.2.4?

2015-11-23 Thread Vincent Untz

Le lundi 23 novembre 2015, à 13:17 +0100, Ihar Hrachyshka a écrit :
> Vincent Untz  wrote:
> 
> >Hi,
> >
> >I know 2014.2.4 is (in theory) the last juno release, but I'd still
> >expect to see a post-release bump to 2014.2.5 in git, to avoid any
> >confusion as to what lives in git. This is especially useful if people
> >build new tarballs from git.
> >
> >Any objection against this, before I send patches? :-)
> >
> >Cheers,
> >
> >Vincent
> 
> I probably miss something, but why do we care about what is in the
> branch now that we don’t plan to merge anything more there? Is it to
> accommodate for downstream consumers that may want to introduce more
> patches on top of the upstream tag?

As I said: because people might keep generating tarballs from git, and
they'd expect to have a version that is correct. Yes, this is mostly
downstreams. (And not necessarily to introduce more patches, but just to
reflect the reality).

I would also argue that we care because we're leaving git in a state
that is kind of wrong (since the version is not correct).

Cheers,

Vincent

-- 
Les gens heureux ne sont pas pressés.

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

Re: [openstack-dev] [devstack]Question about using Devstack

Hi Young,

venv create: /opt/stack/tempest/.tox/venv
venv installdeps: -r/opt/stack/tempest/requirements.txt, 
-r/opt/stack/tempest/test-requirements.txt
ERROR: invocation failed (exit code 1), logfile: 
/opt/stack/tempest/.tox/venv/log/venv-1.log
ERROR: actionid: venv
msg: getenv
cmdargs: [local('/opt/stack/tempest/.tox/venv/bin/pip'), 'install', '-U', 
'-r/opt/stack/tempest/requirements.txt', 
'-r/opt/stack/tempest/test-requirements.txt']

My interpretation is that because tox is using pip directly, which is now 
outside of devstack and knows nothing about the OFFLINE flag.
This is in the “install_tempest” function from devstack/lib/tempest.  A code 
change would be needed to stop tox from running if OFFLINE was specified.  At 
first glance, I believe this is probably a devstack bug.

I suspect that, since Tempest creates flavors, you will not be able to use 
tempest in OFFLINE=true mode, but you may be able to use other services if you 
remove tempest from ENABLED_SERVICES.

@jordan.pittier  @Bob Ball
If I can ensure my IP address , localrc and everything else are not changed, is 
there any way I can achieve my goal?

I don’t think I understand what your goal is – perhaps if you clarify exactly 
what you’re trying to achieve then we can answer the question.

Thanks,

Bob
__
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][fwaas]some architectural advice on fwaas driver writing

2015-11-23 Thread Oğuz Yarımtepe

I am checking the vyatta driver now and they replaced l3 agent with their
own agent and also using a vrouter image for router creation. Our appliance
is not virtual :)
So for the linkage between services, can service chaining help me?

On Mon, Nov 23, 2015 at 8:25 AM, Germy Lure  wrote:

> Hi,
> Under current FWaaS architecture or framework, only integrating hardware
> firewall is not easy. That requires neutron support service level multiple
> vendors. In another word, vendors must fit each other for their services
> while currently vendors just provides all services through controller.
>
> I think the root cause is Neutron just doesn't known how the network
> devices connect each other.  Neutron provides FW, LB, VPN and other
> advanced network functionalists as services. But as the implementation
> layer, Neutron needs TOPO info to make right decision, routing traffic to
> the right device. For example, from namespace router to hardware firewall,
> Neutron should add some internal routes even extra L3 interfaces according
> to the connection relationship between them. If the firewall service is
> integrated with router, like Vyatta, it's simple. The only thing you need
> to do is just enable the firewall itself.
>
> All in all, it requires linkage between services, especially between
> advanced services and L3 router.
>
> Germy
> .
>
> On Fri, Nov 20, 2015 at 9:19 PM, Somanchi Trinath <
> trinath.soman...@freescale.com> wrote:
>
>> Hi-
>>
>>
>>
>> As I understand you are not sure on “How to locate the Hardware
>> Appliance” which you have as your FW?
>>
>>
>>
>> Am I right?  If so you can look into,
>> https://github.com/jumpojoy/generic_switch kind of approach.
>>
>>
>>
>> -
>>
>> Trinath
>>
>>
>>
>>
>>
>>
>>
>> *From:* Oguz Yarimtepe [mailto:oguzyarimt...@gmail.com]
>> *Sent:* Friday, November 20, 2015 5:52 PM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [neutron][fwaas]some architectural advice
>> on fwaas driver writing
>>
>>
>>
>> I created a sample driver by looking at vArmour driver that is at the
>> Github FWaaS repo. I am planning to call the FW's REST API from the
>> suitable functions.
>>
>> The problem is, i am still not sure how to locate the hardware appliance.
>> One of the FWaaS guy says that Service Chaining can help, any body has an
>> idea or how to insert the fw to OpenStack?
>>
>> On 11/02/2015 02:36 PM, Somanchi Trinath wrote:
>>
>> Hi-
>>
>>
>>
>> I’m confused. Do you really have an PoC implementation of what is to be
>> achieved?
>>
>>
>>
>> As I look into these type of Implementations, I would prefer to have
>> proxy driver/plugin to get the configuration from Openstack to external
>> controller/device and do the rest of the magic.
>>
>>
>>
>> -
>>
>> Trinath
>>
>>
>>
>> __
>> 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
>
>


-- 
Oğuz Yarımtepe
http://about.me/oguzy
__
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] [Sahara] Block Device Driver updates

2015-11-23 Thread Ivan Kolodyazhny

Hi Zhidong,

Unfortunately stable/kilo branch is opened only for security fixes now. So
we can't backport this fix.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Mon, Nov 23, 2015 at 4:43 AM, Zhidong Yu  wrote:

> It seems there was a bug introduced in Kilo and then fixed in Liberty [6].
> However, since there are more users of Kilo than of Liberty, I am wondering
> if the fix has been back ported to Kilo. I could not find it except for
> this one [7] which seems to be a different issue.
>
> [6] https://review.openstack.org/#/c/200039/
> [7] https://bugs.launchpad.net/cinder/+bug/1465819
>
> On Thu, Oct 1, 2015 at 3:00 AM, Ivan Kolodyazhny  wrote:
>
>> Hi team,
>>
>> I know that Block Device Driver (BDD) is not popular in Cinder community.
>> The main issues were:
>>
>> * driver is not good maintained
>> * it doesn't feet minimum features set
>> * there is no CI for it
>> * it's not a Cinder way/it works only when instance and volume are
>> created on the same host
>> * etc
>>
>> AFAK, it's widely used in Sahara &  Hadoop communities because it works
>> fast. I won't discuss driver's performance in this thread. I share my
>> performance tests results once I'll finish it.
>>
>> I'm going to share drive updates with you about issues above.
>>
>> 1) driver is not good maintained - we are working on it right now and
>> will fix any found issues. We've got devstack plugin [1] for this driver.
>>
>> 2) it doesn't feet minimum features set - I've filed a blueprint [2] for
>> it. There are patches that implement needed features in the gerrit [3].
>>
>> 3) there is no CI for it - In Cinder community, we've got strong
>> requirement that each driver must has CI. I've absolutely agree with that.
>> That's why new infra job is proposed [4].
>>
>> 4) it works only when instance and volume are created on the same host -
>> I've filed a blueprint [5] but after testing I've found that it's already
>> implemented by [6].
>>
>>
>> I hope, I've answered all questions that were asked in IRC and in
>> comments for [6]. I will do my best to support this driver and propose fix
>> to delete if community decide  to delete it from the cinder tree
>>
>>
>> [1] https://github.com/openstack/devstack-plugin-bdd
>> [2]
>> https://blueprints.launchpad.net/cinder/+spec/block-device-driver-minimum-features-set
>> [3]
>> https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:bp/block-device-driver-minimum-features-set,n,z
>> [4] https://review.openstack.org/228857
>> [5]
>> https://blueprints.launchpad.net/cinder/+spec/block-device-driver-via-iscsi
>> [6] https://review.openstack.org/#/c/200039/
>>
>>
>> Regards,
>> Ivan Kolodyazhny
>>
>> __
>> 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] Regarding Designate Multi-node issue

2015-11-23 Thread Sharma Swati6

 Hi All,

I have a multi-node production environment setup using Ansible. The  basic 
openstack components packed in their respective containers, are  already 
installed here.   

Now, I want to install Designate on this existing setup and have its  
container. I am currently following link : 
https://developer.rackspace.com/blog/getting-started-with-openstack-and-designate/
 . 

But, I am not sure if this will help me with the multinode approach.   Can 
anyone please suggest me some steps?

Thanks & Regards
 Swati Sharma
 System Engineer
 Tata Consultancy Services
 Ground to 8th Floors, Building No. 1 & 2,
 Skyview Corporate Park, Sector 74A,NH 8
 Gurgaon - 122 004,Haryana
 India
 Cell:- +91-9717238784
 Mailto: sharma.swa...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty.  IT Services
Business Solutions
Consulting
 
 
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

Re: [openstack-dev] [horizon][bug] Mitigation to BREACH vulnerability

2015-11-23 Thread Matthias Runge

On Fri, Nov 20, 2015 at 10:00:30PM +, BARTRA, RICK wrote:
> Until django releases an official patch for the BREACH vulnerability, I think 
> we should take a look at django-debreach. The django-debreach package 
> provides some, possibly enough, protection against a BREACH attack. Its 
> integration to Horizon is clear by following the configuration found here: 
> https://pypi.python.org/pypi/django-debreach
> 
> 
> The proposed change to Horizon: https://review.openstack.org/#/c/247838/
> 
> The proposed change to Requirements: https://review.openstack.org/#/c/248233/

Thank you for proposing this

still I believe, this is
a) security hardening to be done by deployers
b) something not specific to Horizon, and a solution should be integrated in
Django, not just in a single application using Django.

Matthias

-- 
Matthias Runge 

__
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] [puppet] mime-types-data requires Ruby version >= 2.0

2015-11-23 Thread Emilien Macchi

Because of [1], [2] and [3]: all beaker-rspec-dsvm-trusty jobs are broken.

The only one option I see is to pin mime-types in beaker dependencies,
because beaker needs frog and frog needs mime-types.

Note beaker is currently broken for ubuntu trusty nodes, because of this
change.

[1] https://github.com/mime-types/mime-types-data/releases/tag/v3.2015.1120
[2] https://github.com/mime-types/mime-types-data/blob/master/Rakefile#L16
[3] fog requires mime-types (>= 0)
-- 
Emilien Macchi



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

[openstack-dev] [nova] Migration progress

2015-11-23 Thread Paul Carlton


John

At the live migration sub team meeting I undertook to look at the issue
of progress reporting.

The use cases I'm envisaging are...

As a user I want to know how much longer my instance will be migrating
for.

As an operator I want to identify any migration that are making slow
 progress so I can expedite their progress or abort them.

The current implementation reports on the instance's migration with
respect to memory transfer, using the total memory and memory remaining
fields from libvirt to report the percentage of memory still to be
transferred.  Due to the instance writing to pages already transferred
this percentage can go up as well as down.  Daniel has done a good job
of generating regular log records to report progress and highlight lack
of progress but from the API all a user/operator can see is the current
percentage complete.  By observing this periodically they can identify
instance migrations that are struggling to migrate memory pages fast
enough to keep pace with the instance's memory updates.

The problem is that at present we have only one field, the instance
progress, to record progress.  With a live migration there are measures
of progress, how much of the ephemeral disks (not needed for shared
disk setups) have been copied and how much of the memory has been
copied. Both can go up and down as the instance writes to pages already
copied causing those pages to need to be copied again.  As Daniel says
in his comments in the code, the disk size could dwarf the memory so
reporting both in single percentage number is problematic.

We could add an additional progress item to the instance object, i.e.
disk progress and memory progress but that seems odd to have an
additional progress field only for this operation so this is probably
a non starter!

For operations staff with access to log files we could report disk
progress as well as memory in the log file, however that does not
address the needs of users and whilst log files are the right place for
support staff to look when investigating issues operational tooling
is much better served by notification messages.

Thus I'd recommend generating periodic notifications during a migration
to report both memory and disk progress would be useful?  Cloud
operators are likely to manage their instance migration activity using
some orchestration tooling which could consume these notifications and
deduce what challenges the instance migration is encountering and thus
determine how to address any issues.

The use cases are only partially addressed by the current
implementation, they can repeatedly get the server details and look at
the progress percentage to see how quickly (or even if) it is
increasing and determine how long the instance is likely to be
migrating for.  However for an instance that has a large disk and/or
is doing a high rate of disk i/o they may see the percentage complete
(i.e. memory) repeatedly showing 90%+ but the instance migration does
not complete.

The nova spec https://review.openstack.org/#/c/248472/ suggests making
detailed information available via the os-migrations object.  This is
not a bad idea but I have some issues with the implementation that I
will share on that spec.

-- Paul Carlton Software Engineer Cloud Services
Hewlett Packard Enterprise
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ
Mobile: +44 (0)7768 994283
Email: mailto:paul.carlt...@hpe.com
Hewlett-Packard Enterprise Limited
registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 
690597 England.
The contents of this message and any attachments to it are confidential 
and may be legally privileged.
If you have received this message in error, you should delete it from 
your system immediately and advise the sender.
To any recipient of this message within HP, unless otherwise stated you 
should consider this message and attachments as "HP CONFIDENTIAL".


__
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] Fwd: [Senlin]Support more complicated scalingscenario

2015-11-23 Thread Jun Xu

Thanks HU yanyan, I still has some questions about your answers, and I
respond inline.

On 2015/11/23 10:43, Yanyan Hu wrote:

Hi, Xu Jun, please find some answers inline. Thanks.

2015-11-20 16:06 GMT+08:00 xu...@cmss.chinamobile.com
>:

Thanks yanyan!

Xu Jun is a contributor from CMCC. He asked a very interesting
question about cluster scaling support in Senlin. To make the
discussion more thorough, I just post the question and my
answer here.

The question from Jun is as following:

For an action, senlin will check all according polices, like
if a cluster attach two scaling-in polices,
the two scaling-in polices will be checked when doing a
scaling-action on this cluster. This is not same as
OS::Heat::ScalingPolicy in heat？
How should I use senlin for following cases？
1. 15% < cpu_util < 30%, scaling_in 1 instance
2. cpu_util < 15%, scaling_in 2 instances

This is a very interesting question and you're right about the
difference between Senlin ScalingPolicy and
OS::Heat::ScalingPolicy. In Heat, OS::Heat::ScalingPolicy is
actually not just a policy. It is a combination of a webhook
and a rule about how ASG respond to the webhook
triggering(resource signal). So you can define two different
OS::Heat::ScalingPolicy instances to make them deal with two
cases you described respectively.

But in Senlin, ScalingPolicy is a REAL policy, it only
describes how a Senlin cluster react to an action triggered by
Senlin webhook which is defined separately. The problem is
when an cluster action e.g. CLUSTER_SCALE_IN is triggered, all
policies attached to it will be checked in sequence based on
policies priority definition._So if you create two Senlin
ScalingPolicy and attach them to the same cluster, only one of
them will take effect actually._
_
_
# 1. But in policy_check function, all the policies will be
checked in priority-based order for a CLUSTER_SCALING_IN
action if the cluster attached with SCALING multiple policies.
is this a bug? or what is the significanceof prority).

/Sorry, I didn't describe it clearly. I mean although both scaling
policies will be checked before CLUSTER_SCALING_IN action is executed,
count result from one ScalingPolicy will actually be overridden by the
result from another ScalingPolicy which has higher priority./

After debugging, I found that former result is not overridden by
another policy.

http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n441

2. if a cluster attached a scaling policy with event =
CLUSTER_SCALE_IN, when aCLUSTER_SCALING_OUT action is
triggered, the policy also will be checked, is this reasonable?

/ When a ScalingPolicy is defined, you can use 'event'
property to specify the action type you want the policy to take effect
on, like:

http://git.openstack.org/cgit/openstack/senlin/tree/examples/policies/scaling_policy.yaml#n5

Although a ScalingPolicy will be checked for both
CLUSTER_SCALE_IN and CLUSTER_SCALE_OUT actions, the check routine will
return immediately if the action type is not what it is expecting.

http://git.openstack.org/cgit/openstack/senlin/tree/senlin/policies/scaling_policy.py#n133/

Yes it's not checked in pre_op, but all ScalingPolicies still will be
checked whether in cooldown.

http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431*
*

Currently, you can use the following way to support your use
case in Senlin:
1. Define two Senlin webhooks which target on the
CLUSTER_SCALE_OUT action of the cluster and specify the
'param' as {'count': 1} for webhook1 and {'count': 2 } for
webhook2;
1. Define two ceilometer/aodh alarms with the first one
matching case1 and second one matching case2. Then define
webhook1 url as alarm1's alarm-action and webhook2 url as
alarm2's alarm-action.

#
Your suggestion has a problem when I want different cooldown
for each ceilometer/aodh alarms, for following cases, how
should I do?
1. 15% < cpu_util < 30%, scaling_in 1 instance with 300s
cooldown time
2. cpu_util < 15%, scaling_in 2 instances with 600s
cooldown time

/ You can define the cooldown by specifying it when creating the
policy or attaching it to a cluster. The cooldown check logic will
prevent a policy taking effect if cooldown is still in progress.

http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431
/

For a senlin webhook, could

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

2015-11-23 Thread Vladimir Kozhukalov

ETA:

experimental ISO w/o docker: tonight
spec: tomorrow night



Vladimir Kozhukalov

On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova 
wrote:

> @Vova,
> thanks for bringing this up.
> The new approach without docker containers on master node really has many
> advantages.
>
> @Igor,
> regarding your question, I would say that we have many dependencies from
> containers in CI/CD systems and test's codebase. The test alignment to the
> new implementation won't be easy. In such things we should move forward
> step by step.
> As you know the first step is a spec file, can you give us a link to it?
>
>
> Nastya.
>
> On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh 
> wrote:
>
>> With CentOS7 we will have python2.7 at Fuel Admin node as a default
>> version, I believe.
>>
>> --
>> Best regards,
>> Oleg Gelbukh,
>> Principal Engineer
>> Mirantis
>>
>> On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov <
>> tnurlygaya...@mirantis.com> wrote:
>>
>>> Hi Andrey,
>>>
>>> As far as I remember from the last usage of fuel master node, there was
 Centos + py26 installation. Python 2.6 is old enough and sometimes it is
 hard to launch some application on fuel node without docker (image with
 py27/py3). Are you planning to provide py27 at least or my note is outdated
 and I can already use py27 from the box?
>>>
>>> We can install docker on master node anyway to run Rally / Tempest or
>>> other test suites and scripts from master node with Python 2.7 or something
>>> also.
>>>
>>> On Fri, Nov 20, 2015 at 5:20 PM, Andrey Kurilin 
>>> wrote:
>>>
 Hi!
 I'm not fuel developer, so opinion below is based on user-view.
 As far as I remember from the last usage of fuel master node, there was
 Centos + py26 installation. Python 2.6 is old enough and sometimes it is
 hard to launch some application on fuel node without docker (image with
 py27/py3). Are you planning to provide py27 at least or my note is outdated
 and I can already use py27 from the box?

 On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov <
 vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> As might remember, we introduced Docker containers on the master node
> a while ago when we implemented first version of Fuel upgrade feature. The
> motivation behind was to make it possible to rollback upgrade process if
> something goes wrong.
>
> Now we are at the point where we can not use our tarball based upgrade
> approach any more and those patches that deprecate upgrade tarball has 
> been
> already merged. Although it is a matter of a separate discussion, it seems
> that upgrade process rather should be based on kind of backup and restore
> procedure. We can backup Fuel data on an external media, then we can
> install new version of Fuel from scratch and then it is assumed backed up
> Fuel data can be applied over this new Fuel instance. The procedure itself
> is under active development, but it is clear that rollback in this case
> would be nothing more than just restoring from the previously backed up
> data.
>
> As for Docker containers, still there are potential advantages of
> using them on the Fuel master node, but our current implementation of the
> feature seems not mature enough to make us benefit from the
> containerization.
>
> At the same time there are some disadvantages like
>
>- it is tricky to get logs and other information (for example, rpm
>-qa) for a service like shotgun which is run inside one of containers.
>- it is specific UX when you first need to run dockerctl shell
>{container_name} and then you are able to debug something.
>- when building IBP image we mount directory from the host file
>system into mcollective container to make image build faster.
>- there are config files and some other files which should be
>shared among containers which introduces unnecessary complexity to the
>whole system.
>- our current delivery approach assumes we wrap into rpm/deb
>packages every single piece of the Fuel system. Docker images are not 
> an
>exception. And as far as they depend on other rpm packages we forced to
>build docker-images rpm package using kind of specific build flow. 
> Besides
>this package is quite big (300M).
>- I'd like it to be possible to install Fuel not from ISO but from
>RPM repo on any rpm based distribution. But it is double work to 
> support
>both Docker based and package based approach.
>
> Probably some of you can give other examples. Anyway, the idea is to
> get rid of Docker containers on the master node and switch to plane 
> package
> based approach that we used before.
>
> As far as there is nothing new

Re: [openstack-dev] [Horizon] Bug day! Yeah!

2015-11-23 Thread Timur Sufiev

Count me in as well.

On Mon, Nov 23, 2015 at 1:53 PM Martin Pavlásek  wrote:

> Count with me tomorrow! :-)
>
>
> Martin
>
>
>
> On 20/11/15 01:02, Lin Hua Cheng wrote:
>
> Great, I'll be around next Tuesday.
>
> -Lin
>
> On Thu, Nov 19, 2015 at 12:53 PM, Rob Cresswell (rcresswe) <
> rcres...@cisco.com> wrote:
>
>> As requested,
>> https://etherpad.openstack.org/p/horizon-bug-day
>>
>> Rob
>>
>> From: Richard Jones 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Thursday, 19 November 2015 20:39
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Horizon] Bug day! Yeah!
>>
>> Let's do it. I'd like to suggest we use an etherpad to keep track of what
>> people have done. If it's not created when I start my day, I'll make one.
>>
>>
>>  Richard
>>
>> On 19 November 2015 at 22:19, Rob Cresswell (rcresswe) <
>> rcres...@cisco.com> wrote:
>>
>>> Hey folks,
>>>
>>> Our bug list is… rather large. We’ve discussed having a bug day, where
>>> as a community we all dedicate some time to triaging bugs and discussing in
>>> the IRC channel as we go.
>>>
>>> First off, see the docs about bug triage:
>>> https://wiki.openstack.org/wiki/BugTriage
>>>
>>> Secondly, lets pick a date. I’d suggest next Tuesday (24th November); if
>>> that doesn’t work for a good number of us, then the following Tuesday (1st
>>> December). Trying to account for Thanksgiving :)
>>>
>>> Rob
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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] [stable] Making stable maintenance its own OpenStack project team

2015-11-23 Thread Marzi, Fausto

I had few related experience working with Erno for releasing/stable branching 
and I have to say he significantly clarified/fixed
many issue we had.

So ++


-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com] 
Sent: 16 November 2015 17:29
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [stable] Making stable maintenance its own 
OpenStack project team

On 13/11/15 15:10 +0100, Thierry Carrez wrote:
>So.. quick summary of this thread so far.
>
>(-)
>* Not enough work to warrant a designated "team", now that the work is 
>decentralized and the cats are mostly herding themselves
>* The change is unlikely to bring a meaningful improvement to the 
>situation, or sudden new resources
>
>(+)
>* An empowered team could tackle new coordination tasks, like engaging 
>more directly in converging stable branch rules across teams, or 
>producing tools
>* Release management doesn't overlap anymore with stable branch, so 
>having them under that PTL is limiting and inefficient
>* Reinforcing the branding (by giving it its own team) may encourage 
>more organizations to affect new resources to it
>
>In summary, I think this is worth a try. If the team fails, at least it 
>will be on its own rather than as the 5th squeaky wheel of release 
>management (where lack of leadership and focus could be rightly blamed 
>for failure).
>
>For this to succeed, we need someone to own the effort and push it 
>forward, and a number of people caring enough about it to attend 
>regular meetings about it and to lurk on #openstack-stable. I'm fine 
>helping the team in the spin-off effort but I don't want to lead it (I 
>proved I was unable to make it my top priority in the past, so I think 
>the team deserves a more focused lead).
>
>Erno has volunteered to lead. Ihar, Alan (Pevec) and myself don't have 
>enough time to lead but are happy to help. Anyone else interested to 
>join that initial group ? Flavio ? Matt ?

I'm happy to join with obvious limited time. I've already worked w/ Erno on 
some of this stuff.

As long as Ernoi (or someone else) is still willing to lead this effort, I 
think we can give this a try.

Flavio

>
>Once we have a list of key members we should set up a meeting to 
>discuss the details.
>
>--
>Thierry Carrez (ttx)
>
>___
>___ OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: 
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
@flaper87
Flavio Percoco
__
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] [designate][chef] cookbook-openstack-dnsaas

2015-11-23 Thread Hayes, Graham

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20/11/15 21:23, JJ Asghar wrote:
> Hey everyone!
> 
> Per our goals for the M cycle, I've started 
> cookbook-openstack-dnsaas[1]. It's under my namespace for the time 
> being; but shouldn't be much longer.
> 
> I walked through the developer install guide[2] and automated the
> build. I'm posting here because I can't find a "production" install
> guide, and was hoping that maybe someone will point me in the
> direction of the diff between the two.

We have a guide for Kilo [3] - we are working on the liberty one
currently, but there should not be a huge difference. There is an
additional service (designate-zone-manager) that should follow the same
init / usage style of pool-manager, and we now support using a tooz
backend for co-ordination. This has only currently been fully tested
using Zookeeper - but as more tooz backends get written the list should
grow.


> For the community as a whole though, after we get this "publicly" 
> released, you'll be able to do a `chef exec kitchen verify` and
> you'll have a vagrant box with Designate built in just a few
> minutes.
> 
> Would the designate team like me to come to ya'lls IRC meeting to
> talk about this more?

Definitely - I can add it to the agenda for this week if you like?
We meet on Wednesdays @ 17:00 UTC in #openstack-meeting-alt [4]


> [1]: https://github.com/jjasghar/cookbook-openstack-dnsaas [2]:
> http://docs.openstack.org/developer/designate/getting-started.html

[3]:
http://docs.openstack.org/developer/designate/install/ubuntu-kilo.html
[4]: http://eavesdrop.openstack.org/#Designate_(DNSaaS)_Meeting
> -J
> 
> __
>
> 
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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWUxH7AAoJEPRBUqpJBgIiWksIAKdRcwAMva41hIW3pQOy1goY
8NL7jKfomqLELcvSJAR5uG3M7i/ltXufirW/ZfDTLT4QL7LNjnsSTYarphhB9Ma3
AkLoEpgOgrUOSkTWbZHn5rif3HX23Zl2tILFBYGj6WI8xWvdzyIhwtbjTAoxwedh
xS3yinH5IcP+wUaoAOPvd/R5xlFU5MSfpGf0+fMah/oylDyAL+6V38CBT7eOIEQU
dc12ekkxaOLXWHcCfv/ioSLV7IniODwVUd68Bf0P68oFJNx2Nf0HpygFfEWheSpG
cqrfRH+b08VbWNlISNOMp5LaoHl4sey7hDf27zhm2Pj8d5oWsclVN+2cPBmqWBk=
=iswn
-END PGP SIGNATURE-

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

Re: [openstack-dev] [oslo] Should we make qpid/proton optional dependencies? (please say yes)


On 23/11/15 10:33 +0100, Victor Stinner wrote:

Hi,

Would it be possible to use the "extra dependencies" thing in 
setup.cfg? Robert Collins started a similar change for Oslo DB for 
make DB drivers optional:

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

Sadly, this change was not merged yet.

@Robert: any progress on this change?

It would allow to ask for "Oslo Messaging with Qpid support" in 
service dependencies, without knowning the exact required Python 
packages for Qpid.


I'd rather have them as extra dependencies. Honestly, I'd even have
rabbitmq's requirements as extra dependencies.

Cheers,
Flavio



Victor

Le 19/11/2015 19:22, Matt Riedemann a écrit :

I want to fix a thing in oslo.messaging but to my surprise I can't run
pep8. This is because python-qpid-proton tries to install qpid-proton
and it can't get that because the apache site where it's hosted is down.
[1]

The apache site for qpid has actually been down a lot lately, I
coincidentally know that because of trying to access QPID security
issues for backports to things like Grizzly - yay for me!

Anyway, depending on a 3rd party repo like this to get packages just to
run pep8/unit tests in oslo.messaging is the suck.  Can we make this
optional?  Isn't the qpid stuff in tree deprecated anyway?

[1] http://paste.openstack.org/show/479460/



__
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


--
@flaper87
Flavio Percoco


signature.asc
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] [Fuel][CI] recheck/reverify support for Fuel CI jobs

There was a conversation a while ago around explicitly avoiding the empty 
namespace - see 
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041238.html

The approach I have used since is "xenserver: recheck" and "xen: recheck".

I think the appropriate command should be "fuel: recheck".

Bob

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: 20 November 2015 21:36
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI
> jobs
> 
> Why not "recheck fuel" to align with how other OpenStack 3rd party CI
> hooks work? See: recheck xen-server or recheck hyper-v
> 
> Best,
> -jay
> 
> On 11/20/2015 05:24 AM, Igor Belikov wrote:
> > Alexey,
> >
> > First of all, "refuel" sounds very cool.
> > Thanks for raising this topic, I would like to hear more opinions here.
> > On one hand, different keyword would help to prevent unnecessary
> > infrastructure load, I agree with you on that. And on another hand,
> > using existing keywords helps to avoid confusion and provides expected
> > behaviour for our CI jobs. Far too many times I've heard questions like
> > "Why 'recheck' doesn't retrigger Fuel CI jobs?".
> >
> > So I would like to hear more thoughts here from our developers. And I
> > will investigate how another third party CI systems handle this questions.
> > --
> > Igor Belikov
> > Fuel CI Engineer
> > ibeli...@mirantis.com 
> >
> >
> >
> >
> >
> >
> >> On 20 Nov 2015, at 16:00, Alexey Shtokolov  >> > wrote:
> >>
> >> Igor,
> >>
> >> Thank you for this feature.
> >> Afaiu recheck/reverify is mostly useful for internal CI-related fails.
> >> And Fuel CI and Openstack CI are two different infrastructures.
> >> So if smth is broken on Fuel CI, "recheck" will restart all jobs on
> >> Openstack CI too. And opposite case works the same way.
> >>
> >> Probably we should use another keyword for Fuel CI to prevent an extra
> >> load on the infrastructure? For example "refuel" or smth like this?
> >>
> >> Best regards,
> >> Alexey Shtokolov
> >>
> >> 2015-11-20 14:24 GMT+03:00 Stanislaw Bogatkin
>  >> >:
> >>
> >> Igor,
> >>
> >> it is much more clear for me now. Thank you :)
> >>
> >> On Fri, Nov 20, 2015 at 2:09 PM, Igor Belikov
> >> > wrote:
> >>
> >> Hi Stanislaw,
> >>
> >> The reason behind this is simple - deployment tests are heavy.
> >> Each deployment test occupies whole server for ~2 hours, for
> >> each commit we have 2 deployment tests (for current
> >> fuel-library master) and that's just because we don't test
> >> CentOS deployment for now.
> >> If we assume that developers will rertrigger deployment tests
> >> only when retrigger would actually solve the failure - it's
> >> still not smart in terms of HW usage to retrigger both tests
> >> when only one has failed, for example.
> >> And there are cases when retrigger just won't do it and CI
> >> Engineer must manually erase the existing environment on slave
> >> or fix it by other means, so it's better when CI Engineer
> >> looks through logs before each retrigger of deployment test.
> >>
> >> Hope this answers your question.
> >>
> >> --
> >> Igor Belikov
> >> Fuel CI Engineer
> >> ibeli...@mirantis.com 
> >>
> >>> On 20 Nov 2015, at 13:57, Stanislaw Bogatkin
> >>> >
> wrote:
> >>>
> >>> Hi Igor,
> >>>
> >>> would you be so kind tell, why fuel-library deployment tests
> >>> doesn't support this? Maybe there is a link with previous
> >>> talks about it?
> >>>
> >>> On Fri, Nov 20, 2015 at 1:34 PM, Igor Belikov
> >>> > wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'd like to inform you that all jobs running on Fuel CI
> >>> (with the exception of fuel-library deployment tests) now
> >>> support retriggering via "recheck" or "reverify" comments
> >>> in Gerrit.
> >>> Exact regex is the same one used in Openstack-Infra's
> >>> zuul and can be found here
> >>> https://github.com/fuel-infra/jenkins-
> jobs/blob/master/servers/fuel-ci/global.yaml#L3
> >>>
> >>> CI-Team kindly asks you to not abuse this option,
> >>> unfortunately not every failure could be solved by
> >>> retriggering.
> >>> And, to stress this out once again: fuel-library
> >>> deployment tests don't support this, so you still have to
> >>> ask for a retrigger in #fuel-infra irc

[openstack-dev] [mistral] Team meeting - 11/23/2015

2015-11-23 Thread Renat Akhmerov

Hi,

This is a reminder that we’ll have a team meeting today at #openstack-meeting 
at 16.00 UTC.

Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Liberty backporting status
Open discussion


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

Re: [openstack-dev] [cinder][glance]Upload encrypted volumes to images


On 23/11/15 03:45 +, Li, Xiaoyan wrote:

Hi all,
More help about volume encryption is needed.

About uploading encrypted volumes to image, there are three options:
1. Glance only keeps non-encrypted images. So when uploading encrypted volumes 
to image, cinder de-crypts the data and upload.
2. Glance maintain encrypted images. Cinder just upload the encrypted data to 
image.
3. Just prevent the function to upload encrypted volumes to images.



The subject and content of this email explicitly mentions uploads and
therefore I think #1 is probably the best option here. However, it is
also possible to create an image and make it point to a cinder
location. Then, you could have nova boot from that as if it was
booting from a cinder volume. That way, the image won't be sent to
Glance and it'll remain encrypted in its volume.

Hope I didn't digress from the requirements with that option, which is
still valid.

Flavio



Option 1 No changes needed in Glance. But it may be not safe. As we decrypt the 
data, and upload it to images.
Option 2 This imports encryption to Glance which needs to manage the encryption 
metadata.

Please add more if you have other suggestions. How do you think which one is 
preferred.
Appreciate for your help.

Best wishes
Lisa



__
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


--
@flaper87
Flavio Percoco


signature.asc
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] [nova] Versioned notifications... who cares about the version?




On 20/11/2015 5:12 PM, Chris Dent wrote:

On Fri, 20 Nov 2015, gord chung wrote:

i think a lot of the complexity we have in versioning is that the 
projects are too silo'd. i think some of the versioning issues would 
be irrelevant if the producer knew it's consumers before sending 
rather than producers just tossing out a chunk of data (versioned 
schema or not) and considering their job complete once it leaves it's 
own walls. the producer doesn't necessarily have to be the individual 
project teams but whoever the producer of notifications is, it should 
know it's audience.


To me this is entirely contrary to the point of having notifications
as a generic concept in the OpenStack environment. To me the point is
to ensure that it is possible for the audience to be and do _anything_.


you can still do anything and add anything to notifications but you also 
know that "attributeA/B/C are probably useful to consumerX; 
attributeD/E/F are related and all the attributes can be used by anyone."




We've become so accustomed to some of the misfeatures in the messaging
architecture that we've lost track of the fact that it could be an
event pool on which we have diverse listeners that the producers have
no requirement to know anything about. We could have nova-compute 
spinning

along shouting "I made a VM. I made another VM. Hey, I made another
VM" and "This VM is hot. Halp, I am oversubscribed." All sorts of
tools and devices need to be able to hear that stuff and choose for
themselves what they might do with it.

(This is similar to the reason we have well-formed HTTP APIs: It is so
we can have unexpected clients that do unexpected things.)


i actually view notifications different from 'well-formed HTTP APIs' as 
the initiator is not the consumer but the producer but i agree with 
"unexpected clients that do unexpected things."




It is certainly the case that if we're going to have schematized
and versioned notifications it is critical that the schema are
discoverable in a language independent fashion.

Sometimes it is hard, though, to be convinced that such formalisms are
quite what we really need. From the consumers end the concern is "do
you have these several keys that I care about?" and, as has been said,
the rest is noise. It sounds like microversioned notifications which
almost never version on the major axis might be able to provide this.

We can't allow the introduction of either the formalisms or
discoverability thereof to grant license to change stuff willy nilly.


agree, following this makes versioning pretty much moot. it's the major 
version changes i'm thinking of. how does producer know not to remove 
attributeX? how does consumer know attributeX is now attributeX.Y.Z if 
the name/location is different?



Nor should we be building formalisms that are defenses against an
architecture that's sub-optimal. We need to evolve the formalisms and
the architecture toward the ideal.



__
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


--
gord

__
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] Versioned notifications... who cares about the version?

given John's reply, i think we should start a new thread? apologies for 
hijacking log thread.


On 23/11/2015 5:01 AM, Alexis Lee wrote:

gord chung said on Fri, Nov 20, 2015 at 01:32:02PM -0500:

On 20/11/15 11:33 AM, Alexis Lee wrote:

why would a producer spit out non-useful datapoints? If no-one cares
or will ever care, it simply shouldn't be included.

... right now the
producer is just sending out a grab bag of data that it thinks is
important but doesn't define who the audience is. ...

... whoever the producer of notifications is, it should know it's
audience.

Here I, with cdent, have to disagree. The criterion has to be
"potentially useful to someone", rather than tailoring production to the
known audience.


so i'm not suggesting producers need to know the entire audience or for 
it to be tailored to a single consumer. i do think whatever we put out 
as a notification should have at least one potential recipient in mind 
(see: useful data to someone [not a hypothetical]). i'm all for 
flexibility and multiple/any consumers, but right now, to be honest, our 
notification criteria seems to be similar to "that guy outside your 
local mall yelling stuff and hoping he makes a convert."


this is just me trying to view it from another approach -- trying to vet 
our current process :)





The problem is knowing what each consumer thinks is interesting and that
isn't something that can be handled by the producer.

^ this is important.


the notification consumption service in ceilometer is essentially
just a pipeline that normalises select incoming notifications into a
data model(s) and pushes that model to whoever wants it (a known
consumer is the storage service but it's configurable to allow other
consumers).

It sounds like Ceilometer is performing a mapping function then and has
to be responsible for knowing how to do that. IE Ceilometer has to
express an opinion on relevance and presentation. This is inevitably
going to be a pain in the butt to maintain, but it's Ceilometer's job,
not the services, since it's Ceilometer trying to express an opinion.
fair enough, i'm just re-raising common feedback i receive when projects 
want to add metrics for ceilometer to collect: 'why do i need to edit 
ceilometer, it's my data.' so there is obviously a divide in the 
community as to whose responsibility it is for maintaining the data.


--
gord


__
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] [networking-ovs-dpdk]

2015-11-23 Thread Mooney, Sean K

Hi
qemu version was 2.0.0 does not support mapping hugepage as shared.
as a result the dpdk implementation of vhost-user cannot function with this 
version.
Similarly libvirt 1.2.2 has no knowledge of vhost-user.
If you are on fedora 21 then the virt-preview repo packages the required 
Libvirt and qemu.
On Ubuntu the kilo cloud archive also packages version that meet the minimum 
versions.
Looking at the log I would agree that this error is probably related to 
manually installing Libvirt and
not adding the appropriate libvirtd configuration options.
Devstack does not have native support for installing a vhost-user compatible 
Libvirt or qemu.
when using our networking-ovs-dpdk plugin we ask you to enable the virt-prevew 
or cloud archive
Before stacking so that when devestack install Libvirt/qemu it get compatible 
versions.
for centos as we have been unable to find an equivalent we explicitly install 
Libvirt/qemu.
In general we don’t provide support for installing the required version 
Libvirt/qemu in
the networking-ovs-dpdk devstack plugin.
What os are you currently using? ubuntu?
in your case enabling the kilo cloud archive, uinstalling Libvirt/qemu and then 
restacking
should provide the appropriate packages.
In liberty we use that standard neutron openvswich agent binary and set the 
agent type to DPDK OVS Agent to enable
the ovsdpdk ml2 driver to manage the node. In mitaka the standard ovs neutron 
agent and standard openvswitch ml2 drivers will be used instead.

To confirm if ovs-dpdk is running you can use the following command
sudo service ovs-dpdk status
this will check if ovs-dpdk is running by reading the pid files and checking if 
the ovsdb and ovs-vswitchd
process are running and tail the last 20ish lines of the vswitchd log file.
note this is not a systemd service so the systemd equivalent command will not 
work.

Alternative you can user ps and grep
ps aux | grep ovs

regards
sean.



From: Prathyusha Guduri [mailto:prathyushaconne...@gmail.com]
Sent: Monday, November 23, 2015 9:16 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-ovs-dpdk]

Hi Sean,
Thanks for your help before. It would be great if you look into another issue 
too.
Am able to run stack.sh successfully and all services are up. But,
libvirt version was 1.2.2 and qemu version was 2.0.0
To satisfy the minimum requirement of qemu- version >=2.1 and libvirt-version 
>= 1.2.10
I manually installed qemu and libvirt from respective sources.
Now
$ kvm --version
 /usr/bin/kvm: line 42: /tmp/qemu.orig: Permission denied
 QEMU emulator version 2.1.3, Copyright (c) 2003-2008 Fabrice Bellard

$ virsh --version
1.2.10
So basic requirement is satisfied.
Before creating an instance ran the below command,
$ nova flavor-key m1.tiny set "hw:mem_page_size=large"
Now created an instance
$ nova boot --flavor m1.tiny --image cirros-0.3.4-x86_64-uec --nic 
net-id=445e2dc5-221b-48ea-aea4-d04dee12fc7f --security-group default 
demo-instance1
It gives the ERROR :

2015-11-23 13:19:59.654 ERROR nova.virt.libvirt.host 
[req-2d9d060d-1934-4e9e-af1c-010e177bea11 None None] Connection to libvirt 
failed: error from service: CheckAuthorization: Did not receive a reply. 
Possible causes include: the remote application did not send a reply, the 
message bus security policy blocked the reply, the reply timeout expired, or 
the network connection was broken.
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host Traceback (most recent 
call last):
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File 
"/opt/stack/nova/nova/virt/libvirt/host.py", line 527, in get_connection
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host conn = 
self._get_connection()
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File 
"/opt/stack/nova/nova/virt/libvirt/host.py", line 514, in _get_connection
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host wrapped_conn = 
self._get_new_connection()
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File 
"/opt/stack/nova/nova/virt/libvirt/host.py", line 466, in _get_new_connection
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host wrapped_conn = 
self._connect(self._uri, self._read_only)
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File 
"/opt/stack/nova/nova/virt/libvirt/host.py", line 320, in _connect
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host libvirt.openAuth, uri, 
auth, flags)
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 141, in 
proxy_call
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host rv = execute(f, *args, 
**kwargs)
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 122, in execute
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host six.reraise(c, e, tb)
2015-11-23 13:19:59.654 TRACE nova.virt.libvirt.host   File

Re: [openstack-dev] [Ceilometer]:Subscribe and Publish Notification frame work in Ceilometer !




On 22/11/2015 10:04 PM, Srikanth Vavilapalli wrote:


We have found a related blueprint *[1],* which is exactly addressing 
this dynamic provisioning of pipelines via an API and making use of a 
new data store to store this configuration. But seems like that 
blueprint was abandoned due its limited usage. We agree that it may 
not be that frequent operation to change the pipeline configuration in 
all deployments, but in certain deployments, where applications desire 
to turn ON/OFF receiving these notifications based on some other 
trigger (like anomaly detection, where application might have sensed 
an anomaly based on some set of meters and wanted to turn ON few 
additional set of event/meters to confirm that and turn OFF once the 
anomaly is confirmed).


you're right, we abandoned that because of lack of usage and the idea 
was that generally you'd probably be some type of admin if you were 
editing pipeline file(s).


also, the scope was a big reason for dropping. i think modification of 
configuration via API is not just a Ceilometer requirement but a global 
OpenStack requirement. that said, it's suggested to support this level 
of functionality, it should probably be done in a way that is useful to 
all OpenStack


this cross-project item might be of interest: 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078400.html


cheers,

--
gord

__
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][glance]Upload encrypted volumes to images

On Mon, Nov 23, 2015 at 03:45:55AM +, Li, Xiaoyan wrote:
> Hi all,
> More help about volume encryption is needed. 
> 
> About uploading encrypted volumes to image, there are three options:
> 1. Glance only keeps non-encrypted images. So when uploading encrypted
> volumes to image, cinder de-crypts the data and upload.

This may be desirable in some cases, but for people wanting to provide
end to end encryption of all tenant data, unencrypting volumes when
converting them to images to store is glance is really the last thing
we want to do. Once tenant data is encrypted, the goal should be to
never decrypt it again except when booting an instance with the volume
or image.

> 2. Glance maintain encrypted images. Cinder just upload the encrypted
> data to image.

That is highly desirable as an option, since it allows glance to remain an
relatively untrusted component. The image signature work will soon allow
Nova to consider glance as untrusted, by allowing Nova to verify that Glance
has not tampered with the data that was provided by user, nor tried to serve
Nova data from a different user.  Following this lead, I think the ability
to prevent Glance seeing any plaintext data from the image is an obvious
beneficial step forwards.

> 3. Just prevent the function to upload encrypted volumes to images.

That's obviously fairly limiting.

> Option 1 No changes needed in Glance. But it may be not safe. As we
> decrypt the data, and upload it to images.

s/may be not safe/is not safe/.

> Option 2 This imports encryption to Glance which needs to manage the
> encryption metadata.

Glance doesn't need to do all that much besides recording a few
bits of metadata, so that doesn't seem unreasonable todo.

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

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

Re: [openstack-dev] [cinder][glance]Upload encrypted volumes to images