Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

[Salvatore Orlando]

Some thoughts inline.

Salvatore

On 11 March 2016 at 23:15, Carl Baldwin  wrote:

> Hi,
>
> I have started to get into coding [1] for the Neutron routed networks
> specification [2].
>
> This spec proposes a new association between network segments and
> subnets.  This affects how IPAM needs to work because until we know
> where the port is going to land, we cannot allocate an IP address for
> it.  Also, IPAM will need to somehow be aware of segments.  We have
> proposed a host / segment mapping which could be transformed to a host
> / subnet mapping for IPAM purposes.
>
> I wanted to get the opinion of folks like Salvatore, John Belamaric,
> and you (if you interested) on this.  How will this affect the
> interface to pluggable IPAM and how can pluggable implementations can
> accommodate this change.  Obviously, we wouldn't require
> implementations to support it but routed networks wouldn't be very
> useful without it.  So, those implementations would not be compatible
> when routed networks are deployed.
>

I think it is ok to augment the IPAM interface. As any API, it needs to
evolve.
I don't think we have a story for its versioning; therefore I reckon that
the simplest way to achieve this would be adding a new method for
segment-aware IPAM, that only drivers supporting routing networks will be
required to implement.



>
> Another related topic was brought up in the recent Neutron mid-cycle.
> We talked about adding a service type attribute to to subnets.  The
> reason for this change is to allow operators to create special subnets
> on a network to be used only by certain kinds of ports.  For example,
> DVR fip namespace gateway ports burn a public IP for no good reason.
> This new feature would allow operators to create a special subnet in
> the network with private addressing only to be used by these ports.
>
> Another example would give operators the ability to use private
> subnets for router external gateway ports if shared SNAT is not needed
> or doesn't need to use public IPs.
>
> These are two ways in which subnets are taking on extra
> characteristics which distinguish them from other subnets on the same
> network.  That is why I lumped them together in to one thread.
>

I wonder if we could satisfy this requirement with tags - as it seems these
subnets are anyway operator-owned you should probably not worry about
regular tenants fiddling with them, and therefore the "helper" subnet
needed for the fip namespace could just be tagged to the purpose.


>
> Carl
>
> __
> OpenStack Development Mailing 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] [chef] PTL Candidacy

[Samuel Cassiba]

Howdy,

I am announcing my candidacy as Chef OpenStack PTL for the Newton release
cycle.

In the Mitaka cycle, we've accomplished quite a bit, with an incredible
velocity.
The core cookbooks underwent a significant refactor, removing some 18k
lines of
code and refactoring another 4k lines. We also saw the introduction of
integration tests in our gates, as well as some third-party vendor support
in Liberty. With the initial round of refactoring completed for Mitaka, we
have
a more streamlined set of cookbooks upon which to build new features.

Being under the big tent is not easy, and we have great challenges in front
of us. My main goal for the Newton cycle is to further reduce the barrier to
entry to the cookbooks, so that we can more easily welcome new contributors
and hopefully more adoption.

- Documentation
I'd like to place an emphasis on more documentation. I believe that this
will enable downstream developers and operators to better uptake newer
releases
as well as contribute back to the project. Our users need better guidance
when
it comes to best practices when using the cookbooks.

- Continuous Integration
We've done a lot on CI, with the integration jobs, but we must also test
different deployment scenarios as proof of concept that a downstream user
can
take these same cookbooks and deploy a production-ready OpenStack cluster.

- Community engagement
I would like to further our collaboration with other projects, notably
OpenStack Infra and upstream packagers (Ubuntu Cloud Archive and RDO), but
also
other OpenStack projects like Heat, TripleO, Magnum, Tempest and
Documentation.
This collaboration makes the OpenStack ecosystem better by providing more
freedom of choice for users when deploying OpenStack. We must continue that
with coordination and maintaining strong lines of communication.

I would greatly appreciate your support for PTL, if you'll have me, and I'm
looking forward to growing the Chef OpenStack team.

The official elections review is here:
https://review.openstack.org/#/c/291967/

Samuel Cassiba (sc`)
__
OpenStack Development Mailing 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] [app-catalog] PTL Candidacy

[Christopher Aedo]

It's time again for the PTL elections, and I'm throwing my hat in the
ring to lead the Community App Catalog project (https://apps.openstack.org).

During the last election cycle I made a few promises which I believe
I've delivered on.  We've continued to operate entirely in the open
including holding weekly meetings on IRC along with bringing a few
issues to the mailing list when I felt we could benefit from opinions
of a broader audience. Another bit of success is that we've adjusted
the schema to support additional asset types, and have received our
first in this category in the form of a TOSCA template[1].  We still
have work to do on the web site in order to actually show additional
asset types in addition to adding that capability to the App Catalog
Horizon plugin, but that work is in progress.

The other significant effort was to implement a legitimate API, which
is now showing promise via the work to implement GLARE as the back
end[2].  In fact we will have a working PoC by the summit in Austin -
and we'll certainly complete that work before the following summit. I
will do everything I can to make sure the folks working on this get
all the support they need.

Looking ahead to the next cycle, the two biggest things the Community
App Catalog needs are a clarified mission and a whole lot more
publicity.  I'm guilty of living in my own bubble here, assuming
everybody must wake up thinking about the catalog after dreaming about
it all night long (just like me!)  But it turns out there are plenty
of people in the community who haven't even *heard* of the Community
App Catalog. I realize I need to work a lot harder to bring attention
to our efforts here.  What we've built can benefit most OpenStack
projects, and should become the standard place to host assets noted in
our documentation. There are many other ways we can all be using the
Community App Catalog to benefit OpenStack as a whole, and I'll start
to discuss and debate my ideas on the mailing lists in the weeks and
months to come.

Speaking of clarified mission, I intend to work within our own
community to build consensus around what we mean when we say "an
OpenStack App".  I believe if we can start to agree on that, and agree
on the best way(s) to package and distribute such things, the
Community App Catalog will become much more valuable to a larger
audience very quickly.

I think the Community App Catalog has tremendous potential; if you'll
have me as PTL again I'll keep working my hardest to deliver!

[1]: https://review.openstack.org/289132
[2]: https://review.openstack.org/276857

The official elections PR is here BTW:
https://review.openstack.org/#/c/291496/

-Christopher

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

[openstack-dev] [murano] PTL Noncandidacy

[Serg Melikyan]

I would like to announce that I am not going to run for Murano PTL this
release cycle. I was the official Murano PTL for the past two cycles and I
feel that it's time for me to pass this role to someone new and more
energetic.

In this e-mail I want to reflect on some changes in community activity
around Murano project that happened in the last few cycles.

Murano started as a one company contribution and that can be easily seen at
stackalytics.org. But I'm happy that this is changing, the number of
commits from non-Mirantis engineers grew from 15% in Kilo [0], to 25% in
Liberty [1], and to 39% in Mitaka [2]. Which means that since the last year
the relative contribution from other companies has more than doubled.

I am very proud of this numbers but not for myself. Kirill Zaitsev is the
person behind this achievement.

He was very active on IRC, helping people step-by-step in their
contribution and encouraging them along the way. He also was the top
reviewer in this cycle with 754 (22% of total) reviews for Murano [3]. He
was participating as a mentor in Outreachy program, mentoring and helping
people to participate in open source development. He was doing all of that
while contributing considerable amount of changes to Murano and other
projects.

Kirill,

Thank you for everything you did for the team and for helping me to lead
the project more than you can imagine. I am waiting for your
self-nomination ;)

References:
[0] http://stackalytics.com/?module=murano-group=kilo=commits
[1]
http://stackalytics.com/?module=murano-group=liberty=commits
[2]
http://stackalytics.com/?module=murano-group=mitaka=commits
[3] http://stackalytics.com/?module=murano-group=mitaka=marks

-- 
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] PTL candidacy

[Jim Rollenhagen]

Hi all,

I've had the pleasure of serving the ironic community as PTL for the
Mitaka cycle, and I'd like to do it again for the Newton cycle, if
you'll have me. We've done some amazing things over the past 6 months
and I think we can do even more over the next 6 months.

Things I'd like to do:

* Bring on more core reviewers. I've noticed some people interacting
  more with the community, as well as reviewing more, and I'd like
  for us to mentor them to get them to a place where they will be an
  effective core.

* Finish the neutron integration. I failed during this cycle to
  sufficiently herd cats to help get this done, but we're almost there
  and it should be easy to finish this early in Newton. We should also
  start working on the even bigger plan of fully decoupling the
  user-facing neutron networking from physical infrastructure.

* Begin working on boot-from-volume. This is an often requested feature
  that will take a long time to get right. We should start working on
  it now to make sure we can deliver it in Newton or Ocata.

* Seriously, make our gate better. We keep talking about this, and
  while we continue to make small improvements, I'd like our gate
  to be rock-solid with substantial coverage (including upgrades!) by
  the end of Newton.

* Get the work done in Nova to move to a multiple compute service
  model. This is the cause of a number of pain points. We need to get
  the ironic side to enable this done ASAP, and I hope to also have
  the nova code done by Newton, though I honestly wouldn't be surprised
  if it lagged to Ocata.

Whether or not you elect me as PTL, I look forward to contributing to
all of these items and more during the Newton cycle. :)

Thanks for reading,

// jim

P.S. The more official version of this email is here:
https://review.openstack.org/#/c/291964/

__
OpenStack Development Mailing 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] [ironic] ironic 5.0.0, the rest of mitaka, and beyond

[Jim Rollenhagen]

Hi all,

(grab some coffee, this is a bit long)

Today we released ironic 5.0.0. Congrats to the team, and thank you for
your hard work so far this cycle! You've all done an amazing job getting
things done. The release notes[0] show how many awesome things we've
shipped this cycle. Even Doug complimented us on making our notes
awesome :D

 jroll : I have to say, now that I've seen the announcement
email: nice job with reno release notes there! :-)

Now, that said, there's still some things I'd like to get done this
cycle; some are action items from the midcycle, and some are patches
we'd like to land in ironic 5.1.0, which will be the basis of
stable/mitaka. We'll need everyone to pitch in to get this stuff done.

First though, I'm really sad to say we need to bump the networking work
to Newton. We got a lot of the underpinnings in, which is great, but
moving forward from here is a pretty large change in our core driver
code, and API changes. I'd rather not rush those through, especially
when the Mitaka versions of our client, and Nova, won't have them done.
Let's keep working on those and land them first thing in Newton.
To be clear, this was the main item I wanted to get done in Mitaka. I
failed to sufficiently herd all of the cats needed to finish this. We
got a late start, and made an even later decision that the pluggability
of it was the wrong direction and needed to be rewritten. That's totally
on me, and I feel pretty bad about it. Sorry, community. :(

That said, things we need to do.

Follow-up items from the midcycle, that we should do soon. Most of these
are "before summit" rather than "before end of Mitaka".

* jroll is going to work on a priorities dashboard that we can use
  during Newton to help focus on the right thing.

* Deva is going to lead the work on setting up a timebox in our meeting
  to triage a few specs, as far as if it's worth looking at in the short
  term. We should also be sure to triage all RFEs, and make sure we
  continue to keep them triaged each week.
  * Let's get a few specs cores in an audio (and video?) conference for
a couple hours next week to push through all of the existing RFEs,
and make a plan to keep them up to date.

* Keep working on our gate.

* Julia is going to write a spec for the reference implementation of
  boot-from-volume.
  * We also should be reviewing the spec for the data model for all the
data that needs to be passed to ironic.

* jroll to separate specs for the filter API from the claims API.

* Review the "VLAN aware baremetal" spec
  * tl;dr unbinds user-facing neutron networking from physical infra
  * https://review.openstack.org/#/c/277853/

* Plan summit sessions! Please put your ideas here:
  https://etherpad.openstack.org/p/ironic-newton-summit

And code that we should land for the 5.1.0 release:

* Anything fixing critical/high bugs

* Partition image support for agent drivers
  * https://review.openstack.org/#/c/160224/
  * https://review.openstack.org/#/c/162008/

* Others? I haven't done a full sweep of everything out there. I'd love
  suggestions on what else should land in Mitaka. :)
  * (this has been made harder by not keeping up to date on approving RFEs)

Last, (again), we need to keep hacking on the neutron integration code
and get that all ready to land ASAP in Newton.

As a reminder, April 1 is the last day to cut the 5.1.0 release:
http://releases.openstack.org/mitaka/schedule.html

If you got this far, thanks for reading. I'm confident we can get this
stuff done in a timely fashion. Thanks in advance for helping. :)

// jim

[0] http://docs.openstack.org/releasenotes/ironic/mitaka.html


__
OpenStack Development Mailing 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] PTL noncandidacy

[Richard Jones]

Thanks for everything David. My involvement and engagement with the project
would not be what it is without your leadership. I look forward to
continuing to work with and learn from you!


   Richard

On 12 March 2016 at 04:19, David Lyle  wrote:

> After five cycles as PTL of Horizon, I've decided not to run for the
> Newton cycle.
>
> I am exceptionally proud of the things we've accomplished over this
> time. I'm amazed by how much our project's community has grown and
> evolved.
>
> Looking at the community now, I believe we have a tremendous group of
> contributors for moving forward. There are several people capable of
> becoming great PTLs and overall the community will be healthier with
> some turnover in the PTL role. I feel honored to have had your trust
> over this time and lucky to have worked with such great people.
>
> I will still be around and will help the next PTL make a smooth
> transition where requested.
>
> David
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Andrew Woodward]

I think we can address it by retaining deployment logs in nailgun/ui, this
also removes the chicken and egg problem. after LMA is deployed it can be
allowed to re-own 'logs' button on UI once it's deployed, including
redirecting fuel logs there.

On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov 
wrote:

> We can sort out details later. In a worst case, the warning will be there
> in Newton too, and feature will go away only in O* release. So let's
> proceed with the bug..
>
> On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh 
> wrote:
>
>> We can add the warning, but I think before we do this we should have
>> clear migration plan. According to this thread, some parts are still not
>> clear.
>>
>> 2016-03-11 22:00 GMT+03:00 Mike Scherbakov :
>>
>>> Deprecation warning for Fuel Mitaka:
>>> https://bugs.launchpad.net/fuel/+bug/1556244.
>>>
>>>
>>> On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko 
>>> wrote:
>>>
 Since there are a lot of supporters for this idea, what do you folks
 think about creating a BP spec where we can describe what we should do in
 order to remove logs from UI and Nailgun? I also propose to file a bug
 about adding a deprecation warning to Mitaka release of Fuel.


 11 бер. 2016 р. о 16:55 Bogdan Dobrelya 
 написав(ла):


 On 03/11/2016 04:46 PM, Mike Scherbakov wrote:

 +1 to remove logs from Fuel UI in Fuel Newton.
 In Fuel Mitaka we'd need to put a deprecation warning somewhere.


 I agree, there is not much sense having non flexible (no content
 filters) logs view in UI. LMA plugins shall cover this area as well.



 On Fri, Mar 11, 2016, 04:57 Patrick Petit >> wrote:


On 11 March 2016 at 12:51:40, Igor Kalnitsky
(ikalnit...@mirantis.com >) wrote:

Patrick,

Sorry, but I meant another question. I thought that LMA plugin should

be installed in some environment before we can start use it. Is
this a
case? If so, it means we can't use for master node until some
environment is deployed.


Right. This is the chicken and egg problem I mentioned earlier...

But this is not a “problem” specific to Fuel. My take on this is is
that ops management tooling (logging, monitoring) should be
installed off-band before any OpenStack deployment. In fact, in
real-world usage, we frequently get asks to have the monitoring and
logging services of StackLight installed permanently for
multi-enviroments. And so, one approach would be to make Stacklight
backend services the first bits of software installed by Fuel (if
not already there), then reconfigure Fuel to hook into those
services and only then, enter into the regular OpenStack
provisioning mode.



On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit
>> wrote:


 On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com <
 mailto:ikalnit...@mirantis.com >)
 wrote:

 Hey Roman,

 Thank you for bringing this up. +1 from my side, especially taking
 into account the patch where we tried to solve logrotated logs problem
 [1]. It's complex and unsupportable, as well as already existed
 logview code in Nailgun.

 Patrick, Simon,

 Does LMA plugin support logs from master node? Or it's designed to
 watch environment's logs?

 No it’s not designed specifically for environment logs. Can be adapted
 to
 any log format.

 Would just need to write a parser like you would with logstach when
 logs are
 not standard.

 Patrick



 Thanks,
 Igor


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

 On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit >> wrote:

 Fuelers,

 As Simon said, we already have a log centralisation solution for MOS
 delivered as a Fuel plugins known as StackLight / LMA toolset. And so
 objectively, there is no need to have log management in Nailgun anymore.

 To
 go one step further we suggested several times to have a StackLight
 agent
 installed on the Fuel master node to also collect and centralise those
 logs.
 There is a little bit of a chicken and egg problem to resolve but I
 think
 it
 is worth a try to have that nailed down in the roadmap for Fuel 10.
 Cheers
 - Patrick


 On 11 March 

Re: [openstack-dev] Branch miss-match between server and client in Kilo

[Sridhar Ramaswamy]

Hi Janki,

Thanks for reporting this issue and it is a valid one. However we need to
fix up our gate tests to skip doc8 test for stable/kilo to merge your
patchset. Given Kilo is close to EOL (end-of-life) would you mind switching
over to use stable/liberty ? For Tacker, Kilo was one of the early release
and we came a long way "cleaning up" the project over Liberty and Mitaka
(which is wrapping up). Again, if you are particular about Kilo for any
specific reason, let us know. We will find a way to work it out.

BTW, I see you are new to OpenStack contributions - a warm welcome! We have
many interesting work items that you could take up, see [1], particularly
the ones with low-hanging-fruit tag. Stop by #tacker channel if you need
help picking one.

- Sridhar

[1] https://goo.gl/S3FAOk


On Wed, Mar 9, 2016 at 8:16 PM, Janki Chhatbar 
wrote:

> Hi All
>
> Greetings for the day!
>
> I have noticed that while installing* OpenStack Kilo* using DevStack, the
> server components cloned are stable/kilo whereas the client components
> cloned are master. This leads to errors in installation or commands
> miss-match. For eg.
>
> *In tacker,*
> tacker git repo is stable/kilo which points to incorrect git repo URL. I
> have filled a  bug and proposed a patch for this (
> https://bugs.launchpad.net/tacker/+bug/1555130)
>
> *In Magnum*,
> *magnum stable/kilo* clones *python-magnumclient master* which leads to
> command mismatch (https://bugs.launchpad.net/magnum/+bug/1509273).
>
>
>1. Does this affect all other services?
>2. Does this mean that the branch needs to be changed for all the
>service's clients? The change will be in /devstack/lib/{service} file in
>"GITBRANCH" variable.
>
>  If changes are required, I am willing to work on those.
>
> Thanking you
>
> Janki Chhatbar
> OpenStack | SDN | Docker
> (+91) 9409239106
> simplyexplainedblog.wordpress.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] PTL noncandidacy

[Tripp, Travis S]

David,

Thank you so much for the patience and wisdom you’ve demonstrated over the 
years.
I always appreciate sense of humor you bring to IRC.

For the love of all that is OpenStack, please stay active on Horizon!

-Travis




On 3/11/16, 10:19 AM, "David Lyle"  wrote:

>After five cycles as PTL of Horizon, I've decided not to run for the
>Newton cycle.
>
>I am exceptionally proud of the things we've accomplished over this
>time. I'm amazed by how much our project's community has grown and
>evolved.
>
>Looking at the community now, I believe we have a tremendous group of
>contributors for moving forward. There are several people capable of
>becoming great PTLs and overall the community will be healthier with
>some turnover in the PTL role. I feel honored to have had your trust
>over this time and lucky to have worked with such great people.
>
>I will still be around and will help the next PTL make a smooth
>transition where requested.
>
>David
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Segments, subnet types, and IPAM

[Carl Baldwin]

Hi,

I have started to get into coding [1] for the Neutron routed networks
specification [2].

This spec proposes a new association between network segments and
subnets.  This affects how IPAM needs to work because until we know
where the port is going to land, we cannot allocate an IP address for
it.  Also, IPAM will need to somehow be aware of segments.  We have
proposed a host / segment mapping which could be transformed to a host
/ subnet mapping for IPAM purposes.

I wanted to get the opinion of folks like Salvatore, John Belamaric,
and you (if you interested) on this.  How will this affect the
interface to pluggable IPAM and how can pluggable implementations can
accommodate this change.  Obviously, we wouldn't require
implementations to support it but routed networks wouldn't be very
useful without it.  So, those implementations would not be compatible
when routed networks are deployed.

Another related topic was brought up in the recent Neutron mid-cycle.
We talked about adding a service type attribute to to subnets.  The
reason for this change is to allow operators to create special subnets
on a network to be used only by certain kinds of ports.  For example,
DVR fip namespace gateway ports burn a public IP for no good reason.
This new feature would allow operators to create a special subnet in
the network with private addressing only to be used by these ports.

Another example would give operators the ability to use private
subnets for router external gateway ports if shared SNAT is not needed
or doesn't need to use public IPs.

These are two ways in which subnets are taking on extra
characteristics which distinguish them from other subnets on the same
network.  That is why I lumped them together in to one thread.

Carl

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

Re: [openstack-dev] [QA] Not running for PTL

[Jim Meyer]

> On Mar 11, 2016, at 11:34 AM, Matthew Treinish  wrote:
> 
> Hi everyone,
> 
> I'm writing this to announce that I am not running for QA PTL this cycle. I've
> been the QA PTL for the past 4 cycles and I think it's time for another person
> to take over the role. I think during the past 4 cycles the QA community has
> grown greatly and become a much larger and stronger community compared to 
> when 
> I first took on the position in the Juno cycle.
> 
> I strongly believe in the diversity of leadership and ideas, and I don't want
> the community to grow stagnant because it becomes synonymous with just my 
> voice.
> Being a PTL is not the same as being an autocrat and I think it's time for
> another person to step up and take over the QA PTL spot.
> 
> That being said, I'm not planning on going anywhere or leaving the project. I
> fully intend to continue working and being heavily involved with the QA 
> program,
> as I have for been the past 2 years. (although maybe with a bit more free time
> now)
> 
> -Matt Treinish

Thanks, Matt, for your tireless efforts in what's so often an under-recognized 
yet critical area.

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

Re: [openstack-dev] [nova] Nova PTL for Newton

[Ken'ichi Ohmichi]

Thank you so much, John.

Nova PTL is always a hard position, and you have accelerated our
collaboration with your leadership.

Thanks

2016-03-11 11:22 GMT-08:00 John Garbutt :
> Hi,
>
> It has been greatly rewarding serving you all as Nova PTL over the
> Liberty and Mitaka cycles. I thank you all for the support,
> encouragement and advice I have been given over the last year. I
> really appreciate that. (That's british speak for "I love you all", or
> something like that).
>
> I don't plan on standing for the Newton cycle. I think its a good time
> for someone to bring fresh energy, ideas, and drive to help keep Nova
> driving forward. I have enjoyed my time as PTL, as such, I would
> consider standing again. We have a good number of folks stepping up to
> lead different parts of the project. I hope we can grow that effort,
> and I hope to continue to be part of that.
>
> I aim to continue contributing to Nova (I hope to be in Austin, and I
> hope to write some code again soon). I will certainly make time to
> ensure a smooth transition to the next PTL.
>
> Many 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 Development Mailing 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-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Maksim Malchuk]

Matthew, congrats!


On Fri, Mar 11, 2016 at 10:59 PM, Sergii Golovatiuk <
sgolovat...@mirantis.com> wrote:

> Hi,
>
> Personally, I give my +2 to Matthew without any doubts. Matthew reviews
> has a lot of technical details and guidances. As always he is bright
> helping people over IRC or mailing list.
>
> Please welcome a new member of fuel-library-core group.
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Wed, Mar 2, 2016 at 5:44 PM, Aleksandr Didenko 
> wrote:
>
>> +1 for Michael Polenchuk
>>
>> On Wed, Mar 2, 2016 at 5:33 PM, Fedor Zhadaev 
>> wrote:
>>
>>> +1 for Michael :)
>>>
>>> ср, 2 мар 2016, 17:50 Matthew Mosesohn :
>>>
 Hi all,

 Thank you for the nominations and +1s. I would like to propose Michael
 Polenchuk to add as a maintainer to fuel-library to take my spot when
 I leave the maintainers list.

 Best Regards,
 Matthew Mosesohn

 On Fri, Feb 26, 2016 at 3:54 PM, Kyrylo Galanov 
 wrote:
 > Finally! +2 !
 >
 > On Fri, Feb 26, 2016 at 9:08 PM, Roman Vyalov 
 wrote:
 >>
 >> +1
 >>
 >> On Fri, Feb 26, 2016 at 12:31 PM, Aleksey Kasatkin
 >>  wrote:
 >>>
 >>> +1
 >>>
 >>>
 >>> Aleksey Kasatkin
 >>>
 >>>
 >>> On Thu, Feb 25, 2016 at 11:59 PM, Sergey Vasilenko
 >>>  wrote:
 
  +1
 
 
  /sv
 
 
 
 
 __
  OpenStack Development Mailing 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

>>> --
>>> Kind Regards,
>>> Fedor Zhadaev
>>>
>>> skype: zhadaevfm
>>> IRC: fzhadaev
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
>


-- 
Best Regards,
Maksim Malchuk,
Senior DevOps Engineer,
MOS: Product Engineering,
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] [nova] The vote for new Nova API sub-team meeting time

[Tony Breeds]

On Fri, Mar 11, 2016 at 07:16:41PM +0800, Alex Xu wrote:
> Hi, folks,
> 
> From the result of vote, all the peoples are available on Wednesday at
> 1300UTC. If no more questions, I think we can start with new time from next
> week. And we will switch to #openstack-meeting-4 channel.

Thanks Alex.  When you're ready please subit a review to irc-meetings to change
the data on eavesdop.o.o

Tony.


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] [QA] Not running for PTL

[Ken'ichi Ohmichi]

2016-03-11 11:34 GMT-08:00 Matthew Treinish :
> Hi everyone,
>
> I'm writing this to announce that I am not running for QA PTL this cycle. I've
> been the QA PTL for the past 4 cycles and I think it's time for another person
> to take over the role. I think during the past 4 cycles the QA community has
> grown greatly and become a much larger and stronger community compared to when
> I first took on the position in the Juno cycle.
>
> I strongly believe in the diversity of leadership and ideas, and I don't want
> the community to grow stagnant because it becomes synonymous with just my 
> voice.
> Being a PTL is not the same as being an autocrat and I think it's time for
> another person to step up and take over the QA PTL spot.

Thank you very much for your great works in long term, Matthew.
You have worked with a lot of people between many projects/timezones
as QA PTL, the work seems hard for me.

> That being said, I'm not planning on going anywhere or leaving the project. I
> fully intend to continue working and being heavily involved with the QA 
> program,
> as I have for been the past 2 years. (although maybe with a bit more free time
> now)

Yeah, we still need  you :-)

Thanks
Ken Ohmichi

---
__
> OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Mike Scherbakov]

We can sort out details later. In a worst case, the warning will be there
in Newton too, and feature will go away only in O* release. So let's
proceed with the bug..

On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh 
wrote:

> We can add the warning, but I think before we do this we should have clear
> migration plan. According to this thread, some parts are still not clear.
>
> 2016-03-11 22:00 GMT+03:00 Mike Scherbakov :
>
>> Deprecation warning for Fuel Mitaka:
>> https://bugs.launchpad.net/fuel/+bug/1556244.
>>
>>
>> On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko 
>> wrote:
>>
>>> Since there are a lot of supporters for this idea, what do you folks
>>> think about creating a BP spec where we can describe what we should do in
>>> order to remove logs from UI and Nailgun? I also propose to file a bug
>>> about adding a deprecation warning to Mitaka release of Fuel.
>>>
>>>
>>> 11 бер. 2016 р. о 16:55 Bogdan Dobrelya 
>>> написав(ла):
>>>
>>>
>>> On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
>>>
>>> +1 to remove logs from Fuel UI in Fuel Newton.
>>> In Fuel Mitaka we'd need to put a deprecation warning somewhere.
>>>
>>>
>>> I agree, there is not much sense having non flexible (no content
>>> filters) logs view in UI. LMA plugins shall cover this area as well.
>>>
>>>
>>>
>>> On Fri, Mar 11, 2016, 04:57 Patrick Petit >> >> wrote:
>>>
>>>
>>>On 11 March 2016 at 12:51:40, Igor Kalnitsky
>>>(ikalnit...@mirantis.com >> >) wrote:
>>>
>>>Patrick,
>>>
>>>Sorry, but I meant another question. I thought that LMA plugin should
>>>
>>>be installed in some environment before we can start use it. Is
>>>this a
>>>case? If so, it means we can't use for master node until some
>>>environment is deployed.
>>>
>>>
>>>Right. This is the chicken and egg problem I mentioned earlier...
>>>
>>>But this is not a “problem” specific to Fuel. My take on this is is
>>>that ops management tooling (logging, monitoring) should be
>>>installed off-band before any OpenStack deployment. In fact, in
>>>real-world usage, we frequently get asks to have the monitoring and
>>>logging services of StackLight installed permanently for
>>>multi-enviroments. And so, one approach would be to make Stacklight
>>>backend services the first bits of software installed by Fuel (if
>>>not already there), then reconfigure Fuel to hook into those
>>>services and only then, enter into the regular OpenStack
>>>provisioning mode.
>>>
>>>
>>>
>>>On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit
>>>>> >> wrote:
>>>
>>>
>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com <
>>> mailto:ikalnit...@mirantis.com >)
>>> wrote:
>>>
>>> Hey Roman,
>>>
>>> Thank you for bringing this up. +1 from my side, especially taking
>>> into account the patch where we tried to solve logrotated logs problem
>>> [1]. It's complex and unsupportable, as well as already existed
>>> logview code in Nailgun.
>>>
>>> Patrick, Simon,
>>>
>>> Does LMA plugin support logs from master node? Or it's designed to
>>> watch environment's logs?
>>>
>>> No it’s not designed specifically for environment logs. Can be adapted to
>>>
>>> any log format.
>>>
>>> Would just need to write a parser like you would with logstach when logs
>>> are
>>> not standard.
>>>
>>> Patrick
>>>
>>>
>>>
>>> Thanks,
>>> Igor
>>>
>>>
>>> [1]: https://review.openstack.org/#/c/243240/
>>>
>>> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit >> mailto:ppe...@mirantis.com >> wrote:
>>>
>>> Fuelers,
>>>
>>> As Simon said, we already have a log centralisation solution for MOS
>>> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
>>> objectively, there is no need to have log management in Nailgun anymore.
>>>
>>> To
>>> go one step further we suggested several times to have a StackLight agent
>>>
>>> installed on the Fuel master node to also collect and centralise those
>>> logs.
>>> There is a little bit of a chicken and egg problem to resolve but I think
>>>
>>> it
>>> is worth a try to have that nailed down in the roadmap for Fuel 10.
>>> Cheers
>>> - Patrick
>>>
>>>
>>> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com <
>>> mailto:spasqu...@mirantis.com >)
>>> wrote:
>>>
>>> Hello Roman,
>>>
>>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko >> mailto:m...@romcheg.me >>
>>> wrote:
>>>
>>>
>>> Fuelers,
>>>
>>> I remember we’ve discussing this topic in our couloirs before but I’d
>>> like
>>> to bring that discussion to a more official format.
>>>
>>> Let me state 

Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained

[Victor Stinner]

Le 08/03/2016 22:22, gordon chung a écrit :

it seems like the main reason there are so many projects leveraging WSME
is because everyone is just using Ironic or Ceilometer as the starting
point for their APIs. can we officially say to all new projects who plan
on copying API logic of Ironic et al.: 'stop'.


Or maybe start to upgrade these two projects to use the state of the 
art, since they look to be used as example :-)


Victor

__
OpenStack Development Mailing 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] [FFE] Unlock Settings Tab

[Igor Kalnitsky]

Hey Dmitry,

I confirm that we agreed on feature design, and you can proceed with
granting exception.

,- Igor

On Fri, Mar 11, 2016 at 8:27 PM, Alexey Shtokolov
 wrote:
> Hi Dmitry,
>
> We've reached the design consensus with Igor today. Could you please remove
> the conditional status of the FFE request?
> As agreed: the merge deadline is March 24.
>
> --
> WBR, Alexey Shtokolov
>
> 2016-03-11 2:27 GMT+03:00 Dmitry Borodaenko :
>>
>> Granted. Design consensus deadline for the task history part of this
>> feature is extended to March 11. This does not change the merge deadline
>> for other parts of this feature, which is still March 24.
>>
>> --
>> Dmitry Borodaenko
>>
>>
>> On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
>> > Dmitry,
>> >
>> > We are really close to have the consensus, but we need one more meeting
>> > with Fuel-Python Component Lead Igor Kalnitsky to make the final
>> > decision.
>> > All patches [0] are on review. The meeting is scheduled for tomorrow
>> > (03/11
>> > 1:30pm CET).
>> > Could you please grant us one more day for it?
>> >
>> > [0] -
>> > https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
>> >
>> > --
>> > WBR, Alexey Shtokolov
>> >
>> > 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko :
>> >
>> > > Granted, merge deadline March 24, task history part of the feature is
>> > > to
>> > > be excluded from this exception grant unless a consensus is reached by
>> > > March 10.
>> > >
>> > > Relevant part of the meeting log starts at:
>> > >
>> > >
>> > > http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
>> > >
>> > > --
>> > > Dmitry Borodaenko
>> > >
>> > >
>> > > On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh wrote:
>> > > > Oh, so there is a spec. I was worried that this patch has
>> > > > "WIP-no-bprint-assigned-yet" string in the commit message, so I
>> > > > thought
>> > > > there is no spec for it. So the commit message should be updated to
>> > > > avoid
>> > > > such confusion.
>> > > >
>> > > > It's really good I've seen this spec. There are plans to overhaul UI
>> > > > data
>> > > > format description which we use for cluster and node settings to
>> > > > solve
>> > > some
>> > > > issues and implement long-awaited features like nested structures,
>> > > > so we
>> > > > might also want to deprecate our expression language and also switch
>> > > > to
>> > > > YAQL (and thus port YAQL to JS).
>> > > >
>> > > > 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin :
>> > > >
>> > > > > Vitaly
>> > > > >
>> > > > > Thanks for bringing this up. Actually the spec has been on review
>> > > > > for
>> > > > > almost 2 weeks: https://review.openstack.org/#/c/282695/.
>> > > > > Essentially,
>> > > > > this is not introducing new DSL but replacing the existing one
>> > > > > with
>> > > more
>> > > > > powerful extendable language which is being actively developed
>> > > > > within
>> > > > > OpenStack and is already a part of other projects (Murano,
>> > > > > Mistral),
>> > > which
>> > > > > has much more contributors, can return not only boolean but any
>> > > arbitrary
>> > > > > collections. So it means that we want to deprecate current
>> > > > > Expression
>> > > > > language that you wrote and replace it with YAQL due to those
>> > > > > reasons.
>> > > You
>> > > > > are not going to extend this Expression-based language in 3 weeks
>> > > > > up to
>> > > > > level of support of extensions, method overloading, return of
>> > > > > arbitrary
>> > > > > collections (e.g. we also want to calculate cross-depends and
>> > > > > requires
>> > > > > fields on the fly which require for it to return list of dicts)
>> > > > > and
>> > > support
>> > > > > of this stuff on your own, are you?
>> > > > >
>> > > > > On Wed, Mar 2, 2016 at 10:09 AM, Vitaly Kramskikh <
>> > > vkramsk...@mirantis.com
>> > > > > > wrote:
>> > > > >
>> > > > >> I think it's not a part of best practices to introduce changes
>> > > > >> like
>> > > > >> https://review.openstack.org/#/c/279714/ (adding yet another DSL
>> > > > >> to
>> > > the
>> > > > >> project) without a blueprint and review and discussion of the
>> > > > >> spec.
>> > > > >>
>> > > > >> 2016-03-02 2:19 GMT+07:00 Alexey Shtokolov
>> > > > >> :
>> > > > >>
>> > > > >>> Fuelers,
>> > > > >>>
>> > > > >>> I would like to request a feature freeze exception for "Unlock
>> > > settings
>> > > > >>> tab" feature [0]
>> > > > >>>
>> > > > >>> This feature being combined with Task-based deployment [1] and
>> > > > >>> LCM-readiness for Fuel deployment tasks [2] unlocks Basic LCM in
>> > > Fuel. We
>> > > > >>> conducted a thorough redesign of this feature and splitted it
>> > > > >>> into
>> > > several
>> > > > >>> granular changes [3]-[6] to allow users to change settings on
>> > > deployed,
>> > > > >>> partially deployed, stopped or erred 

Re: [openstack-dev] [horizon] PTL noncandidacy

[Thai Q Tran]

Thanks David for your commitment and leadership. I learned a lot from you and your perspective on things. Looking forward to learn more from you and to work along side you into the foreseeable future. You are sticking around right? I still have TONS of questions to ask, JK :P
 
- Original message -From: Anita Kuno To: openstack-dev@lists.openstack.orgCc:Subject: Re: [openstack-dev] [horizon] PTL noncandidacyDate: Fri, Mar 11, 2016 1:18 PM 
On 03/11/2016 12:19 PM, David Lyle wrote:> After five cycles as PTL of Horizon, I've decided not to run for the> Newton cycle.>> I am exceptionally proud of the things we've accomplished over this> time. I'm amazed by how much our project's community has grown and> evolved.>> Looking at the community now, I believe we have a tremendous group of> contributors for moving forward. There are several people capable of> becoming great PTLs and overall the community will be healthier with> some turnover in the PTL role. I feel honored to have had your trust> over this time and lucky to have worked with such great people.>> I will still be around and will help the next PTL make a smooth> transition where requested.>> David>> __> OpenStack Development Mailing List (not for usage questions)> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>It has been a delight and honour to work with you in your role asHorizon PTL. I look forward to continuing to work with you as HorizonnonPTL.Thanks for your many cycles of hard work and dedication to the project.I really appreciate it.Thank you,Anita.__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


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

Re: [openstack-dev] [manila] FFE for Removing the File Tree on Delete When Using Nested Shares on 3PAR

[Doug Hellmann]

Excerpts from Ben Swartzlander's message of 2016-03-11 16:10:33 -0500:
> On 03/11/2016 02:42 PM, O'Rourke, Alex Liam wrote:
> > Hi,
> >
> > I would like to request a Feature Freeze Exception for Removing the File
> > Tree on Delete When Using Nested Shares with 3PAR:
> > https://review.openstack.org/#/c/290209/
> >
> > Originally, this was filed as a blueprint and marked as a new feature
> > (https://blueprints.launchpad.net/manila/+spec/hpe3par-nested-deletion),
> > but it was reclassified as a bug fix
> > (https://bugs.launchpad.net/manila/+bug/1538800) soon after. When
> > deleting a nested share from 3PAR, the file tree is not deleted, making
> > it so the contents within the ‘deleted’ share can still be accessed.
> > This bug fix aims to solve the problem by mounting the parent share and
> > deleting the file tree of the share requested. The issue is isolated
> > only to the 3PAR driver.
> >
> > This patch adds configuration options for the username, password, and
> > domain in order to mount a CIFS share. Config options are needed in
> > order to fix this issue because without valid credentials, we cannot
> > mount a CIFS share to delete the lingering files. Because of these
> > options we are adding, the fix is to be treated as a feature over a bug.
> > I am requesting the Feature Freeze Exception so we can get this fix for
> > the 3PAR driver into Mitaka.
> 
> This is one way to handle it! Is anyone opposed? I've already found at 
> least one other "bugfix" which adds a new config option. I'll be on the 
> lookout for more of these over the next week.

Please keep in mind that there is one less week between RC1 and final
release this cycle compared to last cycle. Continuing to add new
features at this point puts your release at risk.

Doug

> 
> -Ben
> 
> > Thank You,
> >
> > Alex O’Rourke
> >
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 

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

Re: [openstack-dev] [QA] Not running for PTL

[Anita Kuno]

On 03/11/2016 02:34 PM, Matthew Treinish wrote:
> Hi everyone,
> 
> I'm writing this to announce that I am not running for QA PTL this cycle. I've
> been the QA PTL for the past 4 cycles and I think it's time for another person
> to take over the role. I think during the past 4 cycles the QA community has
> grown greatly and become a much larger and stronger community compared to 
> when 
> I first took on the position in the Juno cycle.
> 
> I strongly believe in the diversity of leadership and ideas, and I don't want
> the community to grow stagnant because it becomes synonymous with just my 
> voice.
> Being a PTL is not the same as being an autocrat and I think it's time for
> another person to step up and take over the QA PTL spot.
> 
> That being said, I'm not planning on going anywhere or leaving the project. I
> fully intend to continue working and being heavily involved with the QA 
> program,
> as I have for been the past 2 years. (although maybe with a bit more free time
> now)
> 
> -Matt Treinish
> 
> 
> 
> __
> OpenStack Development Mailing 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 for your hard work and dedication, Matt. I really appreciate it.

I'm glad you will be staying around in an unofficial capacity.

Thanks for continuing to ensure that OpenStack and testing have become
synonymous concepts, supported by a chorus of voices.

Thanks Matt,
Anita.



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] [manila] FFE for Removing the File Tree on Delete When Using Nested Shares on 3PAR

[Ben Swartzlander]

On 03/11/2016 02:42 PM, O'Rourke, Alex Liam wrote:

Hi,

I would like to request a Feature Freeze Exception for Removing the File
Tree on Delete When Using Nested Shares with 3PAR:
https://review.openstack.org/#/c/290209/

Originally, this was filed as a blueprint and marked as a new feature
(https://blueprints.launchpad.net/manila/+spec/hpe3par-nested-deletion),
but it was reclassified as a bug fix
(https://bugs.launchpad.net/manila/+bug/1538800) soon after. When
deleting a nested share from 3PAR, the file tree is not deleted, making
it so the contents within the ‘deleted’ share can still be accessed.
This bug fix aims to solve the problem by mounting the parent share and
deleting the file tree of the share requested. The issue is isolated
only to the 3PAR driver.

This patch adds configuration options for the username, password, and
domain in order to mount a CIFS share. Config options are needed in
order to fix this issue because without valid credentials, we cannot
mount a CIFS share to delete the lingering files. Because of these
options we are adding, the fix is to be treated as a feature over a bug.
I am requesting the Feature Freeze Exception so we can get this fix for
the 3PAR driver into Mitaka.


This is one way to handle it! Is anyone opposed? I've already found at 
least one other "bugfix" which adds a new config option. I'll be on the 
lookout for more of these over the next week.


-Ben



Thank You,

Alex O’Rourke



__
OpenStack Development Mailing 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] Nova PTL for Newton

[Anita Kuno]

On 03/11/2016 02:22 PM, John Garbutt wrote:
> Hi,
> 
> It has been greatly rewarding serving you all as Nova PTL over the
> Liberty and Mitaka cycles. I thank you all for the support,
> encouragement and advice I have been given over the last year. I
> really appreciate that. (That's british speak for "I love you all", or
> something like that).
> 
> I don't plan on standing for the Newton cycle. I think its a good time
> for someone to bring fresh energy, ideas, and drive to help keep Nova
> driving forward. I have enjoyed my time as PTL, as such, I would
> consider standing again. We have a good number of folks stepping up to
> lead different parts of the project. I hope we can grow that effort,
> and I hope to continue to be part of that.
> 
> I aim to continue contributing to Nova (I hope to be in Austin, and I
> hope to write some code again soon). I will certainly make time to
> ensure a smooth transition to the next PTL.
> 
> Many 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
> 
You have a kind, gentle touch as leader, John. Based on the results I
see, it seems to have served Nova well.

Thanks so much for your hard work, John. It has been to the benefit of
us all.

Thank you,
Anita.

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

Re: [openstack-dev] [horizon] PTL noncandidacy

[Anita Kuno]

On 03/11/2016 12:19 PM, David Lyle wrote:
> After five cycles as PTL of Horizon, I've decided not to run for the
> Newton cycle.
> 
> I am exceptionally proud of the things we've accomplished over this
> time. I'm amazed by how much our project's community has grown and
> evolved.
> 
> Looking at the community now, I believe we have a tremendous group of
> contributors for moving forward. There are several people capable of
> becoming great PTLs and overall the community will be healthier with
> some turnover in the PTL role. I feel honored to have had your trust
> over this time and lucky to have worked with such great people.
> 
> I will still be around and will help the next PTL make a smooth
> transition where requested.
> 
> David
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
It has been a delight and honour to work with you in your role as
Horizon PTL. I look forward to continuing to work with you as Horizon
nonPTL.

Thanks for your many cycles of hard work and dedication to the project.
I really appreciate it.

Thank you,
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] [all][oslo] config generator default overrides and namespaces

[Doug Hellmann]

rbradford found an issue in neutron today with the entry point for
declaring overrides for defaults for options coming from the cors
middleware. We then subsequently found the same problem in a bunch of
other projects, and have submitted patches to fix them [1]. krotscheck
is reviewing the pending patches to update those before the bad values
land [2].

The tl;dr is: Do not name things in your project using names coming
from other projects.

In this case, the entry points were named 'oslo.middleware.cors'
instead of '$project' and so when the config generator was run on
a system with all projects installed, all of the default override
functions were being invoked because all versions of the
oslo.middleware.cors entry point were loaded. As a result, some
incompatible code was being imported, causing an exception, and so
the sample file generation for solum failed with a traceback in
neutron code. Weird.

If you end up with one of the patches in your project, please assign it
high review priority but look at it carefully before merging to make
sure I picked a valid name.

If you are using this feature in some other way, please check the
names you're using for the entry points to ensure that they have
the application name in them somewhere, and do not refer directly
to the name of a library managed by another team or shared between
projects.

I have updated the oslo.config documentation to be more clear about
this naming restriction [3].

Doug

[1] https://review.openstack.org/#/q/topic:fix-config-default
[2] https://review.openstack.org/#/q/branch:master+topic:bug/1551836
[3] https://review.openstack.org/#/c/291904/

__
OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Vitaly Kramskikh]

We can add the warning, but I think before we do this we should have clear
migration plan. According to this thread, some parts are still not clear.

2016-03-11 22:00 GMT+03:00 Mike Scherbakov :

> Deprecation warning for Fuel Mitaka:
> https://bugs.launchpad.net/fuel/+bug/1556244.
>
>
> On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko  wrote:
>
>> Since there are a lot of supporters for this idea, what do you folks
>> think about creating a BP spec where we can describe what we should do in
>> order to remove logs from UI and Nailgun? I also propose to file a bug
>> about adding a deprecation warning to Mitaka release of Fuel.
>>
>>
>> 11 бер. 2016 р. о 16:55 Bogdan Dobrelya 
>> написав(ла):
>>
>>
>> On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
>>
>> +1 to remove logs from Fuel UI in Fuel Newton.
>> In Fuel Mitaka we'd need to put a deprecation warning somewhere.
>>
>>
>> I agree, there is not much sense having non flexible (no content
>> filters) logs view in UI. LMA plugins shall cover this area as well.
>>
>>
>>
>> On Fri, Mar 11, 2016, 04:57 Patrick Petit > >> wrote:
>>
>>
>>On 11 March 2016 at 12:51:40, Igor Kalnitsky
>>(ikalnit...@mirantis.com > >) wrote:
>>
>>Patrick,
>>
>>Sorry, but I meant another question. I thought that LMA plugin should
>>be installed in some environment before we can start use it. Is
>>this a
>>case? If so, it means we can't use for master node until some
>>environment is deployed.
>>
>>
>>Right. This is the chicken and egg problem I mentioned earlier...
>>
>>But this is not a “problem” specific to Fuel. My take on this is is
>>that ops management tooling (logging, monitoring) should be
>>installed off-band before any OpenStack deployment. In fact, in
>>real-world usage, we frequently get asks to have the monitoring and
>>logging services of StackLight installed permanently for
>>multi-enviroments. And so, one approach would be to make Stacklight
>>backend services the first bits of software installed by Fuel (if
>>not already there), then reconfigure Fuel to hook into those
>>services and only then, enter into the regular OpenStack
>>provisioning mode.
>>
>>
>>
>>On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit
>>>>
>> wrote:
>>
>>
>> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com <
>> mailto:ikalnit...@mirantis.com >)
>> wrote:
>>
>> Hey Roman,
>>
>> Thank you for bringing this up. +1 from my side, especially taking
>> into account the patch where we tried to solve logrotated logs problem
>> [1]. It's complex and unsupportable, as well as already existed
>> logview code in Nailgun.
>>
>> Patrick, Simon,
>>
>> Does LMA plugin support logs from master node? Or it's designed to
>> watch environment's logs?
>>
>> No it’s not designed specifically for environment logs. Can be adapted to
>>
>> any log format.
>>
>> Would just need to write a parser like you would with logstach when logs
>> are
>> not standard.
>>
>> Patrick
>>
>>
>>
>> Thanks,
>> Igor
>>
>>
>> [1]: https://review.openstack.org/#/c/243240/
>>
>> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit > mailto:ppe...@mirantis.com >> wrote:
>>
>> Fuelers,
>>
>> As Simon said, we already have a log centralisation solution for MOS
>> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
>> objectively, there is no need to have log management in Nailgun anymore.
>> To
>> go one step further we suggested several times to have a StackLight agent
>>
>> installed on the Fuel master node to also collect and centralise those
>> logs.
>> There is a little bit of a chicken and egg problem to resolve but I think
>>
>> it
>> is worth a try to have that nailed down in the roadmap for Fuel 10.
>> Cheers
>> - Patrick
>>
>>
>> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com <
>> mailto:spasqu...@mirantis.com >)
>> wrote:
>>
>> Hello Roman,
>>
>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko > mailto:m...@romcheg.me >>
>> wrote:
>>
>>
>> Fuelers,
>>
>> I remember we’ve discussing this topic in our couloirs before but I’d
>> like
>> to bring that discussion to a more official format.
>>
>> Let me state a few reasons to do this:
>>
>> - Log management code in Nailgun is overcomplicated
>> - Working with logs on big scale deployments is barely possible given the
>>
>> current representation
>> - Due to overcomplexity and ineffectiveness of the code we always get
>> recurring bugs like [1]. That eats tons of time to resolve.
>> - There are much better specialized tools, say Logstash [2], that can
>> 

Re: [openstack-dev] [horizon] PTL noncandidacy

[Lin Hua Cheng]

Thanks for all the great work. Your leadership and commitment to horizon
has been instrumental to the projects success.

On Fri, Mar 11, 2016 at 9:19 AM, David Lyle  wrote:

> After five cycles as PTL of Horizon, I've decided not to run for the
> Newton cycle.
>
> I am exceptionally proud of the things we've accomplished over this
> time. I'm amazed by how much our project's community has grown and
> evolved.
>
> Looking at the community now, I believe we have a tremendous group of
> contributors for moving forward. There are several people capable of
> becoming great PTLs and overall the community will be healthier with
> some turnover in the PTL role. I feel honored to have had your trust
> over this time and lucky to have worked with such great people.
>
> I will still be around and will help the next PTL make a smooth
> transition where requested.
>
> David
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Logo for TripleO

[Qasim Sarfraz]

+1

On Fri, Mar 11, 2016 at 8:25 PM, Jay Dobies  wrote:

>
>
> On 03/11/2016 12:32 AM, Jason Rist wrote:
>
>> Hey everyone -
>> We've been working on a UI for TripleO for a few months now and
>> we're
>> just about to beg to be a part of upstream... and we're in need of a
>> logo for the login page and header.
>>
>> In my evenings, I've come up with a logo.
>>
>> It's a take on the work that Dan has already done on the Owl idea:
>> http://wixagrid.com/tripleo/tripleo_svg.html
>>
>> I think it'd be cool if it were used on the CI page and maybe even
>> tripleo.org - I ran it by the guys on #tripleo and they seem to be
>> pretty warm on the idea, so I thought I'd run it by here if you missed
>> the conversation.
>>
>> It's SVG so we can change the colors pretty easily as I have in the two
>> attached screenshots.  It also doesn't need to be loaded as a separate
>> asset.  Additionally, it scales well since it's basically vector instead
>> of rasterized.
>>
>> What do you guys think?
>>
>
> Damn dude, really well done, +1 from me.
>
> Can we use it?
>>
>> I can do a patch for tripleo.org and the ci and wherever else it's in
>> use.
>>
>> -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
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

[Brant Knudson]

On Thu, Mar 10, 2016 at 10:43 AM, Brant Knudson  wrote:

>
>
> On Thu, Mar 10, 2016 at 8:10 AM, Thomas Herve  wrote:
>
>> On Thu, Mar 10, 2016 at 2:55 PM, Sean Dague  wrote:
>> > On 03/10/2016 08:40 AM, Thomas Herve wrote:
>> >> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent 
>> wrote:
>> >>> +many. It would be great if we just got rid of the runnable web
>> >>> servers in the projects and just expose wsgi apps (the tools like
>> >>> devstack etc mounted under whatever the available server is).
>> >>
>> >> Isn't devstack meant for development? Running the APIs in a WSGI
>> >> container like Apache or uwsgi makes for a terrible debugging
>> >> experience. Just this morning I had to prevent aodh from running in
>> >> Apache to be able to run it standalone.
>> >>
>> >> Also, those apps that use WSGI still bind a different port. The fact
>> >> that it runs in Apache doesn't really solve the URLs problem.
>> >
>> > But they shouldn't. I do realize it's taking a while to get there, but
>> > this is the push to get rid of all these weird ports. The point is to
>> > get them all on 80 in a subpath or a separate domain.
>> >
>> >
>> > If projects use the pbr wsgi_script directive the wsgi script will run
>> > on wsgi ref on the commandline if you need that for debug -
>> >
>> https://github.com/openstack/keystone/blob/4db54810e58ad86edb92869a608fb5630a6b99e5/setup.cfg#L75
>> > that was built to make this simpler.
>>
>> Right, but if we move to everything in WSGI besides a subpath, you
>> won't be able to switch to the script easily. Unless you actually
>> implement that using a reverse proxy.
>>
>> I totally understand the will to remove those ports from the final
>> product. I question whether it's the right choice for devstack. It
>> would seem that at least keeping those 'weird' ports for internal
>> consumption would be useful. It's not like we're close to use the 65K
>> available.
>>
>> --
>> Thomas
>>
>>
> For some time, devstack has been running with keystone accepting on both
> it's legacy ports (:5000 and :35357), and on subpaths (:80/identity and
> /identity_admin). I tried to change devstack to have keystone only
> listening on subpaths but this is failing in tempest-lib -- see the errors
> in https://review.openstack.org/#/c/193894/. At first I thought it would
> be best to get tempest-lib doing version discovery but this turned into a
> lot of code since version discovery requires quite a bit of parsing and
> searching through dicts which always requires lots of error handling and
> test code (see reviews ending at https://review.openstack.org/#/c/263452/).
> (You might wonder why I didn't use the code that's already in
> keystoneclient/keystoneauth for version discovery -- it's because tempest
> doesn't use the client libs.)
>
> Anyways I think the alternative that's going to be backwards compatible is
> to have the user be able to pass in the identity endpoints for v2 and v3
> and have tempest use those if provided. I haven't had time to propose this
> yet.
>
> My preference would be to have the keystone processes running separately
> under uwsgi or gunicorn, then httpd proxies to that from /identity and
> /identity_admin (and :5000 and :35357 for legacy). Hopefully this would be
> over a unix socket talking uwsgi protocol or whatever the process and httpd
> support. Note that devstack already has a TLS-proxy deployment option
> that's similar. I've been hoping to have time to propose the keystone
> devstack deployment use this but I'm easily distracted.
>
>
Here's the proposed change to devstack to allow keystone running under
uwsgi while apache accepts http / https (using mod_uwsgi_proxy) if you want
to take a look: https://review.openstack.org/#/c/291817/

We've got a few too many deployment options for keystone devstack now. I'd
like to get this down to just mod_wsgi and mod_uwsgi_proxy. The uwsgi
deploy we should be able to get rid of quickly, just add a non-voting job
in keystone for mod_uwsgi_proxy and get rid of the uwsgi job. We should be
able to get rid of eventlet right away in N since it's not supported to run
eventlet keystone anymore.

Next, we should be able to simplify the tls-proxy deployment since keystone
is always running in apache.

Then simplify further: Get rid of the tls-proxy option and instead have
keystone apache listen on https + http by default. Then eventually stop
listening on http and run https all the time.

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

[openstack-dev] [Neutron] Ironing out outstanding issues in time for RC1

[Armando M.]

Neutrinos,

We have about ~20 outstanding bugs marked Medium/High/Critical, and we have
only one or two days left to have a chance to get them in the gate queue
[1]. Can I trouble you to go and make sure patches are up to date and well
reviewed?

Many thanks,
Armando

[1] https://launchpad.net/neutron/+milestone/mitaka-rc1
__
OpenStack Development Mailing 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] Nova PTL for Newton

[Sean McGinnis]

On Fri, Mar 11, 2016 at 07:22:10PM +, John Garbutt wrote:
> Hi,
> 
> It has been greatly rewarding serving you all as Nova PTL over the
> Liberty and Mitaka cycles. I thank you all for the support,
> encouragement and advice I have been given over the last year. I
> really appreciate that. (That's british speak for "I love you all", or
> something like that).
> 
> I don't plan on standing for the Newton cycle. I think its a good time
> for someone to bring fresh energy, ideas, and drive to help keep Nova
> driving forward. I have enjoyed my time as PTL, as such, I would
> consider standing again. We have a good number of folks stepping up to
> lead different parts of the project. I hope we can grow that effort,
> and I hope to continue to be part of that.
> 
> I aim to continue contributing to Nova (I hope to be in Austin, and I
> hope to write some code again soon). I will certainly make time to
> ensure a smooth transition to the next PTL.
> 
> Many thanks,
> johnthetubaguy
> 

Thanks for all your work John!

Sean


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

[openstack-dev] [cross-project] Stale Specs

[Mike Perez]

Hey all,

I'm looking into cleaning up the cross-project spec reviews.

The following appear to be inactive specs and need the original author to
revive and eventually propose for wider discussions in the cross-project
meeting [1], or someone that's interested in leading the spec needs to
communicate with the current author on taking things over. Otherwise I will be
proposing to the TC to abandon these:

* Stop running testr in the environment under test (robert Collins) - 
https://review.openstack.org/#/c/218070/
* Replace eventlet + monkey-patching with ?? (Joshua Harlow) - 
https://review.openstack.org/164035
* Super Scheduling (Joshua Harlow) - https://review.openstack.org/#/c/210549/
* Backwards compat for libraries and clients. (Robert Collins) - 
https://review.openstack.org/226157
* Event message format (Thomas Therve) - https://review.openstack.org/231382
* Instance users for cloud interaction (Kevin Fox) - 
https://review.openstack.org/#/c/93/1
* DNS and SSL certificates (Kevin Fox) - 
https://review.openstack.org/#/c/228074/2
* No global admin (Adam Young) - https://review.openstack.org/#/c/205629/
* OpenStack wide error codes for log messages (Rochelle Grober) - 
https://review.openstack.org/#/c/172552/5
* Add asynchronous user event support to OpenStack (Angus Salkeld) - 
https://review.openstack.org/#/c/185822/2



This spec needs someone to take lead in the cross-project meeting:

* Instance Auto Evacuation (Timofey Durakov) - 
https://review.openstack.org/#/c/257809/2




This spec needs someone technical to fill in the gaps. Keep in mind this spec
should just cover the concept of rolling upgrades the projects should follow.
Projects can still do individual specs in their spec-repo to discuss technical
details around their specific services. The point here is to agree on the
concept and already existing solutions to solve the problem:

* Rolling Upgrades (Ken Johnston) - https://review.openstack.org/#/c/290977/1

-- 
Mike Perez

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

Re: [openstack-dev] [nova] Nova PTL for Newton

[Sylvain Bauza]

Le 11/03/2016 20:22, John Garbutt a écrit :

Hi,

It has been greatly rewarding serving you all as Nova PTL over the
Liberty and Mitaka cycles. I thank you all for the support,
encouragement and advice I have been given over the last year. I
really appreciate that. (That's british speak for "I love you all", or
something like that).

I don't plan on standing for the Newton cycle. I think its a good time
for someone to bring fresh energy, ideas, and drive to help keep Nova
driving forward. I have enjoyed my time as PTL, as such, I would
consider standing again. We have a good number of folks stepping up to
lead different parts of the project. I hope we can grow that effort,
and I hope to continue to be part of that.

I aim to continue contributing to Nova (I hope to be in Austin, and I
hope to write some code again soon). I will certainly make time to
ensure a smooth transition to the next PTL.


John, thank you so much for the dedication you made to the project and 
the leadership you had during that period.

Time for you refueling your batteries and gaining some rest, you deserve it.

-Sylvain


Many 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 Development Mailing 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] Clarifications about ThirdParty CI deadlines

[Kurt Taylor]

On Mon, Mar 7, 2016 at 1:48 PM, Thiago Paiva 
wrote:

> Hello folks,
>
> My project is in need of some clarifications about the deadlines for the
> CI deployment on [1]. If you can kindly answer these questions to help us
> consider changes on our sprint planning to address the community
> requirements, would be very very helpful:
>
> 1) In the point 2, what do we mean by "receive events"? Is is about
> reading from the event stream of Gerrit and take the appropriate actions?
> Act upon "check experimental" or "check " comments are
> considered valid to fulfill this requirement?
>

Just be able to connect to gerrit and receive events - see:
http://docs.openstack.org/infra/system-config/third_party.html#reading-the-event-stream


>
> 2) We are a little confused with the phrase "post comments in the
> sandbox". By that we mean commenting on the "openstack-infra/ci-sandbox"
> project? Do we need to keep commenting on sandbox even when we have already
> set-up the job to read events and comment results for the
> "openstack/ironic" project?
>
>
This is just a way to test your CI system without posting garbage to the
ironic project patch comments. The sandbox is a place to post comments on a
test pass and verify that it all llooks good and satisfies the
requirements. See:
http://docs.openstack.org/infra/system-config/third_party.html#testing-your-ci-setup

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

[openstack-dev] [manila] FFE for Removing the File Tree on Delete When Using Nested Shares on 3PAR

[O'Rourke, Alex Liam]

Hi,

I would like to request a Feature Freeze Exception for Removing the File Tree 
on Delete When Using Nested Shares with 3PAR: 
https://review.openstack.org/#/c/290209/

Originally, this was filed as a blueprint and marked as a new feature 
(https://blueprints.launchpad.net/manila/+spec/hpe3par-nested-deletion), but it 
was reclassified as a bug fix (https://bugs.launchpad.net/manila/+bug/1538800) 
soon after. When deleting a nested share from 3PAR, the file tree is not 
deleted, making it so the contents within the 'deleted' share can still be 
accessed. This bug fix aims to solve the problem by mounting the parent share 
and deleting the file tree of the share requested. The issue is isolated only 
to the 3PAR driver.

This patch adds configuration options for the username, password, and domain in 
order to mount a CIFS share. Config options are needed in order to fix this 
issue because without valid credentials, we cannot mount a CIFS share to delete 
the lingering files. Because of these options we are adding, the fix is to be 
treated as a feature over a bug. I am requesting the Feature Freeze Exception 
so we can get this fix for the 3PAR driver into Mitaka.


Thank You,
Alex O'Rourke

__
OpenStack Development Mailing 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] Nova PTL for Newton

[Jay Pipes]

On 03/11/2016 02:22 PM, John Garbutt wrote:

Hi,

It has been greatly rewarding serving you all as Nova PTL over the
Liberty and Mitaka cycles. I thank you all for the support,
encouragement and advice I have been given over the last year. I
really appreciate that. (That's british speak for "I love you all", or
something like that).

I don't plan on standing for the Newton cycle. I think its a good time
for someone to bring fresh energy, ideas, and drive to help keep Nova
driving forward. I have enjoyed my time as PTL, as such, I would
consider standing again. We have a good number of folks stepping up to
lead different parts of the project. I hope we can grow that effort,
and I hope to continue to be part of that.

I aim to continue contributing to Nova (I hope to be in Austin, and I
hope to write some code again soon). I will certainly make time to
ensure a smooth transition to the next PTL.


Thanks a ton for your leadership over the last cycles, John, really 
appreciated!


Best,
-jay

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

[openstack-dev] [QA] Not running for PTL

[Matthew Treinish]

Hi everyone,

I'm writing this to announce that I am not running for QA PTL this cycle. I've
been the QA PTL for the past 4 cycles and I think it's time for another person
to take over the role. I think during the past 4 cycles the QA community has
grown greatly and become a much larger and stronger community compared to when 
I first took on the position in the Juno cycle.

I strongly believe in the diversity of leadership and ideas, and I don't want
the community to grow stagnant because it becomes synonymous with just my voice.
Being a PTL is not the same as being an autocrat and I think it's time for
another person to step up and take over the QA PTL spot.

That being said, I'm not planning on going anywhere or leaving the project. I
fully intend to continue working and being heavily involved with the QA program,
as I have for been the past 2 years. (although maybe with a bit more free time
now)

-Matt Treinish


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] [heat] issue of ResourceGroup in Heat template

[Zane Bitter]

On 11/03/16 00:48, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) wrote:

Hi Zane,

Thanks for your reply.
I guess you mean that IP address of rg_a should be available AS SOON AS/AFTER  
the server of rg_a becomes CREATE_COMPLETE? As Sergey pointed out, there is a 
chance that IP address might be available when the server of rg_a becomes 
CREATE_COMPLETE. Actually, IMHO, it depends on when a server becomes ACTIVE or 
CREATE_COMPLETE. It will becomes ACTIVE or CREATE_COMPLETE when the OS is boot 
up but initiation services(such as network interface starting up) has not been 
done or when both OS itself and initialization jobs such as daemon service up 
and network interface up, IP assigned.


Servers don't assign IP addresses to themselves. Neutron assigns one 
when it creates a (virtual) port for the server to attach to. We should 
be able to see what this IP address is long before the server has 
booted, and anything exposed as an attribute of a resource MUST be 
available by the time the resource becomes CREATE_COMPLETE otherwise 
Heat's whole data flow model is broken.



Regards,
Gary

-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com]
Sent: Thursday, March 10, 2016 5:40 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

On 09/03/16 05:42, Sergey Kraynev wrote:

Hi Gary,


First of all you don't need to use "depends_on", because using
"get_attr" already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I
suppose it happens due to:
   - you create in rg_a some Server and probably it goes to active
state before ip address becomes available for get_attr. It is
necessary to check, but if it's try to add wait condition for this
resource, then you will get created rg_a with fully available
resources and I suppose IP will be available.


I would have expected the IP address to be available before the server becomes 
CREATE_COMPLETE. If it isn't then I'd consider that a bug too - as you pointed 
out, people are relying on the dependency created by get_attr to ensure that 
they can actually get the attribute.

cheers,
Zane.


On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
 wrote:

Hi,



I have 3 Heat templates using ResourceGroup. There are 2 resource
groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires
the IP address of rg_a as the paremeter of rg_b. I use "rg_a_public_ip: 
{get_attr:
[rg_a, rg_a_public_ip]}" to get the IP address of rg_a both in the
section of rg_b parameters (rg_b/properties/resource_def/properties)
and the section of outputs.

As per my observation,  rg_a_public_ip shows "null" in the parameter
section of rg_b. while rg_a_public_ip shows the correct IP address in
the outputs section of the yaml file.



My questions are:

1)  Does this behavior is expected as designed or this is a bug?

2)  What is the alternative solution for the above case(user want to get
the run-time information of the instance when creating the second
resource
group)  if this behavior is expected?



--- a.yaml ---

resources:

rg_a:

type: OS::Heat::ResourceGroup

properties:

count: 1

resource_def:

type: b.yaml

properties:

 ...



rg_b:

type: OS::Heat::ResourceGroup

depends_on:

  -rg_a

properties:

  count: 2

  resource_def:

  type: c.yaml

  properties:

  rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
  the value is "null"

  ...



outputs:

 rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
-  the value is correct.

--



--b.yaml  

...

resources:

  rg_a:

type: OS::Nova::Server

properties:

   ...

outputs:

   rg_a_public_ip:

   value: {get_attr: [rg_a, networks, public, 0]}

--



-- c.yaml 

parameters:

rg_a_public_ip:

   type: string

   description: IP of rg_a

...

resources:

rg_b:

  type: OS::Nova::Server

  properties:

   ...

  outputs:

   ...

---



Regards,

Gary




_
_ OpenStack Development Mailing 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] [release] PTL Candidacy

[Doug Hellmann]

I am announcing my candidacy for PTL for the Release Management team
for the Newton release cycle.

My goal for the release team during Mitaka was to automate more of the
work with a review process that allows projects to be self-service,
with some lightweight oversight to manage release timing, version
numbers, and messaging. We made excellent progress on that work,
standardizing the implementation of release tagging so that release
managers only have to type a few easy commands to process a
release. We dropped our use of Launchpad milestones in favor of the
new http://releases.openstack.org site, which provides a new central
place to learn about all of the components of a release. We have
standardized most teams on one of two release models, clearly
communicating to contributors and consumers of the projects what sorts
of releases are expected and how the release schedule affects the
project. We also rolled out reno for managing release notes, and have
already started seeing success with projects communicating upgrade
impact, deprecations, and new features early and clearly.

My goals for the Newton cycle are to finish the release automation by
working with the Infrastructure team so that approving a release
request in gerrit triggers the release and there are no more manual
steps. I also propose, when that work is complete, to expand the
release automation's use beyond managed projects to be used by default
for all official projects. Finally, I plan to implement translations
for release notes, an important feature we had for past releases but
that did not make it into this release.

Doug

Official self-nomination: https://review.openstack.org/#/c/291778

__
OpenStack Development Mailing 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] Nova PTL for Newton

[John Garbutt]

Hi,

It has been greatly rewarding serving you all as Nova PTL over the
Liberty and Mitaka cycles. I thank you all for the support,
encouragement and advice I have been given over the last year. I
really appreciate that. (That's british speak for "I love you all", or
something like that).

I don't plan on standing for the Newton cycle. I think its a good time
for someone to bring fresh energy, ideas, and drive to help keep Nova
driving forward. I have enjoyed my time as PTL, as such, I would
consider standing again. We have a good number of folks stepping up to
lead different parts of the project. I hope we can grow that effort,
and I hope to continue to be part of that.

I aim to continue contributing to Nova (I hope to be in Austin, and I
hope to write some code again soon). I will certainly make time to
ensure a smooth transition to the next PTL.

Many 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] [release][ptl] updating releases.openstack.org with release notes

[Doug Hellmann]

I have started adding links to our published release notes in the
deliverables files in the releases repository [1]. We still have a
few projects who haven't merged the patch to add the series-specific
page to their release notes, so I left those out, for now.

If you do not see your project in [1] and you have a stable/mitaka
branch *and* you have release notes for it, please submit a patch
to add the 'release-notes' key to your deliverable file under
deliverables/mitaka.

Doug

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

__
OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Mike Scherbakov]

Deprecation warning for Fuel Mitaka:
https://bugs.launchpad.net/fuel/+bug/1556244.

On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko  wrote:

> Since there are a lot of supporters for this idea, what do you folks think
> about creating a BP spec where we can describe what we should do in order
> to remove logs from UI and Nailgun? I also propose to file a bug about
> adding a deprecation warning to Mitaka release of Fuel.
>
>
> 11 бер. 2016 р. о 16:55 Bogdan Dobrelya 
> написав(ла):
>
>
> On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
>
> +1 to remove logs from Fuel UI in Fuel Newton.
> In Fuel Mitaka we'd need to put a deprecation warning somewhere.
>
>
> I agree, there is not much sense having non flexible (no content
> filters) logs view in UI. LMA plugins shall cover this area as well.
>
>
>
> On Fri, Mar 11, 2016, 04:57 Patrick Petit  >> wrote:
>
>
>On 11 March 2016 at 12:51:40, Igor Kalnitsky
>(ikalnit...@mirantis.com  >) wrote:
>
>Patrick,
>
>Sorry, but I meant another question. I thought that LMA plugin should
>be installed in some environment before we can start use it. Is
>this a
>case? If so, it means we can't use for master node until some
>environment is deployed.
>
>
>Right. This is the chicken and egg problem I mentioned earlier...
>
>But this is not a “problem” specific to Fuel. My take on this is is
>that ops management tooling (logging, monitoring) should be
>installed off-band before any OpenStack deployment. In fact, in
>real-world usage, we frequently get asks to have the monitoring and
>logging services of StackLight installed permanently for
>multi-enviroments. And so, one approach would be to make Stacklight
>backend services the first bits of software installed by Fuel (if
>not already there), then reconfigure Fuel to hook into those
>services and only then, enter into the regular OpenStack
>provisioning mode.
>
>
>
>On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit
>>>
> wrote:
>
>
> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com <
> mailto:ikalnit...@mirantis.com >)
> wrote:
>
> Hey Roman,
>
> Thank you for bringing this up. +1 from my side, especially taking
> into account the patch where we tried to solve logrotated logs problem
> [1]. It's complex and unsupportable, as well as already existed
> logview code in Nailgun.
>
> Patrick, Simon,
>
> Does LMA plugin support logs from master node? Or it's designed to
> watch environment's logs?
>
> No it’s not designed specifically for environment logs. Can be adapted to
> any log format.
>
> Would just need to write a parser like you would with logstach when logs
> are
> not standard.
>
> Patrick
>
>
>
> Thanks,
> Igor
>
>
> [1]: https://review.openstack.org/#/c/243240/
>
> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit  mailto:ppe...@mirantis.com >> wrote:
>
> Fuelers,
>
> As Simon said, we already have a log centralisation solution for MOS
> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
> objectively, there is no need to have log management in Nailgun anymore.
> To
> go one step further we suggested several times to have a StackLight agent
> installed on the Fuel master node to also collect and centralise those
> logs.
> There is a little bit of a chicken and egg problem to resolve but I think
> it
> is worth a try to have that nailed down in the roadmap for Fuel 10.
> Cheers
> - Patrick
>
>
> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com <
> mailto:spasqu...@mirantis.com >)
> wrote:
>
> Hello Roman,
>
> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko  mailto:m...@romcheg.me >>
> wrote:
>
>
> Fuelers,
>
> I remember we’ve discussing this topic in our couloirs before but I’d
> like
> to bring that discussion to a more official format.
>
> Let me state a few reasons to do this:
>
> - Log management code in Nailgun is overcomplicated
> - Working with logs on big scale deployments is barely possible given the
> current representation
> - Due to overcomplexity and ineffectiveness of the code we always get
> recurring bugs like [1]. That eats tons of time to resolve.
> - There are much better specialized tools, say Logstash [2], that can
> deal
> with logs much more effectively.
>
>
> There may be more reasons bus I think even the already mentioned ones are
> enough to think about the following proposal:
>
> - Remove Logs tab from Fuel Web UI
> - Remove logs support from Nailgun
> - Create mechanism that allows to configure different log management
> software, say Logstash, Loggly, etc
>
> - Choose a default 

[openstack-dev] [gnocchi] strange behavior

[Mike Lowe]

I’m having a little trouble with my gnocchi install, the only output from the 
status command is ‘storage’ and even with verbose and debugging true the api 
log doesn’t show anything after startup.  Any hints?


__
OpenStack Development Mailing 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] Proposal to add Diana Whitten tohorizon-core

[Akihiro Motoki]

+1 from me too!

2016-03-11 17:38 GMT+09:00 Tatiana Ovtchinnikova :
> +1. Thanks for your contribution!
>
>
>
> 2016-03-11 6:40 GMT+03:00 Zhenguo Niu :
>>
>> +1 from me, thanks for all the hard work!
>>
>> On Thu, Mar 10, 2016 at 3:27 AM, Michael Krotscheck 
>> wrote:
>>>
>>> +1. Another vote in favor of ditching django altogether is good by me :)
>>>
>>> On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran  wrote:

 Big +1 from me, thanks for all the hard work Diana!


 - Original message -
 From: David Lyle 
 To: OpenStack Development Mailing List
 
 Cc:
 Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
 horizon-core
 Date: Tue, Mar 8, 2016 2:07 PM

 I propose adding Diana Whitten[1] to horizon-core.

 Diana is an active reviewer, contributor and community member. Over
 the past couple of releases, Diana has driven extensive changes around
 theme-ability in Horizon and drastically increased the standardization
 of our use of bootstrap. During this time, Diana has also provided
 valuable reviews to keep us on the straight and narrow preventing our
 continued abuse of defenseless web technologies.

 Please respond with comments, +1s, or objections by Friday.

 Thanks,
 David

 [1]
 http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all


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

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

[openstack-dev] [release][documentation] fairy-slipper 0.2.0 release

[no-reply]

We are satisfied to announce the release of:

fairy-slipper 0.2.0: A project to make OpenStack API's self
documententing.

With source available at:

https://git.openstack.org/cgit/openstack/fairy-slipper

Please report issues through launchpad:

https://bugs.launchpad.net/openstack-doc-tools

For more details, please see below.

0.2.0
^

Changes in fairy-slipper 0.1.0..0.2.0
-

fa666c0 Adds release notes for added migration features
a364fc3 Update method names with x- prefix
6b45654 Handle other status codes
d57fa58 Fix request example field
271e8c4 Fix venv path
469e5b6 Update the launchpad bug link in CONTRIBUTING.rst
de0b437 Updates to swagger_to_rst template

Diffstat (except docs and test files)
-

CONTRIBUTING.rst   |   2 +-
fairy_slipper/cmd/swagger_to_rst.py| 116 +--
fairy_slipper/cmd/wadl_to_swagger_valid.py | 125 ++-
migrate.sh |  13 +-
.../notes/more-error-migrations-6b45654a.yaml  |   4 +
.../notes/update-method-names-a364fc3b.yaml|   5 +
tools/with_venv.sh |   2 +-
8 files changed, 1052 insertions(+), 88 deletions(-)




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

[openstack-dev] [Cinder] PTL Candidacy

[Sean McGinnis]

Hey everyone,

Wow, how six months flies! I'd like to announce my candidacy to continue on as
Cinder PTL for the Newton release cycle.

A lot has been accomplished in the Mitaka cycle. After a lot of work by many
folks, over a couple development cycles, we now have what we consider a "tech
preview" of rolling upgrades. It just hasn't had enough runtime and testing for
us to say it's "official". We will likely need to fix a few minor things in the
Newton timeframe before it's fully baked and reliable. But it has come a long
way and I'm really happy with the progress that has been made.

Another priority we had identified for Mitaka was active/active high
availability of the c-vol service. We were not able to complete that work, but
many pieces have been put in place to support that in Newton. We fixed several
API races and added the ability to use something like tooz for locking. These
are foundation pieces for us to be able to start breaking out things and
running in a reliable active/active configuration.

Microversion support has been added and there is now a new v3 API endpoint.
This was a bit of a controversy as we really had just started to get folks to
move off of v1 to v2. To be safe though I decided it would protect end users
better to have a clearly separate new API endpoint for the microversion
compatibility. And now hopefully it is our last.

Replication was another slightly controversial feature implemented. Late in
Liberty we finally agreed on a spec for a v2 version of replication. The v2
spec was approved so late that no one actually had time to implement it for
that release. As we started to implement it for Mitaka we found that a lot of
compromises had crept in during the spec review that it had the risk of being
too complex and having some of the issues we were trying to get rid of by
moving away from replication v1. At our midcycle we had a lot of discussion on
replication and finally decided to change course before it was too late.
Whether that ends up being the best choice when we look back a year from now or
not, I'm proud of the team that we were willing to put on the brakes and make
changes - even though it was more work for us - before we released something
out to end users that would have caused problems or a poor experience.

Other than that, there's mostly been a lot of good bug fixes. Eight new drivers
have been added from (I think) five different vendors. The os-brick library is
now 1.0 (actually 1.1.0) and is in use by both Cinder and Nova for common
storage management operations so there is not a duplication and disconnect of
code between the two projects. We were also able to add a Brick cinder client
extension to be able to perform storage management on nodes without Nova (bare
metal, etc.).

None of this goodness was from me.

We have a bunch of smart and active members of the Cinder community. They are
the ones that are making a difference, working across the community, and
making sure Cinder is a solid component in an OpenStack cloud.

Being part of the Cinder community has been one of the best and most engaging
parts of my career. I am lucky enough to have support from my company to be
able to devote time to being a part of this. I would love the opportunity to
continue as PTL to not just contribute where I can, but to make sure the folks
doing the heavy lifting have the support and project organization they need to
avoid distractions and be able to focus on getting the important stuff done.

I think in Newton we need to continue the momentum and get Active/Active Cinder
volume service support implemented. We need to continue to work closely with
the Nova team to make sure our interaction is correct and solid. But also work
to make Cinder a useful storage management interface in environments without
Nova. I will continue to encourage developer involvement and vendor support.
We need to improve the user experience with better error reporting when things
go wrong. And last, but definitely not least, we need to continue to expand our
testing - unit, functional, and tempest - to make sure we can avoid those
errors and deliver a high quality and solid solution.

I really feel I'm just getting into the swing of things. I would love the
opportunity to serve as PTL for the Newton release.

Thank you for your consideration.

Sean McGinnis (smcginnis)


__
OpenStack Development Mailing 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] OpenStack Developer Mailing List Digest March 5-11

[Mike Perez]

HTML Render: 
http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160311/

SuccessBot Says
===
* Ajaeger: All jobs moved from bare-trusty to ubuntu-trusty.
* Clarkb: Infra is running logstash 2.0 now 
* Tell us yours via IRC with a message “#success [insert success]”.
* All [1].


Cross-Project
=
* API guidelines ready for review:
  - Header non proliferation [1]
  - Client interaction guideline for microversions [2]


Election Season, PTL and TC
===
* PTL elections:
  - Important dates:
+ Nominations open: 2016-03-11 00:00 UTC
+ Nominations close: 2016-03-17 23:59 UTC
+ Election open: 2016-03-18 00:00 UTC
+ Election close: 2016-03-24 23:59 UTC
  - Every project team must elect a PTL every 6 months.
  - More info and how to submit your candidacy [3].
* TC elections:
  - Important dates:
+ Nominations open: 2016-03-25 00:00 UTC
+ Nominations close: 2016-03-31 23:59 UTC
+ Election open: 2016-04-01 00:00 UTC
+ Election close: 2016-04-07 23:59 UTC
  - Under the rules of the TC charter [4] we renew 7 TC seats. Seats are valid
for one year.
  - More info and how to submit your candidacy [5].
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088558.html


The stable:follows-policy Tag Is Official, Projects Need To Start Applying For 
It
=
* This is official in the governance documents [6].
* Projects that follow the stable branch policy [7] should start applying.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088592.html


Release Countdown For Week R-3, March 14-18
===
* Focus:
  - Projects teams following cycle-with-milestone model:
+ Preparing their first Mitaka release candidate this week.
+ This should be tagged using (X.Y.Z.0rc1) as soon as the pressure to
  unfreeze master is stronger than the cost of backporting bugfixes.
+ The release team will create stable branches from the release candidate
  tag points.
  - Project teams following the cycle-with-intermediary model
+ Ensure you have at least one mitaka release.
+ Determine if you need another release before the end of the Mitaka cycle.
  - All feature freeze exceptions that haven't landed at this point should wait
until Newton.
* General Notes:
  - The global requirements list is frozen. If you need to change a dependency,
for a bug fix, please provide enough detail in the change request to allow
the requirements review team to evaluate the change.
  - User-facing strings are frozen to allow the translation team time to finish
their work.
* Release Actions:
  - The release team has started creating the stable/mitaka branches for
libraries.
  - Follow-up on the mailing list thread [8] to acknowledge and approve the
version number to use to create the branch.
+ This only includes projects with release:managed tag.
+ Other projects can post on the thread of request their own branches.
* Important Dates:
  - RC target week: R-1, March 28 – April 1
  - Mitaka final release: April 4-8
  - Mitaka release schedule [9].
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/089001.html


Reminder: WSME Is Not Being Actively Maintained
===
* Chris Dent and Lucas Gomes have been actively verifying bug fixes and keeping
  things going with WSME, but are no longer interested or have the time to
  continue. It was also found it never really reached a state where any of the
  following are true:
  - The WSME code is easy to understand and maintain.
  - WSME provides correct handling of HTTP (notably response status and
headers).
  - WSME has an architecture that is suitable for creating modern Python-based
web applications.
* There's a suggestion for the 24 different OpenStack projects that are using
  it to move to something else.
* One big reason for choosing WSME earlier was that it had support for both XML
  and JSON without application code needing to do anything explicitly.
  - The community has decided to stop providing XML API support and some other
tools have been used instead to provide parsing and validation features
similar to WSME:
+ JSONSchema
+ Voluptuous
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#88658



[1] - https://review.openstack.org/#/c/280381/
[2] - https://review.openstack.org/#/c/243414/
[3] - https://wiki.openstack.org/wiki/PTL_Elections_March_2016
[4] - http://governance.openstack.org/reference/charter.html
[5] - https://wiki.openstack.org/wiki/TC_Elections_April_2016
[6] - 
http://governance.openstack.org/reference/tags/stable_follows-policy.html#tag-application-process
[7] - http://docs.openstack.org/project-team-guide/stable-branches.html
[8] - http

Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

[Alexey Shtokolov]

Hi Dmitry,

We've reached the design consensus with Igor today. Could you please remove
the conditional status of the FFE request?
As agreed: the merge deadline is March 24.

--
WBR, Alexey Shtokolov

2016-03-11 2:27 GMT+03:00 Dmitry Borodaenko :

> Granted. Design consensus deadline for the task history part of this
> feature is extended to March 11. This does not change the merge deadline
> for other parts of this feature, which is still March 24.
>
> --
> Dmitry Borodaenko
>
>
> On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
> > Dmitry,
> >
> > We are really close to have the consensus, but we need one more meeting
> > with Fuel-Python Component Lead Igor Kalnitsky to make the final
> decision.
> > All patches [0] are on review. The meeting is scheduled for tomorrow
> (03/11
> > 1:30pm CET).
> > Could you please grant us one more day for it?
> >
> > [0] -
> > https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
> >
> > --
> > WBR, Alexey Shtokolov
> >
> > 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko :
> >
> > > Granted, merge deadline March 24, task history part of the feature is
> to
> > > be excluded from this exception grant unless a consensus is reached by
> > > March 10.
> > >
> > > Relevant part of the meeting log starts at:
> > >
> > >
> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
> > >
> > > --
> > > Dmitry Borodaenko
> > >
> > >
> > > On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh wrote:
> > > > Oh, so there is a spec. I was worried that this patch has
> > > > "WIP-no-bprint-assigned-yet" string in the commit message, so I
> thought
> > > > there is no spec for it. So the commit message should be updated to
> avoid
> > > > such confusion.
> > > >
> > > > It's really good I've seen this spec. There are plans to overhaul UI
> data
> > > > format description which we use for cluster and node settings to
> solve
> > > some
> > > > issues and implement long-awaited features like nested structures,
> so we
> > > > might also want to deprecate our expression language and also switch
> to
> > > > YAQL (and thus port YAQL to JS).
> > > >
> > > > 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin :
> > > >
> > > > > Vitaly
> > > > >
> > > > > Thanks for bringing this up. Actually the spec has been on review
> for
> > > > > almost 2 weeks: https://review.openstack.org/#/c/282695/.
> Essentially,
> > > > > this is not introducing new DSL but replacing the existing one with
> > > more
> > > > > powerful extendable language which is being actively developed
> within
> > > > > OpenStack and is already a part of other projects (Murano,
> Mistral),
> > > which
> > > > > has much more contributors, can return not only boolean but any
> > > arbitrary
> > > > > collections. So it means that we want to deprecate current
> Expression
> > > > > language that you wrote and replace it with YAQL due to those
> reasons.
> > > You
> > > > > are not going to extend this Expression-based language in 3 weeks
> up to
> > > > > level of support of extensions, method overloading, return of
> arbitrary
> > > > > collections (e.g. we also want to calculate cross-depends and
> requires
> > > > > fields on the fly which require for it to return list of dicts) and
> > > support
> > > > > of this stuff on your own, are you?
> > > > >
> > > > > On Wed, Mar 2, 2016 at 10:09 AM, Vitaly Kramskikh <
> > > vkramsk...@mirantis.com
> > > > > > wrote:
> > > > >
> > > > >> I think it's not a part of best practices to introduce changes
> like
> > > > >> https://review.openstack.org/#/c/279714/ (adding yet another DSL
> to
> > > the
> > > > >> project) without a blueprint and review and discussion of the
> spec.
> > > > >>
> > > > >> 2016-03-02 2:19 GMT+07:00 Alexey Shtokolov <
> ashtoko...@mirantis.com>:
> > > > >>
> > > > >>> Fuelers,
> > > > >>>
> > > > >>> I would like to request a feature freeze exception for "Unlock
> > > settings
> > > > >>> tab" feature [0]
> > > > >>>
> > > > >>> This feature being combined with Task-based deployment [1] and
> > > > >>> LCM-readiness for Fuel deployment tasks [2] unlocks Basic LCM in
> > > Fuel. We
> > > > >>> conducted a thorough redesign of this feature and splitted it
> into
> > > several
> > > > >>> granular changes [3]-[6] to allow users to change settings on
> > > deployed,
> > > > >>> partially deployed, stopped or erred clusters and further run
> > > redeployment
> > > > >>> using a particular graph (custom or calculated based on expected
> > > changes
> > > > >>> stored in DB) and with new parameters.
> > > > >>>
> > > > >>> We need 3 weeks after FF to finish this feature.
> > > > >>> Risk of not delivering it after 3 weeks is low.
> > > > >>>
> > > > >>> Patches on review or in progress:
> > > > >>> 
> > > > >>> https://review.openstack.org/#/c/284139/
> > > > >>> 

[openstack-dev] [nova] stuck review, mtu incorrectly set on vhost-user port prevents vm booting.

[Mooney, Sean K]

Hi everyone
I opened a bug back in January to correct an issue with vhost-user
Related to  setting the mtu on the interface.

The recent changes in nova and neutron to change the default mtu value from 0 
to 1500
Are a direct trigger for this bug resulting in an inability to boot vms that 
use vhost-user.

If anyone on the nova core/stable teams has time to look at this  bug and the 
fix I would appreciated it.

I would really like get this merged before rc1 is tagged if possible.
We have been running it in our ci for two weeks to make our cis work but I want
To get them back to running against the head of master nova as soon as possible.

Bug : https://bugs.launchpad.net/nova/+bug/1533876
Review: https://review.openstack.org/#/c/271444/

Liberty backport: https://review.openstack.org/#/c/289370/1
Kilo backport: https://review.openstack.org/#/c/289374/1

Regards
Seán

__
OpenStack Development Mailing 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] CI non-voting jobs

[Dmitry Borodaenko]

Emilien,

Thanks for bringing this up!

On Fri, Mar 11, 2016 at 08:00:14AM -0500, Emilien Macchi wrote:
> We just broke TripleO CI for a bug we introduced in puppet-nova, so I
> thought a reminder would be useful for our group.
> 
> * If Jenkins gives +1 to a patch but some non-voting jobs do not pass,
> please look why or at least ask on #puppet-openstack if it's "normal".
> * If TripleO or Fuel CI jobs are red, and you have no idea how to debug
> them, no problem. Come on IRC and ask some help.
> * If you aren't sure about why TripleO & Fuel CI are red and you're about
> to +A a patch, please come on IRC and ask guidance.

You can find out more about Fuel CI on wiki:
https://wiki.openstack.org/wiki/Fuel/CI#CI_for_Puppet_OpenStack

And if you notice a failed Fuel CI test on your commit, please come to
#fuel-dev, we want to investigate all such failures:
https://wiki.openstack.org/wiki/Fuel/CI/Puppet_OpenStack_CI_duty

We're still working on setting up everything for this (e.g. Fuel CI
doesn't vote yet so we can't setup a gerrit dashboard described on that
page), but we do want to catch potential regressions so we will help.

-- 
Dmitry Borodaenko

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

[openstack-dev] [trove] Trove Newton summit planning

[Amrith Kumar]

Please propose sessions that you would like to include at the design summit in 
Austin.

I will fill in the items that were agreed to at the mid-cycle over the next 
couple of days.

An etherpad is available for this at: 
https://etherpad.openstack.org/p/trove-newton-proposed-sessions

-amrith
__
OpenStack Development Mailing 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] [diskimage-builder] Bypass loopback size limits

[Yolanda Robla Mota]

Hi
I have a problem working with diskimage-builder, when trying to create 
images larger than allowed.


I need to create a dib image, with the following partition (sfdisk format):

2048 4869952 L *
 4872000 + L;
 0 0;
 0 0;

This has been working in the past, but suddenly the config of the VMs i 
was using look different, and i'm getting this error:


Warning: given size (4869952) exceeds max allowable size (3170816)
Warning: The partition table looks like it was made
  for C/H/S=*/69/21 (instead of 197/255/63).
For this listing I'll assume that geometry.
start: (c,h,s) expected (1,28,12) found (0,32,33)
end: (c,h,s) expected (1023,68,21) found (303,68,21)
Warning: partition 2 has size 0 but is not marked Empty
Warning: partition 1 extends past end of disk


Anyone knows how can i bypass that limit on loop device? I tried 
creating an image file with dd, then attaching with losetup (losetup 
/dev/loopxx image-file.img) , but then diskimage-builder complains about 
the filesytem being in use. Anyone has hit that on the pass and knows 
any workaround?


Thanks

--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hpe.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] [Group-based-policy] do we have any usage doc about service function chaining feature?

[Anthony Chow]

I find this URL very useful for Group Based Policy:

https://wiki.openstack.org/wiki/GroupBasedPolicy

https://wiki.openstack.org/wiki/GroupBasedPolicy

Also GitHub usually has good description on how to install.

Hope this is useful, have a nice weekend,

anthony.



On Fri, Mar 11, 2016 at 12:58 AM, gong_ys2004 
wrote:

> Hi,
> I failed to find any usage doc about GBP project's SFC feature.
> Could any one please help to point me to the location?
>
> Thanks
> yong sheng gong
>
> __
> OpenStack Development Mailing 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] [Congress] PTL candidacy

[Tim Hinrichs]

Hi all,

I'm writing to announce my continued candidacy for Congress PTL.

In the Mitaka cycle we've been working hard and making great progress on a
number of things.  The largest change is a new distributed architecture
built on top of oslo-messaging.  That architecture is key to enabling us to
meet the high-availability and high throughput demands that we've heard
from the field.  We also saw the first new mechanism since the project's
inception for injecting data into Congress, so that external systems can
push data, instead of Congress pulling it.  In Mitaka, we also completed
the transition to Python3, and implemented the plugin interface for both
tempest and devstack.  It's also exciting that over the last two cycles, we
have seen longer-term commitments to Congress from the community, with 1
new core reviewer this cycle, and two other incredibly active contributors.

In Newton, my primary technical goal is to complete the migration to our
new distributed architecture.  I also hope to have Congress leverage that
new architecture to provide high-availability and high-throughput
solutions.  I plan to continue discussions with other projects to
understand how and where Congress can be useful. Finally, I'm looking
forward to stengthening the developer community around Congress.

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

[openstack-dev] [horizon] PTL noncandidacy

[David Lyle]

After five cycles as PTL of Horizon, I've decided not to run for the
Newton cycle.

I am exceptionally proud of the things we've accomplished over this
time. I'm amazed by how much our project's community has grown and
evolved.

Looking at the community now, I believe we have a tremendous group of
contributors for moving forward. There are several people capable of
becoming great PTLs and overall the community will be healthier with
some turnover in the PTL role. I feel honored to have had your trust
over this time and lucky to have worked with such great people.

I will still be around and will help the next PTL make a smooth
transition where requested.

David

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

Re: [openstack-dev] [telemetry] stepping down as PTL

[Doug Hellmann]

Excerpts from gordon chung's message of 2016-03-11 16:32:41 +:
> hi folks,
> 
> as the PTL nominations are open, i just want to note that i won't be 
> running again as the Telemetry PTL for Newton cycle.
> 
> i've thoroughly enjoyed my time as PTL which afforded me the opportunity 
> to work with and learn from some great individuals who share the same 
> passion to collaborate openly. i have the utmost confidence that the 
> projects will continue to grow and become more refined under the next 
> leadership.
> 
> personal thanks to everyone in Aodh, Ceilometer and Gnocchi communities 
> as well as the projects that provided valuable feedback by collaborating 
> with us. i thank you for sharing in the decision making so i could 
> spread the blame around. i also thank you for reading through terribly 
> written messages that make you question whether the shift keys on all my 
> keyboards are broken.
> 
> cheers,
> 

Thanks for a smooth release cycle, Gordon!

Doug

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

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Roman Prykhodchenko]

Since there are a lot of supporters for this idea, what do you folks think 
about creating a BP spec where we can describe what we should do in order to 
remove logs from UI and Nailgun? I also propose to file a bug about adding a 
deprecation warning to Mitaka release of Fuel.


> 11 бер. 2016 р. о 16:55 Bogdan Dobrelya  написав(ла):
> 
> On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
>> +1 to remove logs from Fuel UI in Fuel Newton.
>> In Fuel Mitaka we'd need to put a deprecation warning somewhere.
> 
> I agree, there is not much sense having non flexible (no content
> filters) logs view in UI. LMA plugins shall cover this area as well.
> 
>> 
>> 
>> On Fri, Mar 11, 2016, 04:57 Patrick Petit > 
>> >> wrote:
>> 
>> 
>>On 11 March 2016 at 12:51:40, Igor Kalnitsky
>>(ikalnit...@mirantis.com  
>> >) wrote:
>> 
>>>Patrick,
>>> 
>>>Sorry, but I meant another question. I thought that LMA plugin should
>>>be installed in some environment before we can start use it. Is
>>>this a
>>>case? If so, it means we can't use for master node until some
>>>environment is deployed.
>> 
>>Right. This is the chicken and egg problem I mentioned earlier...
>> 
>>But this is not a “problem” specific to Fuel. My take on this is is
>>that ops management tooling (logging, monitoring) should be
>>installed off-band before any OpenStack deployment. In fact, in
>>real-world usage, we frequently get asks to have the monitoring and
>>logging services of StackLight installed permanently for
>>multi-enviroments. And so, one approach would be to make Stacklight
>>backend services the first bits of software installed by Fuel (if
>>not already there), then reconfigure Fuel to hook into those
>>services and only then, enter into the regular OpenStack
>>provisioning mode.
>> 
>>> 
>>> 
>>>On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit
>>> 
>>> >> wrote:
 
 On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com 
  >)
 wrote:
 
 Hey Roman,
 
 Thank you for bringing this up. +1 from my side, especially taking
 into account the patch where we tried to solve logrotated logs problem
 [1]. It's complex and unsupportable, as well as already existed
 logview code in Nailgun.
 
 Patrick, Simon,
 
 Does LMA plugin support logs from master node? Or it's designed to
 watch environment's logs?
 
 No it’s not designed specifically for environment logs. Can be adapted to
 any log format.
 
 Would just need to write a parser like you would with logstach when logs 
 are
 not standard.
 
 Patrick
 
 
 
 Thanks,
 Igor
 
 
 [1]: https://review.openstack.org/#/c/243240/ 
 
 
 On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit  >> wrote:
> Fuelers,
> 
> As Simon said, we already have a log centralisation solution for MOS
> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
> objectively, there is no need to have log management in Nailgun anymore.
> To
> go one step further we suggested several times to have a StackLight agent
> installed on the Fuel master node to also collect and centralise those
> logs.
> There is a little bit of a chicken and egg problem to resolve but I think
> it
> is worth a try to have that nailed down in the roadmap for Fuel 10.
> Cheers
> - Patrick
> 
> 
> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com 
>   >)
> wrote:
> 
> Hello Roman,
> 
> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko    >>
> wrote:
>> 
>> Fuelers,
>> 
>> I remember we’ve discussing this topic in our couloirs before but I’d
>> like
>> to bring that discussion to a more official format.
>> 
>> Let me state a few reasons to do this:
>> 
>> - Log management code in Nailgun is overcomplicated
>> - Working with logs on big scale deployments is barely possible given the
>> current representation
>> - Due to overcomplexity and ineffectiveness of the code we always get

Re: [openstack-dev] [telemetry] stepping down as PTL

[Jason Myers]

You will be greatly missed! Thank you for showing me the ropes, and working
so hard to improve telemetry!

Cheers,
Jason

On Friday, March 11, 2016, gordon chung  wrote:

> hi folks,
>
> as the PTL nominations are open, i just want to note that i won't be
> running again as the Telemetry PTL for Newton cycle.
>
> i've thoroughly enjoyed my time as PTL which afforded me the opportunity
> to work with and learn from some great individuals who share the same
> passion to collaborate openly. i have the utmost confidence that the
> projects will continue to grow and become more refined under the next
> leadership.
>
> personal thanks to everyone in Aodh, Ceilometer and Gnocchi communities
> as well as the projects that provided valuable feedback by collaborating
> with us. i thank you for sharing in the decision making so i could
> spread the blame around. i also thank you for reading through terribly
> written messages that make you question whether the shift keys on all my
> keyboards are broken.
>
> 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
>
__
OpenStack Development Mailing 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] Clarifications about ThirdParty CI deadlines

[Sam Betts (sambetts)]

I'll try to answer your questions as best I can. As I understand it, "receive 
events" means that you can listen to the gerrit stream and take an action when 
for example a new patch is uploaded or a recheck comment is left etc. Initially 
we encourage people to get their CI listening to the ci-sandbox project for 
testing and making sure comments are pushed correctly etc, but once testing is 
complete and your happy to start receiving events from openstack/ironic you can 
switch over to that, there isn't a requirement to keep posting in the sandbox.


Sam

From: Thiago Paiva >
Reply-To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)" 
>
Date: Monday, 7 March 2016 19:48
To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)" 
>
Subject: [openstack-dev] [Ironic] Clarifications about ThirdParty CI deadlines

Hello folks,

My project is in need of some clarifications about the deadlines for the CI 
deployment on [1]. If you can kindly answer these questions to help us consider 
changes on our sprint planning to address the community requirements, would be 
very very helpful:

1) In the point 2, what do we mean by "receive events"? Is is about reading 
from the event stream of Gerrit and take the appropriate actions? Act upon 
"check experimental" or "check " comments are considered valid to 
fulfill this requirement?

2) We are a little confused with the phrase "post comments in the sandbox". By 
that we mean commenting on the "openstack-infra/ci-sandbox" project? Do we need 
to keep commenting on sandbox even when we have already set-up the job to read 
events and comment results for the "openstack/ironic" project?


Thank you,


[1] https://wiki.openstack.org/wiki/Ironic/Testing#Third_Party_CI_Requirements

Thiago Paiva Brito
Lead Software Engineer
OneView Drivers for Openstack Ironic
__
OpenStack Development Mailing 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] Branch miss-match between server and client in Kilo

[Janki Chhatbar]

Hi Adrian

Greetings for the day! Thank you for replying. I would be glad to have you
help me out in this. Below are some of the points that I have noticed.


   1. > I think we can address this by creating a branch for the client
   that aligns with kilo.

There are  version specific branches for client. Devstack is to be
configured to point to the client's kilo branches.

To elaborate:
The *stackrc* file for Devstack Kilo (
https://github.com/openstack-dev/devstack/blob/stable/kilo/stackrc)
specifies the master branch for all client components and kilo branch for
server components.

# ceilometer client library
> GITREPO["python-ceilometerclient"]=${CEILOMETERCLIENT_REPO:-${GIT_BASE}/
> openstack/python-ceilometerclient.git}

GITBRANCH["python-ceilometerclient"]=${CEILOMETERCLIENT_BRANCH:-master} <-
> change to be done is replace "master" with "stable/kilo" for all the
> services.


For projects like Tacker and Magnum, it is to be done at
https://github.com/openstack/tacker/blob/stable/kilo/devstack/lib/tacker

# Set up default directories

> GITREPO["python-tackerclient"]=${TACKERCLIENT_REPO:-${GIT_BASE}/stackforge
> /python-tackerclient.git} <- change the URL to /openstack/
> python-tackerclient.git}
>
> GITBRANCH["python-tackerclient"]=${TACKERCLIENT_BRANCH:master} <- change
> to be done is replace "master" with "stable/kilo" for all the services.
>
> GITREPO["tacker-horizon"]=${TACKERHORIZON_REPO:-${GIT_BASE}/stackforge/
> python-tackerclient.git} <- change the URL to /openstack/
> python-tackerclient.git}



> GITBRANCH["tacker-horizon"]=${TACKERHORZION_BRANCH:-master} <- change to
> be done is replace "master" with "stable/kilo"
>

2. Kilo doesnot support "doc8" tests. (This is what I have noticed while
getting a Tacker patch (https://bugs.launchpad.net/tacker/+bug/1555130)
reviewed (https://review.openstack.org/#/c/290674/). I am not sure how to
proceed in such scenario.


Any guidance will be appreciated.

Thanking you

Janki Chhatbar
OpenStack | SDN | Docker
(+91) 9409239106
simplyexplainedblog.wordpress.com

On Fri, Mar 11, 2016 at 1:51 AM, Adrian Otto 
wrote:

> Hi there Janki. Thanks for catching that. I think we can address this by
> creating a branch for the client that aligns with kilo. I’ve triaged the
> magnum bug on this, and I’m willing to help drive it to resolution
> together.
>
> Regards,
>
> Adrian
>
> On Mar 9, 2016, at 8:16 PM, Janki Chhatbar 
> wrote:
>
> Hi All
>
> Greetings for the day!
>
> I have noticed that while installing* OpenStack Kilo* using DevStack, the
> server components cloned are stable/kilo whereas the client components
> cloned are master. This leads to errors in installation or commands
> miss-match. For eg.
>
> *In tacker,*
> tacker git repo is stable/kilo which points to incorrect git repo URL. I
> have filled a  bug and proposed a patch for this (
> https://bugs.launchpad.net/tacker/+bug/1555130)
>
> *In Magnum*,
> *magnum stable/kilo* clones *python-magnumclient master* which leads to
> command mismatch (https://bugs.launchpad.net/magnum/+bug/1509273).
>
>
>1. Does this affect all other services?
>2. Does this mean that the branch needs to be changed for all the
>service's clients? The change will be in /devstack/lib/{service} file in
>"GITBRANCH" variable.
>
>  If changes are required, I am willing to work on those.
>
> Thanking you
>
> Janki Chhatbar
> OpenStack | SDN | Docker
> (+91) 9409239106
> simplyexplainedblog.wordpress.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [telemetry] stepping down as PTL

[gordon chung]

hi folks,

as the PTL nominations are open, i just want to note that i won't be 
running again as the Telemetry PTL for Newton cycle.

i've thoroughly enjoyed my time as PTL which afforded me the opportunity 
to work with and learn from some great individuals who share the same 
passion to collaborate openly. i have the utmost confidence that the 
projects will continue to grow and become more refined under the next 
leadership.

personal thanks to everyone in Aodh, Ceilometer and Gnocchi communities 
as well as the projects that provided valuable feedback by collaborating 
with us. i thank you for sharing in the decision making so i could 
spread the blame around. i also thank you for reading through terribly 
written messages that make you question whether the shift keys on all my 
keyboards are broken.

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] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Bogdan Dobrelya]

On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
> +1 to remove logs from Fuel UI in Fuel Newton.
> In Fuel Mitaka we'd need to put a deprecation warning somewhere.

I agree, there is not much sense having non flexible (no content
filters) logs view in UI. LMA plugins shall cover this area as well.

> 
> 
> On Fri, Mar 11, 2016, 04:57 Patrick Petit  > wrote:
> 
> 
> On 11 March 2016 at 12:51:40, Igor Kalnitsky
> (ikalnit...@mirantis.com ) wrote:
> 
>> Patrick, 
>>
>> Sorry, but I meant another question. I thought that LMA plugin should 
>> be installed in some environment before we can start use it. Is
>> this a 
>> case? If so, it means we can't use for master node until some 
>> environment is deployed. 
> 
> Right. This is the chicken and egg problem I mentioned earlier...
> 
> But this is not a “problem” specific to Fuel. My take on this is is
> that ops management tooling (logging, monitoring) should be
> installed off-band before any OpenStack deployment. In fact, in
> real-world usage, we frequently get asks to have the monitoring and
> logging services of StackLight installed permanently for
> multi-enviroments. And so, one approach would be to make Stacklight
> backend services the first bits of software installed by Fuel (if
> not already there), then reconfigure Fuel to hook into those
> services and only then, enter into the regular OpenStack
> provisioning mode.
> 
>>
>>
>> On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit
>> > wrote: 
>> > 
>> > On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com 
>> ) 
>> > wrote: 
>> > 
>> > Hey Roman, 
>> > 
>> > Thank you for bringing this up. +1 from my side, especially taking 
>> > into account the patch where we tried to solve logrotated logs problem 
>> > [1]. It's complex and unsupportable, as well as already existed 
>> > logview code in Nailgun. 
>> > 
>> > Patrick, Simon, 
>> > 
>> > Does LMA plugin support logs from master node? Or it's designed to 
>> > watch environment's logs? 
>> > 
>> > No it’s not designed specifically for environment logs. Can be adapted 
>> to 
>> > any log format. 
>> > 
>> > Would just need to write a parser like you would with logstach when 
>> logs are 
>> > not standard. 
>> > 
>> > Patrick 
>> > 
>> > 
>> > 
>> > Thanks, 
>> > Igor 
>> > 
>> > 
>> > [1]: https://review.openstack.org/#/c/243240/ 
>> > 
>> > On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit > > wrote: 
>> >> Fuelers, 
>> >> 
>> >> As Simon said, we already have a log centralisation solution for MOS 
>> >> delivered as a Fuel plugins known as StackLight / LMA toolset. And so 
>> >> objectively, there is no need to have log management in Nailgun 
>> anymore. 
>> >> To 
>> >> go one step further we suggested several times to have a StackLight 
>> agent 
>> >> installed on the Fuel master node to also collect and centralise 
>> those 
>> >> logs. 
>> >> There is a little bit of a chicken and egg problem to resolve but I 
>> think 
>> >> it 
>> >> is worth a try to have that nailed down in the roadmap for Fuel 10. 
>> >> Cheers 
>> >> - Patrick 
>> >> 
>> >> 
>> >> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com 
>> ) 
>> >> wrote: 
>> >> 
>> >> Hello Roman, 
>> >> 
>> >> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko > > 
>> >> wrote: 
>> >>> 
>> >>> Fuelers, 
>> >>> 
>> >>> I remember we’ve discussing this topic in our couloirs before but 
>> I’d 
>> >>> like 
>> >>> to bring that discussion to a more official format. 
>> >>> 
>> >>> Let me state a few reasons to do this: 
>> >>> 
>> >>> - Log management code in Nailgun is overcomplicated 
>> >>> - Working with logs on big scale deployments is barely possible 
>> given the 
>> >>> current representation 
>> >>> - Due to overcomplexity and ineffectiveness of the code we always 
>> get 
>> >>> recurring bugs like [1]. That eats tons of time to resolve. 
>> >>> - There are much better specialized tools, say Logstash [2], that 
>> can 
>> >>> deal 
>> >>> with logs much more effectively. 
>> >>> 
>> >>> 
>> >>> There may be more reasons bus I think even the already mentioned 
>> ones are 
>> >>> enough to think about the following proposal: 
>> >>> 
>> >>> - Remove Logs tab from Fuel Web UI 
>> >>> - Remove logs support from Nailgun 
>> >>> - Create mechanism that allows to configure 

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Mike Scherbakov]

+1 to remove logs from Fuel UI in Fuel Newton.
In Fuel Mitaka we'd need to put a deprecation warning somewhere.

On Fri, Mar 11, 2016, 04:57 Patrick Petit  wrote:

>
> On 11 March 2016 at 12:51:40, Igor Kalnitsky (ikalnit...@mirantis.com)
> wrote:
>
> Patrick,
>
> Sorry, but I meant another question. I thought that LMA plugin should
> be installed in some environment before we can start use it. Is this a
> case? If so, it means we can't use for master node until some
> environment is deployed.
>
> Right. This is the chicken and egg problem I mentioned earlier...
>
> But this is not a “problem” specific to Fuel. My take on this is is that
> ops management tooling (logging, monitoring) should be installed off-band
> before any OpenStack deployment. In fact, in real-world usage, we
> frequently get asks to have the monitoring and logging services of
> StackLight installed permanently for multi-enviroments. And so, one
> approach would be to make Stacklight backend services the first bits of
> software installed by Fuel (if not already there), then reconfigure Fuel to
> hook into those services and only then, enter into the regular OpenStack
> provisioning mode.
>
>
>
> On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit 
> wrote:
> >
> > On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com)
> > wrote:
> >
> > Hey Roman,
> >
> > Thank you for bringing this up. +1 from my side, especially taking
> > into account the patch where we tried to solve logrotated logs problem
> > [1]. It's complex and unsupportable, as well as already existed
> > logview code in Nailgun.
> >
> > Patrick, Simon,
> >
> > Does LMA plugin support logs from master node? Or it's designed to
> > watch environment's logs?
> >
> > No it’s not designed specifically for environment logs. Can be adapted to
>
> > any log format.
> >
> > Would just need to write a parser like you would with logstach when logs
> are
> > not standard.
> >
> > Patrick
> >
> >
> >
> > Thanks,
> > Igor
> >
> >
> > [1]: https://review.openstack.org/#/c/243240/
> >
> > On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit 
> wrote:
> >> Fuelers,
> >>
> >> As Simon said, we already have a log centralisation solution for MOS
> >> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
> >> objectively, there is no need to have log management in Nailgun anymore.
>
> >> To
> >> go one step further we suggested several times to have a StackLight
> agent
> >> installed on the Fuel master node to also collect and centralise those
> >> logs.
> >> There is a little bit of a chicken and egg problem to resolve but I
> think
> >> it
> >> is worth a try to have that nailed down in the roadmap for Fuel 10.
> >> Cheers
> >> - Patrick
> >>
> >>
> >> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com)
> >> wrote:
> >>
> >> Hello Roman,
> >>
> >> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko 
> >> wrote:
> >>>
> >>> Fuelers,
> >>>
> >>> I remember we’ve discussing this topic in our couloirs before but I’d
> >>> like
> >>> to bring that discussion to a more official format.
> >>>
> >>> Let me state a few reasons to do this:
> >>>
> >>> - Log management code in Nailgun is overcomplicated
> >>> - Working with logs on big scale deployments is barely possible given
> the
> >>> current representation
> >>> - Due to overcomplexity and ineffectiveness of the code we always get
> >>> recurring bugs like [1]. That eats tons of time to resolve.
> >>> - There are much better specialized tools, say Logstash [2], that can
> >>> deal
> >>> with logs much more effectively.
> >>>
> >>>
> >>> There may be more reasons bus I think even the already mentioned ones
> are
> >>> enough to think about the following proposal:
> >>>
> >>> - Remove Logs tab from Fuel Web UI
> >>> - Remove logs support from Nailgun
> >>> - Create mechanism that allows to configure different log management
> >>> software, say Logstash, Loggly, etc
> >>>
> >>> - Choose a default software to install and provide a plugin for it from
>
> >>> the box
> >>
> >>
> >> This is what the LMA/StackLight plugins [1][2] are meant for. No need to
>
> >> develop anything new.
> >>
> >> And I'm +1 with the removal of log management from Fuel. As you said, it
>
> >> can't scale...
> >>
> >> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
> >> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/
> >>
> >>
> >>>
> >>>
> >>>
> >>> References
> >>> 1. https://bugs.launchpad.net/fuel/+bug/1553170
> >>> 2. https://www.elastic.co/products/logstash
> >>>
> >>>
> >>> - 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
> >>>
> >>

Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained

[Hongbin Lu]

I think we'd better to have a clear guidance here.

For projects that are currently using WSME, should they have a plan to migrate 
to other tools? If yes, is there any suggestion for the replacement tools? I 
think it will be more clear to have an official guideline in this matter.

Best regards,
Hongbin

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: March-08-16 10:51 AM
To: openstack-dev
Subject: Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively 
maintained

Excerpts from Chris Dent's message of 2016-03-08 11:25:48 +:
> 
> Last summer Lucas Gomes and I were press ganged into becoming core on 
> WSME. Since then we've piecemeal been verifying bug fixes and 
> generally trying to keep things moving. However, from the beginning we 
> both agreed that WSME is _not_ a web framework that we should be 
> encouraging. Though it looks like it started with very good 
> intentions, it never really reached a state where any of the following are 
> true:
> 
> * The WSME code is easy to understand and maintain.
> * WSME provides correct handling of HTTP (notably response status
>and headers).
> * WSME has an architecture that is suitable for creating modern
>Python-based web applications.
> 
> Last summer we naively suggested that projects that are using it move 
> to using something else. That suggestion did not take into account the 
> realities of OpenStack.
> 
> So we need to come up with a new plan. Lucas and I can continue to 
> merge bug fixes as people provide them (and we become aware of them) 
> and we can continue to hassle Doug Hellman to make a release when one 
> is necessary but this does little to address the three gaps above nor 
> the continued use of the framework in existing projects.
> 
> Ideas?

One big reason for choosing WSME early on was that it had support for both XML 
and JSON APIs without the application code needing to do anything explicitly. 
In the time since projects started using WSME, the community has decided to 
stop providing XML API support and some other tools have been picked up 
(JSONSchema, Voluptuous,
etc.) that provide parsing and validation features similar to WSME.
It seems natural that we build new APIs using those tools instead of WSME. For 
existing functioning API endpoints, we can leave them alone (using WSME) or 
change them one at a time as they are extended with new features. I don't see 
any reason to rewrite anything just to change tools.

Doug

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

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

Re: [openstack-dev] [tripleo] Logo for TripleO

[Jay Dobies]

On 03/11/2016 12:32 AM, Jason Rist wrote:

Hey everyone -
We've been working on a UI for TripleO for a few months now and we're
just about to beg to be a part of upstream... and we're in need of a
logo for the login page and header.

In my evenings, I've come up with a logo.

It's a take on the work that Dan has already done on the Owl idea:
http://wixagrid.com/tripleo/tripleo_svg.html

I think it'd be cool if it were used on the CI page and maybe even
tripleo.org - I ran it by the guys on #tripleo and they seem to be
pretty warm on the idea, so I thought I'd run it by here if you missed
the conversation.

It's SVG so we can change the colors pretty easily as I have in the two
attached screenshots.  It also doesn't need to be loaded as a separate
asset.  Additionally, it scales well since it's basically vector instead
of rasterized.

What do you guys think?


Damn dude, really well done, +1 from me.


Can we use it?

I can do a patch for tripleo.org and the ci and wherever else it's in use.

-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



__
OpenStack Development Mailing 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] Compatibility of fuel plugins and fuel versions

[Patrick Petit]

On 11 March 2016 at 15:45:57, Simon Pasquier (spasqu...@mirantis.com) wrote:
Thanks for kicking off the discussion!

On Thu, Mar 10, 2016 at 8:30 AM, Mike Scherbakov  
wrote:
Hi folks,
in order to make a decision whether we need to support example plugins, and if 
actually need them [1], I'd suggest to discuss more common things about plugins.

My thoughts:
1) This is not good, that our plugins created for Fuel 8 won't even install on 
Fuel 9. By default, we should assume that plugin will work at newer version of 
Fuel. However, for proper user experience, I suggest to create meta-field 
"validated_against", where plugin dev would provide versions of Fuel this 
plugin has been tested with. Let's say, it was tested against 7.0, 8.0. If user 
installs plugin in Fuel 9, I'd suggest to show a warning saying about risks and 
the fact that the plugin has not been tested against 9. We should not restrict 
intsallation against 9, though.

From a plugin developer's standpoint, this point doesn't worry me too much. 
It's fairly easy to hack the metadata.yaml file for supporting a newer release 
of Fuel and I suspect that some users already do this.
And I think that it is good that plugin developers explicitly advertise which 
Fuel versions the plugin supports.
That being said, I get the need to have something more automatic for CI and QA 
purposes. What about having some kind of flag/option (in the Nailgun API?) that 
would allow the installation of a plugin even if it is marked as not compatible 
with the current release?

 

2) We need to keep backward compatibility of pluggable interface for a few 
releases. So that plugin developer can use pluggable interface of version x, 
which was supported in Fuel 6.1. If we still support it, it would mean (see 
next point) compatibility of this plugin with 6.1, 7.0, 8.0, 9.0. If we want to 
deprecate pluggable interface version, we should announce it, and basically 
follow standard process of deprecation.


+1 and more.
From my past experience, this is a major issue that complicates the plugin 
maintenance. I understand that it is sometimes necessary to make breaking 
changes but at least it should be advertised in advance and to a wide audience. 
Not all plugin developers monitor the Fuel reviews to track these changes...
 

3) Plugin's ability to work against multiple releases of Fuel (multi-release 
support). If if..else clauses to support multiple releases are fairly minimal, 
let's say take less that 10% of LOC, I'd suggest to have this supported. Just 
because it will be easier for plugin devs to support their plugin code (no code 
duplication, single repo for multiple releases).

From my experience (and assuming that framework compatibility isn't broken), 
this is usually what happens. You need a few if clauses to deal with the 
differences between releases N and N+1 but this is manageable.
+1

Probably one of the most single important thing to have to be able to upgrade a 
deployed environment with a new plugin version!


 

Thoughts?

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
--
Mike Scherbakov
#mihgen

__
OpenStack Development Mailing 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] Compatibility of fuel plugins and fuel versions

[Simon Pasquier]

Thanks for kicking off the discussion!

On Thu, Mar 10, 2016 at 8:30 AM, Mike Scherbakov 
wrote:

> Hi folks,
> in order to make a decision whether we need to support example plugins,
> and if actually need them [1], I'd suggest to discuss more common things
> about plugins.
>
> My thoughts:
> 1) This is not good, that our plugins created for Fuel 8 won't even
> install on Fuel 9. By default, we should assume that plugin will work at
> newer version of Fuel. However, for proper user experience, I suggest to
> create meta-field "validated_against", where plugin dev would provide
> versions of Fuel this plugin has been tested with. Let's say, it was tested
> against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest to show a
> warning saying about risks and the fact that the plugin has not been tested
> against 9. We should not restrict intsallation against 9, though.
>

>From a plugin developer's standpoint, this point doesn't worry me too much.
It's fairly easy to hack the metadata.yaml file for supporting a newer
release of Fuel and I suspect that some users already do this.
And I think that it is good that plugin developers explicitly advertise
which Fuel versions the plugin supports.
That being said, I get the need to have something more automatic for CI and
QA purposes. What about having some kind of flag/option (in the Nailgun
API?) that would allow the installation of a plugin even if it is marked as
not compatible with the current release?



>
> 2) We need to keep backward compatibility of pluggable interface for a few
> releases. So that plugin developer can use pluggable interface of version
> x, which was supported in Fuel 6.1. If we still support it, it would mean
> (see next point) compatibility of this plugin with 6.1, 7.0, 8.0, 9.0. If
> we want to deprecate pluggable interface version, we should announce it,
> and basically follow standard process of deprecation.
>

+1 and more.
>From my past experience, this is a major issue that complicates the plugin
maintenance. I understand that it is sometimes necessary to make breaking
changes but at least it should be advertised in advance and to a wide
audience. Not all plugin developers monitor the Fuel reviews to track these
changes...


>
> 3) Plugin's ability to work against multiple releases of Fuel
> (multi-release support). If if..else clauses to support multiple releases
> are fairly minimal, let's say take less that 10% of LOC, I'd suggest to
> have this supported. Just because it will be easier for plugin devs to
> support their plugin code (no code duplication, single repo for multiple
> releases).
>

>From my experience (and assuming that framework compatibility isn't
broken), this is usually what happens. You need a few if clauses to deal
with the differences between releases N and N+1 but this is manageable.


>
> Thoughts?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
> --
> Mike Scherbakov
> #mihgen
>
> __
> OpenStack Development Mailing 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] Logo for TripleO

[Florian Fuchs]

- Original Message -
> From: "Jason Rist" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Friday, March 11, 2016 6:32:45 AM
> Subject: [openstack-dev] [tripleo] Logo for TripleO
> 
> Hey everyone -
>   We've been working on a UI for TripleO for a few months now and we're
> just about to beg to be a part of upstream... and we're in need of a
> logo for the login page and header.
> 
> In my evenings, I've come up with a logo.
> 
> It's a take on the work that Dan has already done on the Owl idea:
> http://wixagrid.com/tripleo/tripleo_svg.html
> 
> I think it'd be cool if it were used on the CI page and maybe even
> tripleo.org - I ran it by the guys on #tripleo and they seem to be
> pretty warm on the idea, so I thought I'd run it by here if you missed
> the conversation.
> 
> It's SVG so we can change the colors pretty easily as I have in the two
> attached screenshots.  It also doesn't need to be loaded as a separate
> asset.  Additionally, it scales well since it's basically vector instead
> of rasterized.
> 
> What do you guys think?
> 
> Can we use it?

+1. Definitely.


__
OpenStack Development Mailing 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] Logo for TripleO

[Liz Blanchard]

On Fri, Mar 11, 2016 at 12:32 AM, Jason Rist  wrote:

> Hey everyone -
> We've been working on a UI for TripleO for a few months now and
> we're
> just about to beg to be a part of upstream... and we're in need of a
> logo for the login page and header.
>
> In my evenings, I've come up with a logo.
>
> It's a take on the work that Dan has already done on the Owl idea:
> http://wixagrid.com/tripleo/tripleo_svg.html
>
> I think it'd be cool if it were used on the CI page and maybe even
> tripleo.org - I ran it by the guys on #tripleo and they seem to be
> pretty warm on the idea, so I thought I'd run it by here if you missed
> the conversation.
>
> It's SVG so we can change the colors pretty easily as I have in the two
> attached screenshots.  It also doesn't need to be loaded as a separate
> asset.  Additionally, it scales well since it's basically vector instead
> of rasterized.
>
> What do you guys think?
>

Looks awesome!


>
> Can we use it?
>

I hope so :)


>
> I can do a patch for tripleo.org and the ci and wherever else it's in use.
>
> -J
>
> --
> Jason E. Rist
> Senior Software Engineer
> OpenStack Infrastructure Integration
> Red Hat, Inc.
> openuc: +1.972.707.6408
> mobile: +1.720.256.3933
> Freenode: jrist
> github/twitter: knowncitizen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

[Sergey Kraynev]

Hi Gary,

I have tried your template and it works for me correctly. Note, that I
used private network (because my servers have not any public IP in
template).

So your issue looks like a strange bug, because I can not reproduce it.
Could you share traceback if your error and also provide information
about Heat version. Please create new bug with all this data and ping
us to review it.

On 11 March 2016 at 08:25, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
 wrote:
> Hi Sergey,
>
> Thanks for your reply.
>
> Thanks for your pointing out that "depends_on" is not needed when we have 
> already used "get_attr".

So as Zane pointed, when we use get_attr it's expected, that we start
create rg_b, when rg_a will be finally completed/created , because all
information (in your case it's attributes) will be available after
creation of rg_a.

In heat we have two types of dependencies explicit and implicit. So
implicit dependencies will be created with using some Heat intrinsic
functions. Depends_on add explicit dependency. All these dependencies
work in the same way, depended resource will be created, when all his
dependencies be resolved (created).

>
>>you create in rg_a some Server and probably it goes to active state before ip 
>>address becomes available for get_attr. It is necessary to check, but if it's 
>>try to add wait condition for this resource, then you will get created rg_a 
>>with fully available resources and I suppose IP will be available
>
> Do you mean that with "depends_on" functionalities, Heat will launch another 
> resource group(in my case, "rg_b") as soon as the server in "rg_a" becomes 
> "active" state?
> Actually, in my real program code, there is  a wait condition, but it is 
> located in the server template, not Resource group(in my case, it is 
> "b.yaml), which is like:
> --
> rg_a_wc_notify:
> type: OS::Heat::SoftwareConfig
> properties:
>   group: ungrouped
>   config:
> str_replace:
>   template: |
> #!/bin/bash -v
> wc_notify --data-binary '{"status": "SUCCESS"}'
>   params:
> wc_notify: {get_attr: [master_wait_handle, curl_cli]}
> --
> Is it the wait condition which you mentioned in " but if it's try to add wait 
> condition for this resource"? or you want this wait condition to be added to 
> "a.yaml"(the template declaring resource group)?
>
> And as per my observation, only after Heat receives the signal of "SUCCESS", 
> then it try to begin launch "rg_b"(my another server in another resource 
> group).
>
> I am wondering whether there is a chance that, the "IP" information is 
> available but Heat doesn't try to get it until the creation of the 2 resource 
> groups(rg_a and rg_b) is completed?



>
> Regards,
> Gary
>
> -Original Message-
> From: Sergey Kraynev [mailto:skray...@mirantis.com]
> Sent: Wednesday, March 09, 2016 6:42 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template
>
> Hi Gary,
>
>
> First of all you don't need to use "depends_on", because using "get_attr" 
> already create implicit dependency from rg_a.
> About getting Null instead of real Ip address:
> It sounds like a bug, but IMO, it's expected behavior, because I suppose it 
> happens due to:
>  - you create in rg_a some Server and probably it goes to active state before 
> ip address becomes available for get_attr. It is necessary to check, but if 
> it's try to add wait condition for this resource, then you will get created 
> rg_a with fully available resources and I suppose IP will be available.
>
> On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
>  wrote:
>> Hi,
>>
>>
>>
>> I have 3 Heat templates using ResourceGroup. There are 2 resource
>> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires the
>> IP address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip: 
>> {get_attr:
>> [rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the
>> section of rg_b parameters (rg_b/properties/resource_def/properties)
>> and the section of outputs.
>>
>> As per my observation,  rg_a_public_ip shows “null” in the parameter
>> section of rg_b. while rg_a_public_ip shows the correct IP address in
>> the outputs section of the yaml file.
>>
>>
>>
>> My questions are:
>>
>> 1)  Does this behavior is expected as designed or this is a bug?
>>
>> 2)  What is the alternative solution for the above case(user want to get
>> the run-time information of the instance when creating the second
>> resource
>> group)  if this behavior is expected?
>>
>>
>>
>> --- a.yaml ---
>>
>> resources:
>>
>> rg_a:
>>
>>   type: OS::Heat::ResourceGroup
>>
>>   properties:
>>
>>   count: 1
>>
>>   resource_def:
>>
>>   type: b.yaml
>>
>>   properties:
>>
>>…
>>
>>
>>
>> rg_b:

Re: [openstack-dev] [tripleo] Logo for TripleO

[Russell Bryant]

On Fri, Mar 11, 2016 at 4:15 AM, Dmitry Tantsur  wrote:

> On 03/11/2016 06:32 AM, Jason Rist wrote:
>
>> Hey everyone -
>> We've been working on a UI for TripleO for a few months now and
>> we're
>> just about to beg to be a part of upstream... and we're in need of a
>> logo for the login page and header.
>>
>> In my evenings, I've come up with a logo.
>>
>> It's a take on the work that Dan has already done on the Owl idea:
>> http://wixagrid.com/tripleo/tripleo_svg.html
>>
>
> This is looking fantastic!! Big +1 to using it everywhere.
>

​I love it.  :-)​



> We also need to put somewhere both this Owl and ironic's Bear together :)
>

​Don't forget Oslo's moose.

https://github.com/openstack/oslo-incubator/tree/master/doc/source/_images​


​--
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

Re: [openstack-dev] [tripleo] Logo for TripleO

[Dan Prince]

On Thu, 2016-03-10 at 22:32 -0700, Jason Rist wrote:
> Hey everyone -
>   We've been working on a UI for TripleO for a few months now and
> we're
> just about to beg to be a part of upstream... and we're in need of a
> logo for the login page and header.
> 
> In my evenings, I've come up with a logo.
> 
> It's a take on the work that Dan has already done on the Owl idea:
> http://wixagrid.com/tripleo/tripleo_svg.html
> 
> I think it'd be cool if it were used on the CI page and maybe even
> tripleo.org - I ran it by the guys on #tripleo and they seem to be
> pretty warm on the idea, so I thought I'd run it by here if you
> missed
> the conversation.
> 
> It's SVG so we can change the colors pretty easily as I have in the
> two
> attached screenshots.  It also doesn't need to be loaded as a
> separate
> asset.  Additionally, it scales well since it's basically vector
> instead
> of rasterized.
> 
> What do you guys think?
> 
> Can we use it?

+1 from me.

Dan

> 
> I can do a patch for tripleo.org and the ci and wherever else it's in
> use.
> 
> -J
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] Stable* wiki updates

[Brant Knudson]

Since there's no gerrit, I'll leave my comment here: +1 Thanks!

On Fri, Mar 11, 2016 at 1:54 AM, Alan Pevec  wrote:

> Hi stable-maints,
>
> FYI I've updated https://wiki.openstack.org/wiki/StableBranch and
> https://wiki.openstack.org/wiki/StableBranchRelease now that all
> policy and team information has ben included in the Project Team
> Guide. Please review in case I missed something!
>
> Cheers,
> Alan
>
> __
> OpenStack Development Mailing 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] Logo for TripleO

[Dougal Matthews]

On 11 March 2016 at 05:32, Jason Rist  wrote:

> Hey everyone -
> We've been working on a UI for TripleO for a few months now and
> we're
> just about to beg to be a part of upstream... and we're in need of a
> logo for the login page and header.
>
> In my evenings, I've come up with a logo.
>
> It's a take on the work that Dan has already done on the Owl idea:
> http://wixagrid.com/tripleo/tripleo_svg.html
>
> I think it'd be cool if it were used on the CI page and maybe even
> tripleo.org - I ran it by the guys on #tripleo and they seem to be
> pretty warm on the idea, so I thought I'd run it by here if you missed
> the conversation.
>
> It's SVG so we can change the colors pretty easily as I have in the two
> attached screenshots.  It also doesn't need to be loaded as a separate
> asset.  Additionally, it scales well since it's basically vector instead
> of rasterized.
>
> What do you guys think?
>

+1, great job!


Can we use it?
>

Can we? yup. We must use it!


I can do a patch for tripleo.org and the ci and wherever else it's in use.
>
> -J
>
> --
> Jason E. Rist
> Senior Software Engineer
> OpenStack Infrastructure Integration
> Red Hat, Inc.
> openuc: +1.972.707.6408
> mobile: +1.720.256.3933
> Freenode: jrist
> github/twitter: knowncitizen
>
> __
> OpenStack Development Mailing 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] [puppet] CI non-voting jobs

[Emilien Macchi]

Hi,

We just broke TripleO CI for a bug we introduced in puppet-nova, so I
thought a reminder would be useful for our group.

* If Jenkins gives +1 to a patch but some non-voting jobs do not pass,
please look why or at least ask on #puppet-openstack if it's "normal".
* If TripleO or Fuel CI jobs are red, and you have no idea how to debug
them, no problem. Come on IRC and ask some help.
* If you aren't sure about why TripleO & Fuel CI are red and you're about
to +A a patch, please come on IRC and ask guidance.

An example with https://review.openstack.org/#/c/291665/ where TripleO CI
did not pass on https://review.openstack.org/#/c/290534/ because a new
parameter was created while it already existed in another class...
Our CI did not catch it (it will thanks to
https://review.openstack.org/291703 ) while TripleO CI did, so it might be
useful to look at it.

Any question or feedback is highly welcome,
Thanks,
-- 
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

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Patrick Petit]

On 11 March 2016 at 12:51:40, Igor Kalnitsky (ikalnit...@mirantis.com) wrote:

Patrick, 

Sorry, but I meant another question. I thought that LMA plugin should 
be installed in some environment before we can start use it. Is this a 
case? If so, it means we can't use for master node until some 
environment is deployed. 
Right. This is the chicken and egg problem I mentioned earlier...

But this is not a “problem” specific to Fuel. My take on this is is that ops 
management tooling (logging, monitoring) should be installed off-band before 
any OpenStack deployment. In fact, in real-world usage, we frequently get asks 
to have the monitoring and logging services of StackLight installed permanently 
for multi-enviroments. And so, one approach would be to make Stacklight backend 
services the first bits of software installed by Fuel (if not already there), 
then reconfigure Fuel to hook into those services and only then, enter into the 
regular OpenStack provisioning mode.



On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit  wrote: 
> 
> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com) 
> wrote: 
> 
> Hey Roman, 
> 
> Thank you for bringing this up. +1 from my side, especially taking 
> into account the patch where we tried to solve logrotated logs problem 
> [1]. It's complex and unsupportable, as well as already existed 
> logview code in Nailgun. 
> 
> Patrick, Simon, 
> 
> Does LMA plugin support logs from master node? Or it's designed to 
> watch environment's logs? 
> 
> No it’s not designed specifically for environment logs. Can be adapted to 
> any log format. 
> 
> Would just need to write a parser like you would with logstach when logs are 
> not standard. 
> 
> Patrick 
> 
> 
> 
> Thanks, 
> Igor 
> 
> 
> [1]: https://review.openstack.org/#/c/243240/ 
> 
> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit  wrote: 
>> Fuelers, 
>> 
>> As Simon said, we already have a log centralisation solution for MOS 
>> delivered as a Fuel plugins known as StackLight / LMA toolset. And so 
>> objectively, there is no need to have log management in Nailgun anymore. 
>> To 
>> go one step further we suggested several times to have a StackLight agent 
>> installed on the Fuel master node to also collect and centralise those 
>> logs. 
>> There is a little bit of a chicken and egg problem to resolve but I think 
>> it 
>> is worth a try to have that nailed down in the roadmap for Fuel 10. 
>> Cheers 
>> - Patrick 
>> 
>> 
>> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com) 
>> wrote: 
>> 
>> Hello Roman, 
>> 
>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko  
>> wrote: 
>>> 
>>> Fuelers, 
>>> 
>>> I remember we’ve discussing this topic in our couloirs before but I’d 
>>> like 
>>> to bring that discussion to a more official format. 
>>> 
>>> Let me state a few reasons to do this: 
>>> 
>>> - Log management code in Nailgun is overcomplicated 
>>> - Working with logs on big scale deployments is barely possible given the 
>>> current representation 
>>> - Due to overcomplexity and ineffectiveness of the code we always get 
>>> recurring bugs like [1]. That eats tons of time to resolve. 
>>> - There are much better specialized tools, say Logstash [2], that can 
>>> deal 
>>> with logs much more effectively. 
>>> 
>>> 
>>> There may be more reasons bus I think even the already mentioned ones are 
>>> enough to think about the following proposal: 
>>> 
>>> - Remove Logs tab from Fuel Web UI 
>>> - Remove logs support from Nailgun 
>>> - Create mechanism that allows to configure different log management 
>>> software, say Logstash, Loggly, etc 
>>> 
>>> - Choose a default software to install and provide a plugin for it from 
>>> the box 
>> 
>> 
>> This is what the LMA/StackLight plugins [1][2] are meant for. No need to 
>> develop anything new. 
>> 
>> And I'm +1 with the removal of log management from Fuel. As you said, it 
>> can't scale... 
>> 
>> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/ 
>> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/ 
>> 
>> 
>>> 
>>> 
>>> 
>>> References 
>>> 1. https://bugs.launchpad.net/fuel/+bug/1553170 
>>> 2. https://www.elastic.co/products/logstash 
>>> 
>>> 
>>> - 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] [tripleo] Logo for TripleO

[Ryan Brady]

On Fri, Mar 11, 2016 at 12:32 AM, Jason Rist  wrote:

> Hey everyone -
> We've been working on a UI for TripleO for a few months now and
> we're
> just about to beg to be a part of upstream... and we're in need of a
> logo for the login page and header.
>
> In my evenings, I've come up with a logo.
>
> It's a take on the work that Dan has already done on the Owl idea:
> http://wixagrid.com/tripleo/tripleo_svg.html
>
> I think it'd be cool if it were used on the CI page and maybe even
> tripleo.org - I ran it by the guys on #tripleo and they seem to be
> pretty warm on the idea, so I thought I'd run it by here if you missed
> the conversation.
>
> It's SVG so we can change the colors pretty easily as I have in the two
> attached screenshots.  It also doesn't need to be loaded as a separate
> asset.  Additionally, it scales well since it's basically vector instead
> of rasterized.
>
> What do you guys think?
>

+1.  The logo looks great.


>
> Can we use it?
>
> I can do a patch for tripleo.org and the ci and wherever else it's in use.
>
> -J
>
> --
> Jason E. Rist
> Senior Software Engineer
> OpenStack Infrastructure Integration
> Red Hat, Inc.
> openuc: +1.972.707.6408
> mobile: +1.720.256.3933
> Freenode: jrist
> github/twitter: knowncitizen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ryan Brady
Cloud Engineering
rbr...@redhat.com
919.890.8925
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [trove] Weekly meeting time change

[Amrith Kumar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It is that time of the year ... The weekly Trove meeting is held at 1800
UTC each Wednesday in #openstack-meeting-alt[1]. This weekend, people
will be going through the twice annual ritual of readjusting their
clocks and changing batteries in smoke detectors. And consequently, the
Trove meeting will move to 2PM Eastern Time on Wednesdays.

If you live in a place which adjusts its clocks please make sure you
take this into account as you plan your Wednesday.

Thanks,

- -amrith


[1] https://wiki.openstack.org/wiki/Meetings/TroveMeeting

- --
Amrith Kumar, CTO   | amr...@tesora.com
Tesora, Inc | @amrithkumar
125 CambridgePark Drive, Suite 400  | http://www.tesora.com
Cambridge, MA. 02140| GPG: 0x5e48849a9d21a29b
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQJ8BAEBCgBmBQJW4ricXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1MDlGREJBQTlDOTQ1N0MxMDdFNUVERERE
M0Y3QTJGMjBFMUU1MzZGAAoJENP3ovIOHlNvm1sQAKFh2suGjZKQBbZvcnLZDf/W
IcwKXAYEB2aO+XiaWuEnM3QPK2pF3o0HCbNPlbQVCA7POKUtsi1CnQXGth1ras+K
9yMWynCjCoi2dBD/UBrnO/dlj/6iXDIhVRaLEz7TBk2J6tHIpoQW60f5o0Lhz8fF
Cqrsyh+q+l3ujGo635x11x4CSZmIzE1QgzVZgV33nHIpGs6/WiPKmq1Lx9ukbFY7
2qEAepE4jh13V0JmMuXTWE/Cx3RnrLAyD7dvRC63+iJZdLfIEbEJijUsGaNX0W5I
AnpLmgko/fuWz43SnqwD20hloSD6ha3Gr9RbQuqa7hvKeb2atvYU1qxWQR5jgp5t
SXUYkmEqysJNCN6Q3vgrD9GcWLIT109F6Hp2VuIdlPi1sPrbUhje/UtCwbu6h3Fd
JKkianxC9CJ1dqSMwgCKmqYEwGm5d3ZR1NPDc5EkI2CvOSxSoRk5dFltvoC5FspK
zUz27orAZsEtIWAQkRdYa0aHCkcu5grBeVfBl0Lpj+fsKwupp2ZIrxN0BqvspE/L
sjYr1X8zoBdWzMPkgNu0EU/QQ66dssDdqiJNqNJ5+7rNxhxs9h8RmXIdAwpUPC6l
HEOFMymRC04PgKlF7zFBqGMMQCPXV9fswTIH/Ng+PBeIcwMS76B6WfdP7/mlTcOs
yPTNqEMjYFl4GxIrdBC3
=JaCS
-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] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Igor Kalnitsky]

Patrick,

Sorry, but I meant another question. I thought that LMA plugin should
be installed in some environment before we can start use it. Is this a
case? If so, it means we can't use for master node until some
environment is deployed.

On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit  wrote:
>
> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com)
> wrote:
>
> Hey Roman,
>
> Thank you for bringing this up. +1 from my side, especially taking
> into account the patch where we tried to solve logrotated logs problem
> [1]. It's complex and unsupportable, as well as already existed
> logview code in Nailgun.
>
> Patrick, Simon,
>
> Does LMA plugin support logs from master node? Or it's designed to
> watch environment's logs?
>
> No it’s not designed specifically for environment logs. Can be adapted to
> any log format.
>
> Would just need to write a parser like you would with logstach when logs are
> not standard.
>
> Patrick
>
>
>
> Thanks,
> Igor
>
>
> [1]: https://review.openstack.org/#/c/243240/
>
> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit  wrote:
>> Fuelers,
>>
>> As Simon said, we already have a log centralisation solution for MOS
>> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
>> objectively, there is no need to have log management in Nailgun anymore.
>> To
>> go one step further we suggested several times to have a StackLight agent
>> installed on the Fuel master node to also collect and centralise those
>> logs.
>> There is a little bit of a chicken and egg problem to resolve but I think
>> it
>> is worth a try to have that nailed down in the roadmap for Fuel 10.
>> Cheers
>> - Patrick
>>
>>
>> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com)
>> wrote:
>>
>> Hello Roman,
>>
>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko 
>> wrote:
>>>
>>> Fuelers,
>>>
>>> I remember we’ve discussing this topic in our couloirs before but I’d
>>> like
>>> to bring that discussion to a more official format.
>>>
>>> Let me state a few reasons to do this:
>>>
>>> - Log management code in Nailgun is overcomplicated
>>> - Working with logs on big scale deployments is barely possible given the
>>> current representation
>>> - Due to overcomplexity and ineffectiveness of the code we always get
>>> recurring bugs like [1]. That eats tons of time to resolve.
>>> - There are much better specialized tools, say Logstash [2], that can
>>> deal
>>> with logs much more effectively.
>>>
>>>
>>> There may be more reasons bus I think even the already mentioned ones are
>>> enough to think about the following proposal:
>>>
>>> - Remove Logs tab from Fuel Web UI
>>> - Remove logs support from Nailgun
>>> - Create mechanism that allows to configure different log management
>>> software, say Logstash, Loggly, etc
>>>
>>> - Choose a default software to install and provide a plugin for it from
>>> the box
>>
>>
>> This is what the LMA/StackLight plugins [1][2] are meant for. No need to
>> develop anything new.
>>
>> And I'm +1 with the removal of log management from Fuel. As you said, it
>> can't scale...
>>
>> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
>> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/
>>
>>
>>>
>>>
>>>
>>> References
>>> 1. https://bugs.launchpad.net/fuel/+bug/1553170
>>> 2. https://www.elastic.co/products/logstash
>>>
>>>
>>> - 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
>>
>>
>> __
>> OpenStack Development Mailing 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] The vote for new Nova API sub-team meeting time

[Alex Xu]

Hi, folks,

>From the result of vote, all the peoples are available on Wednesday at
1300UTC. If no more questions, I think we can start with new time from next
week. And we will switch to #openstack-meeting-4 channel.

Thanks
Alex

2016-03-09 15:56 GMT+08:00 Alex Xu :

> Hi,
>
> Looks like it's time to think about adjust nova api meeting now. I found
> really hard find a time which good for everyone. But let me give a try. I
> find out those time slots:
>
> 1400UTC: this is the time which closes to most people can join the
> meeting. But it's still very late or early for some peoples.
>
> 1200UTC/1300UTC and (01:00UTC/21:00UTC): another way is using alternate
> meeting times. 1200UTC/1300UTC is similar current meeting will drop the PST
> timezone. 01:00UTC will drop the Europe timezone, 21:00UTC will drop the
> Asia timezone.
>
> Let's vote the meeting time at: http://doodle.com/poll/8vq87q32wb5wh9xv
> Then depend on the vote to decide a meeting time.
>
>
> Thanks
> Alex
>
>
>
__
OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Patrick Petit]

On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com) wrote:

Hey Roman,

Thank you for bringing this up. +1 from my side, especially taking
into account the patch where we tried to solve logrotated logs problem
[1]. It's complex and unsupportable, as well as already existed
logview code in Nailgun.

Patrick, Simon,

Does LMA plugin support logs from master node? Or it's designed to
watch environment's logs?
No it’s not designed specifically for environment logs. Can be adapted to any 
log format.

Would just need to write a parser like you would with logstach when logs are 
not standard.

Patrick



Thanks,
Igor


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

On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit  wrote:
> Fuelers,
>
> As Simon said, we already have a log centralisation solution for MOS
> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
> objectively, there is no need to have log management in Nailgun anymore. To
> go one step further we suggested several times to have a StackLight agent
> installed on the Fuel master node to also collect and centralise those logs.
> There is a little bit of a chicken and egg problem to resolve but I think it
> is worth a try to have that nailed down in the roadmap for Fuel 10.
> Cheers
> - Patrick
>
>
> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com) wrote:
>
> Hello Roman,
>
> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko  wrote:
>>
>> Fuelers,
>>
>> I remember we’ve discussing this topic in our couloirs before but I’d like
>> to bring that discussion to a more official format.
>>
>> Let me state a few reasons to do this:
>>
>> - Log management code in Nailgun is overcomplicated
>> - Working with logs on big scale deployments is barely possible given the
>> current representation
>> - Due to overcomplexity and ineffectiveness of the code we always get
>> recurring bugs like [1]. That eats tons of time to resolve.
>> - There are much better specialized tools, say Logstash [2], that can deal
>> with logs much more effectively.
>>
>>
>> There may be more reasons bus I think even the already mentioned ones are
>> enough to think about the following proposal:
>>
>> - Remove Logs tab from Fuel Web UI
>> - Remove logs support from Nailgun
>> - Create mechanism that allows to configure different log management
>> software, say Logstash, Loggly, etc
>>
>> - Choose a default software to install and provide a plugin for it from
>> the box
>
>
> This is what the LMA/StackLight plugins [1][2] are meant for. No need to
> develop anything new.
>
> And I'm +1 with the removal of log management from Fuel. As you said, it
> can't scale...
>
> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/
>
>
>>
>>
>>
>> References
>> 1. https://bugs.launchpad.net/fuel/+bug/1553170
>> 2. https://www.elastic.co/products/logstash
>>
>>
>> - 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
>
>
> __
> OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Igor Kalnitsky]

Hey Roman,

Thank you for bringing this up. +1 from my side, especially taking
into account the patch where we tried to solve logrotated logs problem
[1]. It's complex and unsupportable, as well as already existed
logview code in Nailgun.

Patrick, Simon,

Does LMA plugin support logs from master node? Or it's designed to
watch environment's logs?

Thanks,
Igor


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

On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit  wrote:
> Fuelers,
>
> As Simon said, we already have a log centralisation solution for MOS
> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
> objectively, there is no need to have log management in Nailgun anymore. To
> go one step further we suggested several times to have a StackLight agent
> installed on the Fuel master node to also collect and centralise those logs.
> There is a little bit of a chicken and egg problem to resolve but I think it
> is worth a try to have that nailed down in the roadmap for Fuel 10.
> Cheers
>  - Patrick
>
>
> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com) wrote:
>
> Hello Roman,
>
> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko  wrote:
>>
>> Fuelers,
>>
>> I remember we’ve discussing this topic in our couloirs before but I’d like
>> to bring that discussion to a more official format.
>>
>> Let me state a few reasons to do this:
>>
>> - Log management code in Nailgun is overcomplicated
>> - Working with logs on big scale deployments is barely possible given the
>> current representation
>> - Due to overcomplexity and ineffectiveness of the code we always get
>> recurring bugs like [1]. That eats tons of time to resolve.
>> - There are much better specialized tools, say Logstash [2], that can deal
>> with logs much more effectively.
>>
>>
>> There may be more reasons bus I think even the already mentioned ones are
>> enough to think about the following proposal:
>>
>> - Remove Logs tab from Fuel Web UI
>> - Remove logs support from Nailgun
>> - Create mechanism that allows to configure different log management
>> software, say Logstash, Loggly, etc
>>
>> - Choose a default software to install and provide a plugin for it from
>> the box
>
>
> This is what the LMA/StackLight plugins [1][2] are meant for. No need to
> develop anything new.
>
> And I'm +1 with the removal of log management from Fuel. As you said, it
> can't scale...
>
> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/
>
>
>>
>>
>>
>> References
>> 1.  https://bugs.launchpad.net/fuel/+bug/1553170
>> 2. https://www.elastic.co/products/logstash
>>
>>
>> - 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
>
>
> __
> OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Patrick Petit]

Fuelers,

As Simon said, we already have a log centralisation solution for MOS delivered 
as a Fuel plugins known as StackLight / LMA toolset. And so objectively, there 
is no need to have log management in Nailgun anymore. To go one step further we 
suggested several times to have a StackLight agent installed on the Fuel master 
node to also collect and centralise those logs. There is a little bit of a 
chicken and egg problem to resolve but I think it is worth a try to have that 
nailed down in the roadmap for Fuel 10.
Cheers
 - Patrick  
 
On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com) wrote:

Hello Roman,

On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko  wrote:
Fuelers,

I remember we’ve discussing this topic in our couloirs before but I’d like to 
bring that discussion to a more official format.

Let me state a few reasons to do this:

- Log management code in Nailgun is overcomplicated
- Working with logs on big scale deployments is barely possible given the 
current representation
- Due to overcomplexity and ineffectiveness of the code we always get recurring 
bugs like [1]. That eats tons of time to resolve.
- There are much better specialized tools, say Logstash [2], that can deal with 
logs much more effectively.


There may be more reasons bus I think even the already mentioned ones are 
enough to think about the following proposal:

- Remove Logs tab from Fuel Web UI
- Remove logs support from Nailgun
- Create mechanism that allows to configure different log management software, 
say Logstash, Loggly, etc 
- Choose a default software to install and provide a plugin for it from the box

This is what the LMA/StackLight plugins [1][2] are meant for. No need to 
develop anything new.

And I'm +1 with the removal of log management from Fuel. As you said, it can't 
scale...

[1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
[2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/

 


References
1.  https://bugs.launchpad.net/fuel/+bug/1553170
2. https://www.elastic.co/products/logstash


- 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  
__
OpenStack Development Mailing 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] Compatibility of fuel plugins and fuel versions

[Evgeniy L]

Hi Mike, thanks for clarification.

On Fri, Mar 11, 2016 at 9:42 AM, Mike Scherbakov 
wrote:

> Thank you for comments folks.
> Clarifications, with the feedback incorporated:
> 1) We can install plugin developed against 8 to Fuel Mitaka (9). But it
> won't appear in the UI as available plugin. This is what I want to fix, and
> have just a warning that this plugin may not work.
>
>
We can do that, but I don't think that we should add any new fields, we
already have "releases" field, which specifies compatibility (hence they
has to be verified with these versions). For versions which are not in the
list, as you suggested, we can show a message for the user, that we don't
actually know if it's going to work.


> 2) To clarify, I'm talking about using plugin developed against
> 8.0-liberty in 9.0-mitaka, e.g. in newer Fuel with newer OpenStack release
> deployed. I understand that we've changed names of tasks, and now it's just
> impossible to have any meaningful plugin developed against 8 which would
> work in Mitaka without other task names, etc. But - do we expect renames
> over again and again? Any other changes? I hope the answer is no, that we
> want to stabilize an interface. I understand, that new OpenStack release
> may require changes in tasks, new tasks would appear, new dependencies.
> However, I assume that vast majority of components don't change that often.
> So, do we have any suggestions how we can keep tasks and whatever else from
> changes? Can we introduce backward compatibility here?
> I'm trying to understand how hard it will be to make. As otherwise, every
> plugin developer will have to learn new tasks every new release, and re-do
> the work.
>
>
As far as I know we have renames and graph shuffling (almost?) every
release, but looking at some of the plugins, most of them use old format
(i.e. pre/post), and for new tasks there are dependencies on anchors
(pre/post) which don't get changed too often.
I see no way (or I see only very expensive ways) to support graph in a way
it won't break old plugins, even bug fix sometimes requires graph changes
(e.g. to fix race conditions).


> 3) Multi-release support is kinda covered in (2) here. If plugin's code
> needs little tweaks in order to support new release of Fuel, I'd suggest to
> figure out how we can use inheritance and keep code for multiple Fuel
> releases in one plugin repo. In current reality, when it means to fork
> almost everything, I'm in a support of having a plugin branch per Fuel
> release. Thanks for links to the corresponding thread and plugins v5 spec,
> I'll take a careful look.
>
> > So I don't quite understand how new"validated_against" parameter will
> differ from existing "releases" list.
> Alex, I meant to have different use of what we have now. Instead of
> blocking a user from using a plugin in "unsupported" Fuel version, allow it
> - but warn.
>
> Thanks,
>
>
> On Thu, Mar 10, 2016 at 4:50 AM Aleksandr Didenko 
> wrote:
>
>> > Good idea. That should be done despite on any decision we will take.
>>
>> Currently you have to specify which releases your plugin supports [0]. So
>> I can take my plugin developed for 8.0 and install it on Fuel-9.0 (I
>> actually did it and it worked just fine). But I won't be able to enable
>> this plugin for "mitaka-9.0" release because plugin was not developed and
>> tested for it, so it does not have "miraka-9.0" in "releases" list [0]. So
>> I don't quite understand how new "validated_against" parameter will
>> differ from existing "releases" list.
>>
>> Regards,
>> Alex
>>
>> [0]
>> https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21
>>
>>
>> On Thu, Mar 10, 2016 at 10:22 AM, Bogdan Dobrelya > > wrote:
>>
>>> On 10.03.2016 08:30, Mike Scherbakov wrote:
>>> > Hi folks,
>>> > in order to make a decision whether we need to support example plugins,
>>> > and if actually need them [1], I'd suggest to discuss more common
>>> things
>>> > about plugins.
>>> >
>>> > My thoughts:
>>> > 1) This is not good, that our plugins created for Fuel 8 won't even
>>> > install on Fuel 9. By default, we should assume that plugin will work
>>> at
>>> > newer version of Fuel. However, for proper user experience, I suggest
>>> to
>>> > create meta-field "validated_against", where plugin dev would provide
>>> > versions of Fuel this plugin has been tested with. Let's say, it was
>>> > tested against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest
>>> > to show a warning saying about risks and the fact that the plugin has
>>> > not been tested against 9. We should not restrict intsallation against
>>> > 9, though.
>>>
>>> Good idea. That should be done despite on any decision we will take.
>>>
>>> >
>>> > 2) We need to keep backward compatibility of pluggable interface for a
>>> > few releases. So that plugin developer can use pluggable interface of
>>> > 

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Evgeniy L]

Hi,

+1, it's very hard to use current representation of logs for debugging,
everybody goes to the node and tries to find required logs, instead of
reimplementing debugging friendly tool it would be better to get something
ready to use on the master.

Thanks,

On Fri, Mar 11, 2016 at 12:05 PM, Simon Pasquier 
wrote:

> Hello Roman,
>
> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko 
> wrote:
>
>> Fuelers,
>>
>> I remember we’ve discussing this topic in our couloirs before but I’d
>> like to bring that discussion to a more official format.
>>
>> Let me state a few reasons to do this:
>>
>> - Log management code in Nailgun is overcomplicated
>> - Working with logs on big scale deployments is barely possible given the
>> current representation
>> - Due to overcomplexity and ineffectiveness of the code we always get
>> recurring bugs like [1]. That eats tons of time to resolve.
>> - There are much better specialized tools, say Logstash [2], that can
>> deal with logs much more effectively.
>>
>>
>> There may be more reasons bus I think even the already mentioned ones are
>> enough to think about the following proposal:
>>
>> - Remove Logs tab from Fuel Web UI
>> - Remove logs support from Nailgun
>> - Create mechanism that allows to configure different log management
>> software, say Logstash, Loggly, etc
>
> - Choose a default software to install and provide a plugin for it from
>> the box
>>
>
> This is what the LMA/StackLight plugins [1][2] are meant for. No need to
> develop anything new.
>
> And I'm +1 with the removal of log management from Fuel. As you said, it
> can't scale...
>
> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/
>
>
>
>>
>>
>> References
>> 1.  https://bugs.launchpad.net/fuel/+bug/1553170
>> 2. https://www.elastic.co/products/logstash
>>
>>
>> - 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
>
>
__
OpenStack Development Mailing 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] Logo for TripleO

[Dmitry Tantsur]

On 03/11/2016 06:32 AM, Jason Rist wrote:

Hey everyone -
We've been working on a UI for TripleO for a few months now and we're
just about to beg to be a part of upstream... and we're in need of a
logo for the login page and header.

In my evenings, I've come up with a logo.

It's a take on the work that Dan has already done on the Owl idea:
http://wixagrid.com/tripleo/tripleo_svg.html


This is looking fantastic!! Big +1 to using it everywhere.

We also need to put somewhere both this Owl and ironic's Bear together :)



I think it'd be cool if it were used on the CI page and maybe even
tripleo.org - I ran it by the guys on #tripleo and they seem to be
pretty warm on the idea, so I thought I'd run it by here if you missed
the conversation.

It's SVG so we can change the colors pretty easily as I have in the two
attached screenshots.  It also doesn't need to be loaded as a separate
asset.  Additionally, it scales well since it's basically vector instead
of rasterized.

What do you guys think?

Can we use it?

I can do a patch for tripleo.org and the ci and wherever else it's in use.

-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




__
OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Simon Pasquier]

Hello Roman,

On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko  wrote:

> Fuelers,
>
> I remember we’ve discussing this topic in our couloirs before but I’d like
> to bring that discussion to a more official format.
>
> Let me state a few reasons to do this:
>
> - Log management code in Nailgun is overcomplicated
> - Working with logs on big scale deployments is barely possible given the
> current representation
> - Due to overcomplexity and ineffectiveness of the code we always get
> recurring bugs like [1]. That eats tons of time to resolve.
> - There are much better specialized tools, say Logstash [2], that can deal
> with logs much more effectively.
>
>
> There may be more reasons bus I think even the already mentioned ones are
> enough to think about the following proposal:
>
> - Remove Logs tab from Fuel Web UI
> - Remove logs support from Nailgun
> - Create mechanism that allows to configure different log management
> software, say Logstash, Loggly, etc

- Choose a default software to install and provide a plugin for it from the
> box
>

This is what the LMA/StackLight plugins [1][2] are meant for. No need to
develop anything new.

And I'm +1 with the removal of log management from Fuel. As you said, it
can't scale...

[1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
[2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/



>
>
> References
> 1.  https://bugs.launchpad.net/fuel/+bug/1553170
> 2. https://www.elastic.co/products/logstash
>
>
> - 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

[openstack-dev] [Group-based-policy] do we have any usage doc about service function chaining feature?

[gong_ys2004]

Hi,I failed to find any usage doc about GBP project's SFC feature.Could any one 
please help to point me to the location?
Thanksyong sheng gong__
OpenStack Development Mailing 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] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Roman Prykhodchenko]

Fuelers,

I remember we’ve discussing this topic in our couloirs before but I’d like to 
bring that discussion to a more official format.

Let me state a few reasons to do this:

- Log management code in Nailgun is overcomplicated
- Working with logs on big scale deployments is barely possible given the 
current representation
- Due to overcomplexity and ineffectiveness of the code we always get recurring 
bugs like [1]. That eats tons of time to resolve.
- There are much better specialized tools, say Logstash [2], that can deal with 
logs much more effectively.


There may be more reasons bus I think even the already mentioned ones are 
enough to think about the following proposal:

- Remove Logs tab from Fuel Web UI
- Remove logs support from Nailgun
- Create mechanism that allows to configure different log management software, 
say Logstash, Loggly, etc
- Choose a default software to install and provide a plugin for it from the box


References
1.  https://bugs.launchpad.net/fuel/+bug/1553170
2. https://www.elastic.co/products/logstash


- 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] [tripleo] Contributing to TripleO is challenging

[Michael Chapman]

On Sat, Mar 5, 2016 at 10:31 AM, Giulio Fidente  wrote:

> On 03/04/2016 03:23 PM, Emilien Macchi wrote:
>
>> That's not the name of any Summit's talk, it's just an e-mail I wanted
>> to write for a long time.
>>
>> It is an attempt to expose facts or things I've heard a lot; and bring
>> constructive thoughts about why it's challenging to contribute in
>> TripleO project.
>>
>
> hi Emilien,
>
> thanks for bringing this up, it's not an easy topic and yet of most
> crucial. As a core contributors I feel, to some extent, responsible for the
> current status of things and I think it's time for us to reflect more about
> what we can, individually, do.
>
> I have some ideas but I want to start by commenting to your points.
>
> 1/ "I don't review this patch, we don't have CI coverage."
>>
>> One thing I've noticed in TripleO is that a very few people are involved
>> in CI work.
>> In my opinion, CI system is more critical than any feature in a product.
>> Developing Software without tests is a bit like http://goo.gl/OlgFRc
>> All people - specially core - in the project should be involved in CI
>> work. If you are TripleO core and you don't contribute on CI, you might
>> ask yourself why.
>>
>
> Agreed, we need more 'eyes' on out CI to cope with both the infra and the
> inavoidable failures due to changes/bugs in the puppet modules or openstack
> itself.
>
> But there is more hiding behind this problem ... we already have quite a
> number of optional and even pluggable features in TripleO and we're even
> designing an interface to make this easier; testing them all isn't going to
> happen. So we'll always hit something we don't have coverage for.
>
> Let's have a conversation on how we can improve coverage at the summit!
> Maybe we can make simply make our CI scenarios more variegated/complex in
> the attempt to touch more features?
>
> 2/ "I don't review this patch, CI is broken."
>>
>> Another thing I've noticed in TripleO is that when CI is broken, again,
>> a very few people are actually working on fixing failures.
>> My experience over the last years taught me to stop my daily work when
>> CI is broken and fix it asap.
>>
>
> Agreed. More eyes and more coverage to increase its dependability.
>
> 3/ "I don't review it, because this feature / code is not my area".
>>
>> My first though is "Aren't we supposed to be engineers and learn new
>> areas?"
>> My second though is that I think we have a problem with TripleO Heat
>> Templates.
>> THT or TripleO Heat Templates's code is 80% of Puppet / Hiera. If
>> TripleO core say "I'm not familiar with Puppet", we have a problem here,
>> isn't?
>> Maybe should we split this repository? Or revisit the list of people who
>> can +2 patches on THT.
>>
>
> Not sure here, I find that manifests and templates are pretty much "meant
> to go together" so I am worried that a split could solve some problems but
> also cause others.
>

This is pretty much what I proposed last week (
https://blueprints.launchpad.net/tripleo/+spec/refactor-puppet-manifests)
and I noticed Dan approved the blueprint yesterday (cheers). It's
definitely going to cause problems in that THT defines the data interface
and puppet-tripleo is going to have to keep up with that interface in
lock-step in some cases so be prepared to deal with that as a patch author.
This isn't really any different to non-tripleo puppet module situations
where a change to the repo holding hiera data will be tied to changes in
modules.

Ideally I'd like to incrementally decouple the puppet-tripleo profiles from
the data heat provides but for the first cut they'll be joined at the hip.

So given a new home (puppet-tripleo) for a large portion of the code
(starting with overcloud controller and controller_pacemaker), hopefully
this paves the way for giving those who know puppet well the opportunity to
take on responsibility for the manifests without necessarily being
intimately familiar with the rest of the system, which I guess helps with
Emilien's original concern that there's a skill split across the tooling
lines.


>
> This said, let's be honest, an effective patch for THT requires a good
> understanding of many different problems which can be TripleO specific (eg.
> implications on upgrades), tooling specific (eg. Heat/Puppet), OpenStack
> specific (eg. cooperation with other, optional, features) so I have myself
> skipped changes when I didn't feel comfortable with it.
>
> But one problem which I think is more recently slowing reviews and which
> is somewhat concause of 3) is that we're not dealing too well with code
> duplication in the yamls and with conditional logic in the manifests.
>
> Maybe we could stop and think a together about new HOT functionalities
> which could help us? Interesting for the summit as well?
>
> 4/ Patches are stalled. Most of the time.
>>
>> Over the last 12 months, I've pushed a lot of patches in TripleO and one
>> thing I've noticed is that if I don't ping people, my patch 

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten tohorizon-core

[Tatiana Ovtchinnikova]

+1. Thanks for your contribution!


2016-03-11 6:40 GMT+03:00 Zhenguo Niu :

> +1 from me, thanks for all the hard work!
>
> On Thu, Mar 10, 2016 at 3:27 AM, Michael Krotscheck 
> wrote:
>
>> +1. Another vote in favor of ditching django altogether is good by me :)
>>
>> On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran  wrote:
>>
>>> Big +1 from me, thanks for all the hard work Diana!
>>>
>>>
>>> - Original message -
>>> From: David Lyle 
>>> To: OpenStack Development Mailing List <
>>> openstack-dev@lists.openstack.org>
>>> Cc:
>>> Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>>> horizon-core
>>> Date: Tue, Mar 8, 2016 2:07 PM
>>>
>>> I propose adding Diana Whitten[1] to horizon-core.
>>>
>>> Diana is an active reviewer, contributor and community member. Over
>>> the past couple of releases, Diana has driven extensive changes around
>>> theme-ability in Horizon and drastically increased the standardization
>>> of our use of bootstrap. During this time, Diana has also provided
>>> valuable reviews to keep us on the straight and narrow preventing our
>>> continued abuse of defenseless web technologies.
>>>
>>> Please respond with comments, +1s, or objections by Friday.
>>>
>>> Thanks,
>>> David
>>>
>>> [1]
>>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>>
>>
>
>
> --
> Best Regards,
> Zhenguo Niu
>
> __
> OpenStack Development Mailing 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] Trouble mapping the Remote PXE node

[Vladimir Kuklin]

Hi, Akshik

Thanks for the email. Do you have nailgun logs with you? I guess, it would
much more easier to debug this while having more diagnostic info. Please,
file a bug at launchpad following the steps described here:

https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Bugs

then post the link to this thread. The diagnostic snapshot would give us
more info on your environment configuration along with logs of Nailgun.

Feel free to contact us again whether you face any issues filing the bug.

On Fri, Mar 11, 2016 at 9:59 AM, Akshik dbk  wrote:

>  Hi,
>
> I'm using Fuel 7.0, trying to evaluate remote compute and node group
>
>
> I've configured a remote PXE and I'm able to boot the node successfully
> onto the remote pxe, but while adding it to the environment and trying to
> configure interface I'm stuck with following error
>
>
> fuel node --node-id 43 --network upload
>
> DEPRECATION WARNING: /etc/fuel/client/config.yaml exists and will be used
> as the source for settings. This behavior is deprecated. Please specify the
> path to your custom settings file in the FUELCLIENT_CUSTOM_SETTINGS
> environment variable.
>
> 400 Client Error: Bad Request (Node '43': '53' network(s) are left
> unassigned)
>
>
> the interface yams file is
>
> http://paste.openstack.org/show/490098/
>
>
> pls. help
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.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