[openstack-dev] Self-nomination to serve on the technical committee team

2016-09-29 Thread Steven Dake (stdake) 
My Peers,

I am self-nominating for serving you as your technical committee
representative.

I won't bore you with my professional accomplishments.  If you want to
see such information to judge if I'm qualified for serving you on the
technical committee team, that information is available in my
foundation profile linked at the bottom of this self-nomination or
on LinkedIn.

I'll get straight to the point instead.

I believe in OpenStack's mission.  I believe in the OpenStack way.
I believe in the Four Opens.  I believe in the OpenStack principles.
I believe in OpenStack itself.  I believe Open Source has changed the
world of computing in a fundamentally more effective way.  Most
importantly, I believe the diversity of opinions and teams in our
community are what make OpenStack special.  I'm a believer.

I think the TC has done a reasonable job of managing OpenStack's
tremendous technical growth.  If you want a history lesson from my
point of view on why OpenStack is the way it is today, please
reference my Newton technical committee self-nomination [1].

The Big Tent needs some fine tuning, and the technical committee is
working to make that occur.  Fine tuning to me doesn't mean we need to
overthrow years of progress because some folks perceive OpenStack as
having an identity crisis.  I also don't believe defending the status
quo represents fine tuning.  Fine tuning to me means making incremental
improvements to the state of the art.

This is how we develop software in OpenStack after a community around
the software has been bootstrapped.

Let’s face reality for a moment.  OpenStack does have some problems.
They all stem from various choices made along the OpenStack journey.

There are five types of consumers of OpenStack's software:

application developers of the operator's clouds
consumers of the operator's clouds
infrastructure developers of the OpenStack software
operators operating clouds produced by the developers of the OpenStack software
OpenStack distributors
This problem so far has gone unacknowledged.  The problem to be
solved with OpenStack is ensuring the above five types of consumers
of OpenStack's software are served fairly, equally, with respect,
and most importantly effectively.  These are the individuals our
community represents.  This is an extremely difficult problem to solve.

Can it be solved alone by any individual?  NO.
Can in be solved by the technical committee?  NO.
Can it be solved by the technical committee and various other working
groups involved in making OpenStack tick?  NO.
Can it be solved by our community of developers, core reviewers,
project team leads, technical committee team, operators,
working groups, OpenStack distributors working in concert?  I am hopeful.

I am a tenacious problem solver.  If you make a choice to select me as
your technical committee representative, I will dedicate myself to
working with the technical committee to facilitate a solution to this
problem just as I have done in other leadership service roles inside
the OpenStack community.

While working to solve this problem, I will keep driving OpenStack
forward to the horizon with the help of your vote and the technical
committee.

Freenode: sdake
Review history: https://review.openstack.org/#/q/reviewer:2834,n,z
Commit history: https://review.openstack.org/#/q/owner:2834,n,z
Stackalytics: http://stackalytics.com/?user_id=sdake=all
Foundation Profile: https://www.openstack.org/community/members/profile/360
Website: https://sdake.io
[1] 
http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/TC/Steven_Dake.txt

__
OpenStack Development Mailing 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] What's Up, Doc? 30 September

2016-09-29 Thread Lana Brindley 
Hi everyone,

We're on the final countdown to Newton now! The release managers Olena and Alex 
are busy getting the release patches ready, the Install Guide testing team are 
madly working through the last few sections, and Andreas and I have our fingers 
hovering over the big red GO button! Don't forget that you can contact any of 
us (or just send mail to the docs mailing list) if you have any questions about 
the Newton docs release. 

Please be aware that the core team will not be merging non-critical patches 
until after we've branched for Newton, particularly for the Installation Guide. 
We usually cut the branch about a week after Summit concludes, so you might be 
asked to wait until then. If that happens, a core will -2 your patch until 
after we've branched. 

== Progress towards Newton ==

5 days to go!

Bugs closed so far: 466

Release managers: Olena Logvinova and Alexandra Settle

Release tasks are being tracked here: 
https://etherpad.openstack.org/p/NewtonRelease

Install Guide testing is being tracked here: 
https://wiki.openstack.org/wiki/Documentation/NewtonDocTesting

== The Road to Barcelona ==

I have a draft schedule up, which you can see here: 
https://etherpad.openstack.org/p/Ocata-DocsSessions I'll put this into Sched 
once the tool becomes available, and your early feedback is welcome. 
Additionally, if you're interested in moderating a session in Barcelona, please 
let me know.

== Core Team Reviews ==

Just a quick note that we won't be holding a core team review in October, as it 
conflicts with release, or in November, as it conflicts with Summit. We'll 
resume these in December for the Newton cycle.

== Doc team meeting ==

Next meetings:

The US meeting was held this week, you can read the minutes here: 
https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2016-09-28

Next meetings:
APAC: Wednesday 5 October, 00:30 UTC (This will be the final meeting before 
release day!)
US: Wednesday 12 October, 19:00 UTC

Please go ahead and add any agenda items to the meeting page here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#30_September_2016

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

[openstack-dev] [tricircle]stable/newton branch created

2016-09-29 Thread joehuang 
Hello, all

All "must to have" patches have been merged, the "stable/newton" branch was 
just created: https://github.com/openstack/tricircle/tree/stable/newton

Before the newton release, two more patches needed for this branch: one patch 
to update devstack related script to download newton branch code, one patch for 
release note.

The release date for Tricircle Newton will be around Oct.15, after 
Nova/Cinder/Neutron publish their Newton release.

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

[openstack-dev] TC Candidacy

2016-09-29 Thread John Griffith 
Hey Everyone,

Some of you may know me, I've been around the OpenStack community for a
while (longer than some, shorter than others).  I'm not an "uber hipster",
or a "super cool bro-grammer", or even a "mega hacker" trying to write the
most clever code possible to impress everyone.

I am however someone that has been contributing to OpenStack for about five
years now.  Not only via code contributions, but services, support and
evangelism.  I started the Cinder project with some great help from a few
other folks and did the best I could with that while forging ahead into
unknown territory.  I use OpenStack on a daily basis in a number of private
clouds, have helped several average sized companies deploy and maintain
OpenStack clouds and have spent countless hours helping people get their
heads wrapped around the whole OpenStack Platform thing and how it might be
able solve some of their problems.

I'm not going to try and claim that I have all the answers related to
OpenStack and the TC, in fact, I'm not even going to pretend to know what
all the questions are.  I'm not going to tell you what a great person I am,
or all of my "great achievements" over the years.  As we all know, people
can write up whatever wonderful things.  People can say or write up just
about anything and promise the world without really having any idea what
they're talking about.

What I will say however, is that I believe OpenStack has changed
dramatically over the last few years.  Some things for the better, some
things... not so much.  While I think the past is extremely important for
the experience it gives, I think what's more important and critical is the
future and where OpenStack is going over the course of the next few years.

OpenStack is a bit ambiguous for a lot of people that I talk to (both
inside and outside of the community).  Even more unclear is what do we want
to be in another two years, three or even five?  Do we want to just
continue being a platform that kinda looks like AWS or a "free" version of
VMware?  Do we want our most popular topic at the key-notes to continue
being customers telling their story of "how hard" it was to do OpenStack?

I think we're at an important cross-roads with respect to the future of
OpenStack.  It's my belief that the TC has a great opportunity (with the
right people) to take input from the "outside world" and drive a meaningful
and innovative future for OpenStack.  Maybe try and dampen the echo-chamber
a bit, see if we can identify some real problems that we can help real
customers solve.

I'd like to see us embracing new technologies and ways of doing things.
I'd love to have a process where we don't care so much about the check
boxes of what oslo libs you do or don't use in a project, or how well you
follow the hacking rules; but instead does your project actually work?  Can
it actually be deployed by somebody outside of the OpenStack community or
with minimal OpenStack experience?

It's my belief that Projects should offer real value as stand-alone
services just as well as they do working with other OpenStack services.  I
should be able to use them equally as well outside the eco-system as in
side of it.  I believe the TC should consider driving issues like these and
help guide the future of OpenStack.

If you like my philosophy (really that's all it is), or agree with it; I'd
love the opportunity to try and make some of this a reality.  I can't
promise anything, except that I'll try to do what I believe is good for the
community (especially deployers and end-users).

Feel free to ask me about my thoughts on anything specific, I'm happy to
answer any questions that I can as honestly as I can.

Thanks,
John
__
OpenStack Development Mailing 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] [trio2o]Trio2o cleaning discussion

2016-09-29 Thread joehuang 
etherpad: https://etherpad.openstack.org/p/Trio2oCleaning

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 29 September 2016 10:59
To: openstack-dev
Subject: [openstack-dev][trio2o]Trio2o cleaning discussion

Hello,

As we discussed yesterday, we'll have a short conversation on the Trio2o 
cleaning.

Let's discuss Trio2o cleaning on Friday UTC2:00(i.e, beijing time 10:00), 1 hour

It would be better to discuss this in the channel of #openstack-trio2o instead 
of #openstack-tricircle(sorry mentioned #openstack-tricircle channel yesterday).

Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing 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-python-agent]code-review about this commit https://review.openstack.org/#/c/369245/

2016-09-29 Thread zhou . ya 
Hi ironic team：

I reported a bug of "get pci device's numa_node info when collecting 
pci devices info" on ironic-python-agent launchpad.

this is the bug link: 
https://bugs.launchpad.net/ironic-python-agent/+bug/1622940 

And here is the commit: https://review.openstack.org/#/c/369245/

Could anyone of your team take a little time to look into this commit and 
spare some time to do the code-review?

Thank you very much.

Looking forward for your response.
Regards
zhouya
__
OpenStack Development Mailing 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] [daisycloud-core] Agenda for IRC meeting 0800UTC Sep. 30 2016

2016-09-29 Thread hu . zhijiang 
1) Roll Call
2) Core Code Abstraction
3) Bifrost/Ironic Integration
4) OPNFV: Daisy4nfv CI Framework Progress
5) Bare Metal Deployment(PXE/IPMI) demo2 doc and artifact

B.R.,
Zhijiang


__
OpenStack Development Mailing 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] [daisycloud-core] Agenda for IRC meeting 0800UTC Sep. 30 2016

2016-09-29 Thread hu . zhijiang 
B.R.,
Zhijiang


__
OpenStack Development Mailing 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] TC Candidacy

2016-09-29 Thread Qiming Teng 
I believe this is the voice we really need in the TC.
THANK YOU.

- Qiming

On Thu, Sep 29, 2016 at 11:47:12PM +, Jeremy Stanley wrote:
> I guess I'll send a copy of mine to the ML too, since all the cool
> kids seem to be doing it...
> 
> Most of you probably know me as "that short dude in the Hawaiian
> shirt and long hair." I'll answer to "Jeremy," "fungi" or even just
> "hey you." I'm starting my third cycle as PTL of the Infrastructure
> team, and have been a core reviewer and root sysadmin for
> OpenStack's community-maintained project infrastructure for the past
> four years. I've also been doing vulnerability management in
> OpenStack for almost as long, chaired conference tracks, and given
> talks to other communities on a variety of OpenStack-related topics.
> I help with elections, attend and participate in TC meetings and
> review proposed changes to governance. I have consistent, strong
> views in favor of free software and open/transparent community
> process.
> 
> https://wiki.openstack.org/user:fungi
> 
> I see OpenStack not as software, but as a community of people who
> come together to build something for the common good. We've been
> fortunate enough to experience a bubble of corporate interest which
> has provided amazing initial momentum in the form of able software
> developers and generous funding, but that can't last forever. As
> time goes on, we will need to rely increasingly on effort from
> people who contribute to OpenStack because it interests them, rather
> than because some company is paying them to do so. The way I see it,
> we should be preparing now for the future of our project:
> independent, volunteer contributors drawn from the global free
> software community. However, we're not succeeding in attracting them
> the way some other projects do, which brings me to a major
> concern...
> 
> OpenStack has a public relations problem we need to solve, and soon.
> I know I'm not the only one who struggles to convince contributors
> in other communities that we're really like them, writing free
> software under transparent processes open to any who wish to help.
> This skepticism comes from many sources, some overt (like our
> massive trade conferences and marketing budget) while others
> seemingly inconsequential (such as our constant influx of new
> community members who are unfamiliar with free software concepts and
> lack traditional netiquette). Overcoming this not-really-free
> perception is something we absolutely must do to be able to attract
> the unaffiliated volunteers who will continue to maintain OpenStack
> through the eventual loss of our current benefactors and well into
> stabilization.
> 
> Prior to OpenStack, I worked for longer than I care to remember as
> an "operator" at Internet service, hosting and telecommunications
> providers doing Unix systems administration, network engineering,
> virtualization and information security. When I first started my
> career, you couldn't be a capable systems administrator without a
> firm grasp of programming fundamentals and couldn't be a good
> programmer without understanding the basics of systems
> administration. I'm relieved that, after many years of companies
> trying to tell us otherwise, our industry as a whole is finally
> coming back around to the same realization. Similarly, I don't
> believe we as a community benefit by socializing a separation of
> "operators" from "developers" and feel the role distinction many
> attempt to strike between the two is at best vague, while at its
> worst completely alienating a potential source of current and future
> contributions.
> 
> What causes software to succeed in the long run is not hype,
> limitless funding or even technical superiority, it's the size and
> connectedness of its community of volunteers and users who invest
> themselves and their personal time. The work we're doing now is
> great, don't get me wrong, but for it to survive into the next
> decade and beyond we need to focus more on building a close-knit
> community of interested contributors even if it's not in the best
> interests of industry pundits or vendor product roadmaps.
> 
> OpenStack is people. If we lose sight of that, it's over.
> -- 
> Jeremy Stanley


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

Re: [openstack-dev] TC candidacy

2016-09-29 Thread John Dickinson 


On 29 Sep 2016, at 16:00, gordon chung wrote:

>
> On 29/09/16 04:35 PM, John Dickinson wrote:
>>
>> I am concerned that there is a current focus on preserving the status
>> quo. There's focus on policies and rules instead of use cases; there's
>> focus on conformity instead of innovation; there's focus on forced
>> prioritization instead of inclusivity.
>
> i fully agree with this pov. there's a sentiment among certain members
> that if you choose a path different from the norm, you are not
> "following the OpenStack way".
>
> my question is (i guess this in theory could be ask to everyone), the
> the TC has historically been a reactive council that lets others ask for
> change and acts as the final approver (arguably, just my opinion). do
> you believe the TC should be a proactive committee that drives change?
> and if yes, to what scope? i realise the follow up is very open-end and
> vague and i apologise for this.

The TC is not small enough, and OpenStack is too big, for the TC to proactively 
drive and manage change across all OpenStack projects. In fact, I think 
OpenStack is too big for any one group to try to manage a task for all 
projects. I like how the docs team has been pushing docs into each project 
repository. That distributes the load and solves a scaling problem.

In my experience as a PTL for a single OpenStack project, I've learned that I 
can influence by suggestion, but I cannot mandate anything. In a large part, my 
role has been to respond to what the community is doing by removing any 
barriers that exist, monitoring the status of the team, connecting people 
working on similar tasks, and providing a general vision of where we're going 
as a project.

I see the role of the TC in much the same way. The TC should not be the 
high-priesthood of OpenStack where we go to present our supplications before 
we're allowed to do something. Individual projects should default to "doing" 
and the TC's role there is to make sure barriers for "doing" are removed. The 
individual projects are what initial and drive change in OpenStack, based on 
the needs of their specific users, and the TC aggregates those changes across 
projects to facilitate communication with the broader ecosystem about OpenStack 
in general.

I'm sure I could go on for quite a while about specifics I'd like to see. 
Here's a short list of bullets of things I'd love to see the TC take on:

 * Every project installable in 10 minutes or less.
 * Most projects independently installable to solve a specific use case for a 
deployer.
 * Track contributor activity to identify when and why people contribute. Is 
there some pattern that can be used to identify when someone might leave the 
community? Is there a pattern of how long-term contributors start? What are the 
major barriers for new contributors?
 * How do we reduce the average time a patch spends in review?
 * Why are people adopting OpenStack? If people move away from OpenStack (in 
whole or in part), what was missing in OpenStack?
 * What improvements can we make to facilitate team communication across time 
zones and across cultural lines?
 * How do we provide our corporate sponsors with a reasonably-accurate view of 
future development work?
 * How do we support new languages and deployment tools in OpenStack projects?
 * What improvements can we make to integrate proprietary software and hardware 
into our projects?
 * How does OpenStack work in a world where "cloud" is dominated by AWS, 
Google, and Microsoft?

etc.



--John



>
>>
>> If I am elected to the TC, I will look at every decision in the light
>> of these two needs. I will not focus on codifying rules, and I will
>> not focus on keeping OpenStack small and homogeneous. I will do what I
>> can to help the OpenStack community increase adoption today and remain
>> relevant as the industry changes.
>>
>
> yay to less codifying rules!
>
> 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


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] [neutron][lbaas][heat][octavia] Heat engine doesn't detect lbaas listener failures

2016-09-29 Thread Michael Johnson 
Hi folks,

Yes, I think there are some discrepancies around the provisioning
status being exposed.

Currently I think the only way to get visibility to those is through
the status api:
http://developer.openstack.org/api-ref/networking/v2/#show-load-balancer-status-tree
Which, frankly, I think there are some bugs in.

Going forward we do want to flesh these out and expose them as appropriate.

My intent is to have provisioning status on all of our top level
objects that can independently go into an ERROR state should there be
a problem.  This should allow users/operators the ability to
delete/re-create any object that had a failure the driver was unable
to recover from.

If you see gaps or items you need visibility to, please open bugs for
us and extra credit if you ping us in the #openstack-lbaas channel or
during our weekly meeting.

Michael

On Wed, Sep 28, 2016 at 10:51 AM, Jiahao Liang
 wrote:
> But in the lbaas db, all lbaas resources have the provisioning_status and
> operating_status fields[1].
> [1]http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/neutron_lbaas/db/loadbalancer/models.py#n352
>
> Also there are apis which allows drivers to maintain them[2].
> [2]http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/neutron_lbaas/agent/agent_manager.py#n255
>
> __
> OpenStack Development Mailing 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] TC Candidacy

2016-09-29 Thread Jeremy Stanley 
I guess I'll send a copy of mine to the ML too, since all the cool
kids seem to be doing it...

Most of you probably know me as "that short dude in the Hawaiian
shirt and long hair." I'll answer to "Jeremy," "fungi" or even just
"hey you." I'm starting my third cycle as PTL of the Infrastructure
team, and have been a core reviewer and root sysadmin for
OpenStack's community-maintained project infrastructure for the past
four years. I've also been doing vulnerability management in
OpenStack for almost as long, chaired conference tracks, and given
talks to other communities on a variety of OpenStack-related topics.
I help with elections, attend and participate in TC meetings and
review proposed changes to governance. I have consistent, strong
views in favor of free software and open/transparent community
process.

https://wiki.openstack.org/user:fungi

I see OpenStack not as software, but as a community of people who
come together to build something for the common good. We've been
fortunate enough to experience a bubble of corporate interest which
has provided amazing initial momentum in the form of able software
developers and generous funding, but that can't last forever. As
time goes on, we will need to rely increasingly on effort from
people who contribute to OpenStack because it interests them, rather
than because some company is paying them to do so. The way I see it,
we should be preparing now for the future of our project:
independent, volunteer contributors drawn from the global free
software community. However, we're not succeeding in attracting them
the way some other projects do, which brings me to a major
concern...

OpenStack has a public relations problem we need to solve, and soon.
I know I'm not the only one who struggles to convince contributors
in other communities that we're really like them, writing free
software under transparent processes open to any who wish to help.
This skepticism comes from many sources, some overt (like our
massive trade conferences and marketing budget) while others
seemingly inconsequential (such as our constant influx of new
community members who are unfamiliar with free software concepts and
lack traditional netiquette). Overcoming this not-really-free
perception is something we absolutely must do to be able to attract
the unaffiliated volunteers who will continue to maintain OpenStack
through the eventual loss of our current benefactors and well into
stabilization.

Prior to OpenStack, I worked for longer than I care to remember as
an "operator" at Internet service, hosting and telecommunications
providers doing Unix systems administration, network engineering,
virtualization and information security. When I first started my
career, you couldn't be a capable systems administrator without a
firm grasp of programming fundamentals and couldn't be a good
programmer without understanding the basics of systems
administration. I'm relieved that, after many years of companies
trying to tell us otherwise, our industry as a whole is finally
coming back around to the same realization. Similarly, I don't
believe we as a community benefit by socializing a separation of
"operators" from "developers" and feel the role distinction many
attempt to strike between the two is at best vague, while at its
worst completely alienating a potential source of current and future
contributions.

What causes software to succeed in the long run is not hype,
limitless funding or even technical superiority, it's the size and
connectedness of its community of volunteers and users who invest
themselves and their personal time. The work we're doing now is
great, don't get me wrong, but for it to survive into the next
decade and beyond we need to focus more on building a close-knit
community of interested contributors even if it's not in the best
interests of industry pundits or vendor product roadmaps.

OpenStack is people. If we lose sight of that, it's over.
-- 
Jeremy Stanley


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

[openstack-dev] TC Candidacy

2016-09-29 Thread Clark Boylan 
I am standing as a candidate for a seat on the OpenStack Technical
Committee.

I have worked with OpenStack since the Diablo days and have done it full
time since joining the OpenStack Infrastructure team during the Folsom
cycle. During this time I have been an OpenStack developer, operator,
and user.

During the Newton cycle the TC began to work on community wide goals. I
agree with Doug and others that this is a very important step for the TC
and OpenStack to take. We should be able to collaborate on and solve
large scale issues that affect our community.

That said, I recognize that at the end of the day someone has to be
making these changes. I have previously been involved in many community
wide changes including parallelized unittesting, ElasticSearch and
elastic-recheck, multinode testing, and most recently running our tests
with TLS enabled. I know how difficult changes like this can be. Getting
the critical mass of interest needed for reviews to happen and debugging
when things go wrong can be very difficult. If I am elected to the TC my
mission will be to ensure these goals get the visibility required to be
successful, and that we actually work together to achieve these goals as
a community.

As an individual one of the best things about OpenStack for me is that I
get to develop and use Free Software that solves real world problems for
both myself and others. I think the best way for us to continue to do
this is by working together to solve the hard technical problems we
face. Let's make it happen.

Thank you,
Clark

https://review.openstack.org/379853

__
OpenStack Development Mailing 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] TC candidacy

2016-09-29 Thread Monty Taylor 
On 09/29/2016 06:14 PM, Clint Byrum wrote:
> https://review.openstack.org/379850
> 
> Let's make OpenStack great again.
> 
> If you don't know me, I'm very good. The code and designs I make
> are tremendous, and I intend to contribute to the TC bigly. The other
> candidates are sad, and they want OpenStack to be a third world project,
> no good.
> 
> OpenStack, could be the greatest cloud in the history of clouds, but to
> get there, you need me, to make sure our clouds are the greatest. We
> need to test the clouds, I'm talking about EXTREME cloud vetting,
> EXTREME cloud vetting. You know the other TC's are laughing at us,
> because we don't have such a great TC.
> 
> The biggest problem we have is people rewriting parts of OpenStack in Go.
> They're bringing threads, they're compiled, with errors handled at the
> point of return, and some of them, I assume, are good programmers. So
> when I'm elected to the TC, I will build a wall, and make Go pay for it.
> 
> ...
> 
> Ok if you're still reading and you don't take things too seriously,
> then hello. I'm Clint Byrum, known as "SpamapS" on IRC, and I want to
> serve you on the OpenStack Technical Committee. You may recognize me
> from various scalability and deployment discussions.
> 
> OpenStack has a number of challenges that face it in the immediate. There
> is a crisis of identity that we're only just now wrapping our arms
> around, and a question about whether or not this should be something
> decided at a centralized level by the TC or not. Are we a toobox? Are
> we a product? Can we be both?  These are real things, and the TC should
> debate them. However, I don't think the TC should force the community to
> do anything it doesn't want to do as a whole. If the community really
> wants to end the big tent, we should listen, inform, and debate, and
> decide whether or not we think it is in the best interest to do so based
> on our own expertise, the experience thus far, and a plan to go forward.
> 
> It is my personal belief that the big tent has largely been a success
> for OpenStack project teams, but created a problem of confusion that we
> should resolve. The recent efforts to more clearly define OpenStack have
> been positive, and I would like to help the TC continue down that road.
> 
> In fact, I have recently started an Architecture Working Group to help
> define and shape what OpenStack is at a technical design level. Whether
> pieces have been evolved apart from one another, or specifically designed
> and built to spec, OpenStack hasn't done a good job of writing some
> of those things down. I believe the Architecture Working Group will
> be capable of improving that, and I want the TC to have some of that
> influence built in.
> 
> So, if you want to see more design, consensus building, and an eye for
> scaling on the TC, then please consider casting a vote for me.

I nominate this email to be the best email ever sent to an OpenStack
list. In fact, I think we should replace the entire TC with this email.
This email shall be our leader and I, for one, welcome it gladly.

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

[openstack-dev] TC candidacy

2016-09-29 Thread Clint Byrum 
https://review.openstack.org/379850

Let's make OpenStack great again.

If you don't know me, I'm very good. The code and designs I make
are tremendous, and I intend to contribute to the TC bigly. The other
candidates are sad, and they want OpenStack to be a third world project,
no good.

OpenStack, could be the greatest cloud in the history of clouds, but to
get there, you need me, to make sure our clouds are the greatest. We
need to test the clouds, I'm talking about EXTREME cloud vetting,
EXTREME cloud vetting. You know the other TC's are laughing at us,
because we don't have such a great TC.

The biggest problem we have is people rewriting parts of OpenStack in Go.
They're bringing threads, they're compiled, with errors handled at the
point of return, and some of them, I assume, are good programmers. So
when I'm elected to the TC, I will build a wall, and make Go pay for it.

...

Ok if you're still reading and you don't take things too seriously,
then hello. I'm Clint Byrum, known as "SpamapS" on IRC, and I want to
serve you on the OpenStack Technical Committee. You may recognize me
from various scalability and deployment discussions.

OpenStack has a number of challenges that face it in the immediate. There
is a crisis of identity that we're only just now wrapping our arms
around, and a question about whether or not this should be something
decided at a centralized level by the TC or not. Are we a toobox? Are
we a product? Can we be both?  These are real things, and the TC should
debate them. However, I don't think the TC should force the community to
do anything it doesn't want to do as a whole. If the community really
wants to end the big tent, we should listen, inform, and debate, and
decide whether or not we think it is in the best interest to do so based
on our own expertise, the experience thus far, and a plan to go forward.

It is my personal belief that the big tent has largely been a success
for OpenStack project teams, but created a problem of confusion that we
should resolve. The recent efforts to more clearly define OpenStack have
been positive, and I would like to help the TC continue down that road.

In fact, I have recently started an Architecture Working Group to help
define and shape what OpenStack is at a technical design level. Whether
pieces have been evolved apart from one another, or specifically designed
and built to spec, OpenStack hasn't done a good job of writing some
of those things down. I believe the Architecture Working Group will
be capable of improving that, and I want the TC to have some of that
influence built in.

So, if you want to see more design, consensus building, and an eye for
scaling on the TC, then please consider casting a vote for me.

Thank you.

https://review.openstack.org/379850

__
OpenStack Development Mailing 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] TC candidacy

2016-09-29 Thread gordon chung 


On 29/09/16 04:35 PM, John Dickinson wrote:
>
> I am concerned that there is a current focus on preserving the status
> quo. There's focus on policies and rules instead of use cases; there's
> focus on conformity instead of innovation; there's focus on forced
> prioritization instead of inclusivity.

i fully agree with this pov. there's a sentiment among certain members 
that if you choose a path different from the norm, you are not 
"following the OpenStack way".

my question is (i guess this in theory could be ask to everyone), the 
the TC has historically been a reactive council that lets others ask for 
change and acts as the final approver (arguably, just my opinion). do 
you believe the TC should be a proactive committee that drives change? 
and if yes, to what scope? i realise the follow up is very open-end and 
vague and i apologise for this.

>
> If I am elected to the TC, I will look at every decision in the light
> of these two needs. I will not focus on codifying rules, and I will
> not focus on keeping OpenStack small and homogeneous. I will do what I
> can to help the OpenStack community increase adoption today and remain
> relevant as the industry changes.
>

yay to less codifying rules!


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-dev] TC candidacy

2016-09-29 Thread Joshua Harlow 

Howdy folks,

I'd like to submit myself as a candidate for the OpenStack TC,

The reasons why are varied (and longer than I can list here) but it
really comes to my desire to see OpenStack succeed and prosper and
exist (in whatever shape and form) going forward in a way that is
sustainable for the companies consuming *and* contributing to
OpenStack. I believe the TC as it exists helps (or can help) act as a
guiding force that ensures that sustainable future (along with
everyone involved in OpenStack).

In my honest opinion times ahead are going to be a little ‘scary'
for some as alternative tooling (such as containers and container
services) come into existence that offer similar (and yes sometimes
more uniform and better) functionality than what we have via the
diverse set of OpenStack components. I personally don't see that as
bad, but what I do see it being is a thing called 'evolution' and we
need to ensure we have a strong set of leaders that is helping ensure
our relevance (whatever it may be) going forward.

I feel we need to ask the 'hard' questions like:

- Where does the diverse set of OpenStack projects & components have
  value in this evolution?
- Is it better to align with some other community and create alliances
  (a *united* cloud nation for example) that work well for both/all?
  - Why have we been resistant to such things before? What can
we do better going forward...
- Are we learning from from operator difficulties, distributed system
  best practices (and other successful large scale distributed systems)
  so that we can architect and develop smart & sustainable solutions
  that *out of  the box* have zero to no operational difficulties?
- How do we get there (while still keeping our own ship afloat)?
- And more...

This may involve some changes in how our community operates and the
outreach to other communities that are becoming more popular and
widely used (and yes we may even need to slim down a little). I
personally feel it is the job of TC leadership to help guide our
community in this regard (and to make it a goal of *all* folks in our
community to do outreach, to produce great & innovative code and
products and projects that can be valuable beyond 'just being useful
in OpenStack').

Because one thing evolution has shown is that if we don't try to
evolve (and this evolution may be uncomfortable for some) that we
*may* (there's no fate but what we make) quickly become obsolete. So
instead we probably need to do some really deep thinking around
various questions like 'where does the community see itself in 3-5
years'?

TLDR; I'm hoping that being on the TC with others that I can help raise
  these kinds of questions and encourage the discussion (along with
  others) that starts to ask these hard and likely uncomfortable
  questions (and hopefully we can offer a clear(er) path for the
  general community as a result). Overall I hope we as a community
  try to rally behind a sustainable future where the majority
  understands our future evolution and the majority can get behind
  it and help *all* of us get there (it’s highly likely there will
  be a minority who will likely not be in agreement, that
  IMHO is ok and natural).

Thanks for my consideration,

FYI, harlowja on IRC, feel free to find and chat with me if you want :)

-Josh

__
OpenStack Development Mailing 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][tripleo][fuel] Upcoming changes to defaults around using processor count for worker configurations

2016-09-29 Thread Alex Schultz 
Hello all,

So for many years we've been using either the service defaults
(usually python determined processor count) or the $processorcount
fact from facter in puppet for worker configuration options for the
OpenStack services.  If you are currently using the default values
provided by the puppet modules, you will be affected by this upcoming
change. After much discussion and feedback from deployers, we've
decided to change this to a default value that has a cap on it.  This
is primarily from the feedback when deploying on physical hardware
where processor counts can be 32, 48 or even 512.  These values can
lead to excessive memory consumption or errors due to connection
limits (mysql/rabbit).  As such we've come up with a new fact to that
will be used instead of $processorcount.

The new fact is called $os_workers[0]. This fact uses the
$processorcount to help weigh in on the number of workers to configure
and won't be less than 2 but is capped at 8.  The $os_workers fact
will use the larger value of either '2' or '# of processors / 4' but
will not exceed 8.  The primary goal of this is to improve the user
experience when people install services using the puppet modules and
without having to tune all of these worker values.  We plan on
implementing this for all modules as part of the Ocata cycle.  This
work will can be tracked using the os_workers-fact[1] gerrit topic.
It should be noted that we have implemented this fact in such a way
that operators are free to override it using an external fact to
provide their own values as well.  If you are currently specifying
your own values for the worker configurations in your manifests then
this change will not affect you.  If you have been relying on the
defaults and wish to continue to use the $processorcount logic, we
would recommend either implementing your own external fact[2] for this
or updating your manifests to provide $::processorcount to the workers
configuration.

As always we'd love to hear feedback on this and any other issues
people might be facing. We're always available in #puppet-openstack on
freenode or via the mailing lists.

Thanks,
-Alex


[0] https://review.openstack.org/#/c/375146/
[1] https://review.openstack.org/#/q/topic:os_workers-fact
[2] https://docs.puppet.com/facter/3.4/custom_facts.html#external-facts

__
OpenStack Development Mailing 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][Designate] Designate Newton RC2 available

2016-09-29 Thread Davanum Srinivas 
Hello everyone,

A new release candidate for Designate for the end of the Newton cycle
is available!  You can find the source code tarball at:

https://tarballs.openstack.org/designate/designate-3.0.0.0rc2.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/designate/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/designate/+filebug

and tag it *newton-rc-potential* to bring it to the Designate release
crew's attention.

Thanks,
Dims

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

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

[openstack-dev] [release][Nova] Nova Newton RC2 available

2016-09-29 Thread Davanum Srinivas 
Hello everyone,

A new release candidate for Nova for the end of the Newton cycle
is available!  You can find the source code tarball at:

https://tarballs.openstack.org/nova/nova-14.0.0.0rc2.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/nova/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/nova/+filebug

and tag it *newton-rc-potential* to bring it to the Nova release
crew's attention.

Thanks,
Dims

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

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

Re: [openstack-dev] [Kolla] Deprecation Policies (related to Heka)

2016-09-29 Thread Steven Dake (stdake) 
Michal,

I didn’t say we had to run two parallel implementations at the same time to be 
compliant with this project maturity tag.  We have to maintain it in the 
release for 3 months until we switch to something else if our intent is to 
switch to something else (at 3 months + 1 picosecond ☺.  Reading into the 
rationale into this, I believe it is to help out all projects provide a 
feasible backport mechanism to also be complaint with the follows stable policy 
project maturity tag.

The fact that Heka is an internal service Kolla uses is not a meaningful 
argument for avoiding the deprecation policy because operators may rely on our 
internal infrastructure already (e.g. they built their own containers with heka 
logging) and need a migration path for what is next.

Operators need time to move to a new component just as Kolla does.

Regards
-steve


From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, September 29, 2016 at 8:59 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [Kolla] Deprecation Policies (related to Heka)

notification = of course
relase note with information and upgrade info = of course
1 full release of supporting both heka and alternative = not so much

On 29 September 2016 at 10:54, Swapnil Kulkarni (coolsvap)
> wrote:
On Sep 29, 2016 3:06 PM, "Christian Berendt"
> wrote:

> On 29 Sep 2016, at 06:26, Steven Dake (stdake) 
> > wrote:
>
> If you have a different parsing of the deprecation policy, feel free to
> chime in.

Heka is only used as an internal component of Kolla and is not provided as
a service for the operators. It should be sufficient to replace Heka by
something else without deprecating it.

Christian.

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


Kolla is an operator tool and there are multiple tools only internal to
deployment. This does not mean we can deprecate tools without operator being
notified about it.


__
OpenStack Development Mailing 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] TC candidacy

2016-09-29 Thread John Dickinson 
I am throwing my hat into the ring for the TC election.

I've been a part of OpenStack since it started. I've seen it grow from
a few dozen people into the very large community we have today. During
the past 6 years, I've seen controversial topics come and go and the
community grow and adapt. I've also seen OpenStack respond in knee-
jerk fashion to new ideas that challenge the status quo.

I am concerned that there is a current focus on preserving the status
quo. There's focus on policies and rules instead of use cases; there's
focus on conformity instead of innovation; there's focus on forced
prioritization instead of inclusivity.

The primary things OpenStack should be focused on are increased
adoption today and continued relevance in the next five years.

We have a lovely community today, and we attract thousands to our
semi-annual conference. I love seeing companies, big and small, come
share their stories of how they're using OpenStack. It's great to hear
from them over time and see how their use of OpenStack changes and
grows. However, I'm concerned that we keep seeing mostly the same
people, the same companies, and the same sponsors show up to each
event. I'm concerned that, outside of our community bubble, OpenStack
is still largely unknown and little-used. In order to increase
adoption, the TC must look at the use cases we are serving. We must
realize where we are falling short in solving for current use cases,
and we must encourage growth in new use cases which we don't yet
support. To better-solve current use cases, I would like to see more
emphasis on SDK development (across many languages) and the creation
of governance tags identifying projects that are independently
deployable for specific use cases. To encourage solving more use cases
within OpenStack, I would like to see less requirements placed on new
projects and more clear communication about the various ways new
projects can join OpenStack.

In order to stay relevant in the technical world, the OpenStack TC
must figure out how the community itself can foster new ideas and grow
them within OpenStack. We should not ask new projects to split into
OpenStack and non-OpenStack pieces before joining. We should not ask
existing OpenStack contributors to go elsewhere to develop their
ideas. We must inclusively welcome new contributors, new projects, and
new ideas. Sometimes these new ideas require significant effort to
adopt, but I will encourage the TC to take on the challenge.

If I am elected to the TC, I will look at every decision in the light
of these two needs. I will not focus on codifying rules, and I will
not focus on keeping OpenStack small and homogeneous. I will do what I
can to help the OpenStack community increase adoption today and remain
relevant as the industry changes.

I appreciate your vote for me to the TC in this election.

--John

notmyname on IRC

elections patch: https://review.openstack.org/379814




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

[openstack-dev] TC candidacy

2016-09-29 Thread Steve Martinelli 
I’d like to also toss my name into the ring. I’m announcing my candidacy
for a
position on the OpenStack Technical Committee.

-- About me
I have served as the Keystone PTL for the Mitaka and Newton cycles, and will
again serve as the PTL for the Ocata cycle. I’ve also contributed heavily to
python-openstackclient in it’s early days, where I am remain an active
core-reviewer. I am also a core member in a few Oslo projects (oslo.cache
and
oslo.policy) and OpenStackClient projects (os-client-config and cliff). I’ve
contributed reviews and patches to many repos over my time -- ranging from
devstack, infra, python-*client, openstack-manuals, you name it!

I’ve been contributing to OpenStack since early 2013, as part of a small
group
of IBMers dedicated to working entirely upstream. I can happily say that I
continue this same role today. Most of my work on OpenStack has been focused
on making Keystone and OpenStack more enterprise ready while trying to
improve
usability and manageability of OpenStack.

-- Bracing for the Big Crunch
The explosive growth that occurred as a result of the Big Tent was expected
and
phenomenal. I believe the decision brought great innovation, accelerated
adoption at a time when it was needed, and allowed competing projects to
co-exist. A natural reaction to such growth is unfortunately, a leveling
off or
contraction phase. We already saw hints of this in the last round of PTL
elections [1] . I believe this trend will continue. This is OK and
completely
natural, the strongest projects will continue to survive. We have seen this
pattern in many other technologies. The TC should be prepared for this
eventuality, and set minimum standards that projects should meet (not unlike
what is proposed by the OpenStack-wide goals).

-- Organizing the Big Tent
The big tent lumped all the projects together in an unorganized way, take a
quick look at the list [2]. I believe this has been a large source of
confusion
to the end consumer. There are projects that a consumer would never deploy
(docs, infra, etc), there are projects that a consumer will use one of
(openstack-ansible, puppet, chef, etc), these logical groupings go on. We
don't
provide enough guidance on which sets of projects are good groupings to
consider using together. It is critical for the OpenStack community to
reduce
the adoption pains experienced by our consumers. Everything can live in the
big tent, but let’s make the big tent a bit more organized.

-- Let’s get Opinionated
I also believe OpenStack needs to be a bit more opinionated. We have a bad
habit of trying to please everyone, and I’d like for that to stop. We’ll
end up
pleasing nobody at all. We don’t need more optional features, we need to pay
down technical debt. We need to focus on OpenStack-wide goals that create a
more consistent project that is focused and more consumable; improving the
quality of OpenStack as a whole. This is something I will be enforcing in
the
Ocata cycle for Keystone, and I encourage others to do the same.

-- Creating OpenStack-wide goals
OpenStack is mature, it’s now 6 years old. It’s (past?) time we tackle the
hard
issues at an OpenStack-wide level. I'd like to see the TC focus on goals
that
not only increase adoption of OpenStack but also make OpenStack easier to
manage and help to improve our ability to have new consumers of OpenStack
stick
with OpenStack. I believe the key to this success is to work closely with
our
operator friends. Having the Project Team Gathering (PTG) [3] will help get
the
right folks in the room to talk about the important issues.

Working on OpenStack has brought me a great deal of fun and joy. I look
forward
to working on OpenStack in any capacity and would be honored to be on the
TC.

Thanks for reading,
Steve

Stackalytics: http://stackalytics.com/?user_id=stevemar
Foundation Profile: https://www.openstack.org/community/members/profile/8430
Freenode: stevemar
Twitter: https://twitter.com/stevebot

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104170.html
[1] https://governance.openstack.org/reference/projects/index.html
[2] https://www.openstack.org/ptg/

I've also submitted the required patch to the election repo:
https://review.openstack.org/#/c/379799/
__
OpenStack Development Mailing 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-ansible] Blueprint discussion

2016-09-29 Thread Michael Gugino 
"Testing: call tempest function from tox"

https://blueprints.launchpad.net/openstack-ansible/+spec/testing-direct-tem
pest


I filed this blueprint for a potential enhance to our functional testing.

Any thoughts OSA team?


Michael Gugino



On 9/29/16, 1:38 PM, "Davanum Srinivas"  wrote:

>Hello everyone,
>
>The release candidate for OpenStack-Ansible for the end of the Newton
>cycle is available! You can find the details at:
>
>https://releases.openstack.org/newton/index.html#newton-openstack-ansible
>
>Unless release-critical issues are found that warrant a release
>candidate respin, this RC2 will be formally released as the final
>Newton release on 6 October. You are therefore strongly encouraged to
>test these!
>
>If you find an issue that could be considered release-critical, please
>file it at:
>
>https://bugs.launchpad.net/openstack-ansible/+filebug
>
>and tag it *newton-rc-potential* to bring it to the OpenStack-Ansible
>release crew's attention.
>
>Thanks,
>Dims
>
>-- 
>Davanum Srinivas :: https://twitter.com/dims
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

This email and any files transmitted with it are confidential and intended 
solely for the individual or entity to whom they are addressed. If you have 
received this email in error destroy it immediately. *** Walmart Confidential 
***

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

Re: [openstack-dev] SRIOV-port refused to bind

2016-09-29 Thread Murali B 
Hi Lenny Verkhovsky,

Thank you for your response.

I am using the Mitaka version of openstack. I followed the
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking and set
the "intel_iommu=on".

Here is the output for the VF's config

root@A1-22932-compute1:~# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.2.0-42-generic
root=UUID=ff1b5507-414f-4c96-9fbe-cc3c02c682fc ro intel_iommu=on
igbe.max_vfs=2 pci=assign-busses quiet splash vt.handoff=7

root@A1-22932-compute1:~# lspci | grep Ether
03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network
Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network
Connection (rev 01)
04:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev
01)
04:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev
01)
04:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev
01)
04:10.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev
01)
08:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
09:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection

root@A1-22932-compute1:~# ls /sys/bus/pci/devices/\:04\:10.0/net/
eth1


Please find the config here http://pastebin.com/Tfaez4Je

here are the logs on controller http://pastebin.com/e3s1LaMw

here is the nova-compute log http://pastebin.com/qRzG6Tif

Thanks
-Murali
__
OpenStack Development Mailing 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] [release][searchlight] RC3 available (was: searchlight Newton RC2 available)

2016-09-29 Thread Davanum Srinivas 
A translation review trickled in late for searchlight-ui. So we cut a RC3:
https://tarballs.openstack.org/searchlight-ui/searchlight-ui-1.0.0.0rc3.tar.gz

Thanks,
Dims


On Thu, Sep 29, 2016 at 11:09 AM, Davanum Srinivas  wrote:
> Hello everyone,
>
> The release candidate for searchlight for the end of the Newton cycle
> is available! You can find the RC2 source code tarball at:
>
> https://tarballs.openstack.org/searchlight/searchlight-1.0.0.0rc2.tar.gz
> https://tarballs.openstack.org/searchlight-ui/searchlight-ui-1.0.0.0rc2.tar.gz
>
> Unless release-critical issues are found that warrant a release
> candidate respin, this RC2 will be formally released as the final
> Newton release on 6 October. You are therefore strongly encouraged to
> test and validate this tarball!
>
> Alternatively, you can directly test the stable/newton release branch at:
>
> http://git.openstack.org/cgit/openstack/searchlight/log/?h=stable/newton
>
> If you find an issue that could be considered release-critical, please
> file it at:
>
> https://bugs.launchpad.net/searchlight/+filebug
>
> and tag it *newton-rc-potential* to bring it to the searchlight
> release crew's attention.
>
> Note that the "master" branch of searchlight is now open for Ocata
> development, and feature freeze restrictions no longer apply there!
>
> Thanks,
> Dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims



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

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

[openstack-dev] [new][documentation] os-api-ref 1.1.0 release

2016-09-29 Thread no-reply 
We are overjoyed to announce the release of:

os-api-ref 1.1.0: Sphinx Extensions to support API reference sites in
OpenStack

With source available at:

http://git.openstack.org/cgit/openstack/os-api-ref

For more details, please see below.

Changes in os-api-ref 1.0.0..1.1.0
--

533589c Sync with global-requirements
b494f29 Update homepage with developer documentation page
22bf5f2 Adds an example http-status.yaml file and updates doc
34a7f1b Use beautifulsoup4 instead of bs4 in test-requirements.txt
a22ecf2 remove padding-top for endpoint-container
bab707c Adds more info to the README to instruct authors
8d31f26 Expand width of API Site
f9241b1 Add color for COPY label


Diffstat (except docs and test files)
-

README.rst | 69 ++
os_api_ref/assets/api-site.css | 11 ++-
requirements.txt   |  9 +++---
setup.cfg  |  2 +-
setup.py   |  2 +-
test-requirements.txt  | 13 
8 files changed, 161 insertions(+), 48 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index e7e1e2c..a61c008 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5,5 +5,4 @@
-pbr>=1.6
-PyYAML>=3.1.0
-docutils
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2
-openstackdocstheme>=1.4.0  # Apache-2.0
+pbr>=1.6 # Apache-2.0
+PyYAML>=3.1.0 # MIT
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+openstackdocstheme>=1.5.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 251cd52..390e56e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7,6 +7,5 @@ hacking<0.11,>=0.10.0
-coverage>=3.6
-python-subunit>=0.0.18
-oslosphinx>=2.5.0 # Apache-2.0
-testrepository>=0.0.18
-testtools>=1.4.0
-
+coverage>=3.6 # Apache-2.0
+python-subunit>=0.0.18 # Apache-2.0/BSD
+oslosphinx>=4.7.0 # Apache-2.0
+testrepository>=0.0.18 # Apache-2.0/BSD
+testtools>=1.4.0 # MIT
@@ -14 +13 @@ sphinx-testing
-bs4
+beautifulsoup4 # MIT



__
OpenStack Development Mailing 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] Release countdown for week R-0, 3-7 Oct

2016-09-29 Thread Doug Hellmann 
Focus
-

This is the final release week. We're almost there!

Most project teams should be preparing for the summit in Barcelona.

General Notes
-

The release management team will tag the final Newton release on 6
October (project teams do not need to take any action). We will
re-tag the commit used for the most recent release candidate listed
in openstack/releases, using a final version number that drops the
"rc" segment.  Projects not following the milestone model will not
be re-tagged. Cycle-trailing projects will be skipped until the trailing
deadline.

Backports should be restricted to last-minute critical fixes to
avoid having to publish more release candidates than necessary.

Release Actions
---

Projects not following the milestone-based release model who want
stable/newton branches created should talk to the release team about
their needs. Remember, we always create stable branches from tagged
commits, so we need the tag to exist before we branch. We will NOT
be creating branches without communicating with the PTL or release
liaison for the team.

Unbranched projects include:

  * cloudkitty
  * fuel
  * monasca
  * openstackansible
  * senlin
  * solum
  * tripleo

PTLs, this is a good time to clean up core team memberships and
remove inactive members.

Important Dates
---

Newton Final Release, 6 Oct.

Newton cycle-trailing deadline, 20 Oct.

Ocata Design Summit, 24-28 Oct.

Newton release schedule: http://releases.openstack.org/newton/schedule.html

Ocata release schedule: https://releases.openstack.org/ocata/schedule.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] [puppet] Proposing David Moreau Simard part of Puppet OpenStack CI core team

2016-09-29 Thread David Moreau Simard 
Hey,

Great -- thanks everyone. Let's keep on rocking.
Sometimes, it works outside of Devstack. Let's keep it that way :)

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Thu, Sep 29, 2016 at 12:33 PM, Emilien Macchi  wrote:
> Great, I proposed the change here: https://review.openstack.org/#/c/379583/
>
> Thanks for your feedback!
>
> On Thu, Sep 29, 2016 at 12:18 PM, Alex Schultz  wrote:
>> +1.  I think it would be beneficial to get more eyes on our testing as well
>>
>> On Wed, Sep 28, 2016 at 10:15 AM, Iury Gregory  wrote:
>>> +1 from me, David is doing an awesome job in p-o-i =)
>>>
>>> 2016-09-28 13:08 GMT-03:00 Rich Megginson :

 On 09/28/2016 10:06 AM, Emilien Macchi wrote:
>
> Until now, we had no specific team for dealing with Puppet OpenStack
> CI (aka openstack/puppet-openstack-integration project).
> But we have noticed that David was doing consistent work to contribute
> to Puppet OpenStack CI by adding more coverage, but also helping when
> things are broken.
> David is always here to help us to make testing better.
>
> David is working on RDO Infra and re-use Puppet OpenStack CI tooling
> to test OpenStack, so he has a perfect knowledge at how Puppet
> OpenStack CI is working.
>
> I would like to request feedback from our community about creating
> this new Gerrit group (where we would include existing Puppet
> OpenStack core groups into it), and also include David into it.


 +1 for David, whatever he's working on

>
> Thanks,




 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> --
>>>
>>> ~
>>> Att[]'s
>>> Iury Gregory Melo Ferreira
>>> Master student in Computer Science at UFCG
>>> E-mail:  iurygreg...@gmail.com
>>> ~
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing 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][openstack-ansible] OpenStack-Ansible Newton RC2 available

2016-09-29 Thread Davanum Srinivas 
Hello everyone,

The release candidate for OpenStack-Ansible for the end of the Newton
cycle is available! You can find the details at:

https://releases.openstack.org/newton/index.html#newton-openstack-ansible

Unless release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as the final
Newton release on 6 October. You are therefore strongly encouraged to
test these!

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/openstack-ansible/+filebug

and tag it *newton-rc-potential* to bring it to the OpenStack-Ansible
release crew's attention.

Thanks,
Dims

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

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

Re: [openstack-dev] [release][tripleo] Tripleo Newton RC2 available

2016-09-29 Thread Emilien Macchi 
On Thu, Sep 29, 2016 at 1:10 PM, Davanum Srinivas  wrote:
> Hello everyone,
>
> The release candidate for Tripleo for the end of the Newton cycle is
> available! You can find the RC2 source code tarballs at:
>
> https://tarballs.openstack.org/instack-undercloud/instack-undercloud-5.0.0.0rc2.tar.gz
> https://tarballs.openstack.org/puppet-tripleo/puppet-tripleo-5.2.0.tar.gz
> https://tarballs.openstack.org/python-tripleoclient/python-tripleoclient-5.2.0.tar.gz
> https://tarballs.openstack.org/tripleo-common/tripleo-common-5.2.0.tar.gz
> https://tarballs.openstack.org/tripleo-heat-templates/tripleo-heat-templates-5.0.0.0rc2.tar.gz
> https://tarballs.openstack.org/tripleo-image-elements/tripleo-image-elements-5.0.0.0rc2.tar.gz
> https://tarballs.openstack.org/tripleo-puppet-elements/tripleo-puppet-elements-5.0.0.0rc2.tar.gz
> https://tarballs.openstack.org/tripleo-ui/tripleo-ui-1.0.3.tar.gz
> https://tarballs.openstack.org/os-collect-config/os-collect-config-5.0.0.0rc2.tar.gz
> https://tarballs.openstack.org/os-net-config/os-net-config-5.0.0.0rc2.tar.gz
>
> Unless release-critical issues are found that warrant a release
> candidate respin, this RC2 will be formally released as the final
> Newton release on 6 October. You are therefore strongly encouraged to
> test and validate these tarballs!

Thanks for your help on release management Dims!

> If you find an issue that could be considered release-critical, please
> file it at:
>
> https://bugs.launchpad.net/tripleo/+filebug
>
> and tag it *newton-rc-potential* to bring it to the Tripleo release
> crew's attention.

I went ahead and moved all remaining RC2 bugs into ocata-1 with the tag:
https://bugs.launchpad.net/tripleo/+bugs?field.tag=newton-backport-potential

If you think a bug needs to be backported into Newton before official
release date, please add the tag so we can more easily triage them.

Thanks,

> Thanks,
> Dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [release][tripleo] Tripleo Newton RC2 available

2016-09-29 Thread Davanum Srinivas 
Hello everyone,

The release candidate for Tripleo for the end of the Newton cycle is
available! You can find the RC2 source code tarballs at:

https://tarballs.openstack.org/instack-undercloud/instack-undercloud-5.0.0.0rc2.tar.gz
https://tarballs.openstack.org/puppet-tripleo/puppet-tripleo-5.2.0.tar.gz
https://tarballs.openstack.org/python-tripleoclient/python-tripleoclient-5.2.0.tar.gz
https://tarballs.openstack.org/tripleo-common/tripleo-common-5.2.0.tar.gz
https://tarballs.openstack.org/tripleo-heat-templates/tripleo-heat-templates-5.0.0.0rc2.tar.gz
https://tarballs.openstack.org/tripleo-image-elements/tripleo-image-elements-5.0.0.0rc2.tar.gz
https://tarballs.openstack.org/tripleo-puppet-elements/tripleo-puppet-elements-5.0.0.0rc2.tar.gz
https://tarballs.openstack.org/tripleo-ui/tripleo-ui-1.0.3.tar.gz
https://tarballs.openstack.org/os-collect-config/os-collect-config-5.0.0.0rc2.tar.gz
https://tarballs.openstack.org/os-net-config/os-net-config-5.0.0.0rc2.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as the final
Newton release on 6 October. You are therefore strongly encouraged to
test and validate these tarballs!

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/tripleo/+filebug

and tag it *newton-rc-potential* to bring it to the Tripleo release
crew's attention.

Thanks,
Dims

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

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

Re: [openstack-dev] [all][oslo] Parse ISO8601 (open) time intervals

2016-09-29 Thread Julien Danjou 
On Tue, Sep 27 2016, milanisko k wrote:

> I'd like to ask whether other projects need to parse time intervals and/or
> how do they achieve that.

We kind of do that in Gnocchi, but we do with 2 fields: one ISO8601
timestamp and a timestamp field, which we parse using pytimeparse, you
(can check gnocchi.utils.to_timespan).

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


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] [all][oslo] Parse ISO8601 (open) time intervals

2016-09-29 Thread Kevin L. Mitchell 
On Thu, 2016-09-29 at 12:07 -0400, Doug Hellmann wrote:
> Excerpts from milanisko k's message of 2016-09-29 09:48:40 +:
[snip]
> > > Doug, I'm afraid that dateutil.parser.parse doesn't support intervals
> > either: http://paste.openstack.org/show/583452/
> > Is there any interest in oslo_utils.timeutils parsing ISO8601 time
> > intervals as in [2]?
> > What do OS projects use instead especially w/r http api queries?
> 
> Have you talked with the dateutils maintainers about adding support
> there?  It would still be better to contribute to dateutil than to
> put the function in a library not meant for anyone else outside of
> OpenStack to use.

You might also want to look at the timestring library…
-- 
Kevin L. Mitchell 


signature.asc
Description: This is a digitally signed message part
__
OpenStack Development Mailing 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] Proposing David Moreau Simard part of Puppet OpenStack CI core team

2016-09-29 Thread Emilien Macchi 
Great, I proposed the change here: https://review.openstack.org/#/c/379583/

Thanks for your feedback!

On Thu, Sep 29, 2016 at 12:18 PM, Alex Schultz  wrote:
> +1.  I think it would be beneficial to get more eyes on our testing as well
>
> On Wed, Sep 28, 2016 at 10:15 AM, Iury Gregory  wrote:
>> +1 from me, David is doing an awesome job in p-o-i =)
>>
>> 2016-09-28 13:08 GMT-03:00 Rich Megginson :
>>>
>>> On 09/28/2016 10:06 AM, Emilien Macchi wrote:

 Until now, we had no specific team for dealing with Puppet OpenStack
 CI (aka openstack/puppet-openstack-integration project).
 But we have noticed that David was doing consistent work to contribute
 to Puppet OpenStack CI by adding more coverage, but also helping when
 things are broken.
 David is always here to help us to make testing better.

 David is working on RDO Infra and re-use Puppet OpenStack CI tooling
 to test OpenStack, so he has a perfect knowledge at how Puppet
 OpenStack CI is working.

 I would like to request feedback from our community about creating
 this new Gerrit group (where we would include existing Puppet
 OpenStack core groups into it), and also include David into it.
>>>
>>>
>>> +1 for David, whatever he's working on
>>>

 Thanks,
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>>
>> ~
>> Att[]'s
>> Iury Gregory Melo Ferreira
>> Master student in Computer Science at UFCG
>> E-mail:  iurygreg...@gmail.com
>> ~
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

__
OpenStack Development Mailing 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] Proposing David Moreau Simard part of Puppet OpenStack CI core team

2016-09-29 Thread Alex Schultz 
+1.  I think it would be beneficial to get more eyes on our testing as well

On Wed, Sep 28, 2016 at 10:15 AM, Iury Gregory  wrote:
> +1 from me, David is doing an awesome job in p-o-i =)
>
> 2016-09-28 13:08 GMT-03:00 Rich Megginson :
>>
>> On 09/28/2016 10:06 AM, Emilien Macchi wrote:
>>>
>>> Until now, we had no specific team for dealing with Puppet OpenStack
>>> CI (aka openstack/puppet-openstack-integration project).
>>> But we have noticed that David was doing consistent work to contribute
>>> to Puppet OpenStack CI by adding more coverage, but also helping when
>>> things are broken.
>>> David is always here to help us to make testing better.
>>>
>>> David is working on RDO Infra and re-use Puppet OpenStack CI tooling
>>> to test OpenStack, so he has a perfect knowledge at how Puppet
>>> OpenStack CI is working.
>>>
>>> I would like to request feedback from our community about creating
>>> this new Gerrit group (where we would include existing Puppet
>>> OpenStack core groups into it), and also include David into it.
>>
>>
>> +1 for David, whatever he's working on
>>
>>>
>>> Thanks,
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
>
> ~
> Att[]'s
> Iury Gregory Melo Ferreira
> Master student in Computer Science at UFCG
> E-mail:  iurygreg...@gmail.com
> ~
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Kolla] Deprecation Policies (related to Heka)

2016-09-29 Thread Swapnil Kulkarni 
On Sep 29, 2016 9:30 PM, "Michał Jastrzębski"  wrote:
>
> notification = of course
> relase note with information and upgrade info = of course
> 1 full release of supporting both heka and alternative = not so much
>
> On 29 September 2016 at 10:54, Swapnil Kulkarni (coolsvap)
>  wrote:
> > On Sep 29, 2016 3:06 PM, "Christian Berendt"
> >  wrote:
> >>
> >> > On 29 Sep 2016, at 06:26, Steven Dake (stdake) 
wrote:
> >> >
> >> > If you have a different parsing of the deprecation policy, feel free
to
> >> > chime in.
> >>
> >> Heka is only used as an internal component of Kolla and is not
provided as
> >> a service for the operators. It should be sufficient to replace Heka by
> >> something else without deprecating it.
> >>
> >> Christian.
> >>
> >>
__
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > Kolla is an operator tool and there are multiple tools only internal to
> > deployment. This does not mean we can deprecate tools without operator
being
> > notified about it.
> >
> >
> >
__
> > OpenStack Development Mailing 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

Doesn't the notification in release note be a depreciation notification for
something not available from subsequent release? If no why not?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo] Parse ISO8601 (open) time intervals

2016-09-29 Thread Doug Hellmann 
Excerpts from milanisko k's message of 2016-09-29 09:48:40 +:
> út 27. 9. 2016 v 18:05 odesílatel Doug Hellmann 
> napsal:
> 
> > Excerpts from milanisko k's message of 2016-09-27 12:30:09 +:
> > > Hello Stackers!
> > >
> > > The ironic inspector project keeps track of introspection finished_at
> > time
> > > stamps.
> > > We're just discussing how to reasonably query time ranges over the API[1]
> > > to serve matching introspection statuses to the user.
> > > Wikipedia[2] mentions the ISO8601 time interval specification (and there
> > > are open-interval extensions to that).
> > > It would be nice to be able to specify a query like :
> > >  /v1/introspection?finished_at=2016:09:27:14:17/PT1H
> > > to fetch all introspection statuses that finished within 1hour around
> > 14:17
> > > Today,
> > > or to be able to state an open-ended interval:
> > > /v1/introspection?finished_at=2016:09:27:14:17/
> > > but oslo_utils.timeutils lacks parsing support for ISO8061 time
> > intervals.
> > >
> > > I'd like to ask whether other projects need to parse time intervals
> > and/or
> > > how do they achieve that.
> > >
> > > Thanks!
> > > milan
> > >
> > > [1]
> > >
> > https://review.openstack.org/#/c/375045/3/specs/list-introspection-statuses.rst
> > > [2] https://en.wikipedia.org/wiki/ISO_8601#Time_intervals
> >
> > You may want to have a look at the dateutil library.
> > https://dateutil.readthedocs.io/en/stable/
> >
> > Doug, I'm afraid that dateutil.parser.parse doesn't support intervals
> either: http://paste.openstack.org/show/583452/
> Is there any interest in oslo_utils.timeutils parsing ISO8601 time
> intervals as in [2]?
> What do OS projects use instead especially w/r http api queries?

Have you talked with the dateutils maintainers about adding support
there?  It would still be better to contribute to dateutil than to
put the function in a library not meant for anyone else outside of
OpenStack to use.

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] [ironic] base node payload for notification

2016-09-29 Thread Tripp, Travis S 


On 9/27/16, 8:23 AM, "Jim Rollenhagen"  wrote:

On Tue, Sep 27, 2016 at 9:57 AM, Loo, Ruby  wrote:
> Hi Yuriy,
>
>
>
> Thanks for bringing this up. I'm good with your list, with the exception 
of
> driver_info and instance_info. I'm on the fence with these two. If we 
assume
> that any secrets will be bleep'd out (configdrives won't be there), is 
there
> other information there that might be useful? I'm not totally sure what
> notifications will be used for; it is somewhat hard to assume.
>
>
>
> I suppose we could look at it this way, since you and Mario are fine 
without
> those two. If no one speaks up wanting them, then we'll do as you propose,
> and not expose those two fields.

On 9/27/16, 8:23 AM, "Jim Rollenhagen"  wrote:

> 2) Searching things with searchlight - the obvious case for driver_info 
is "find
> all nodes with BMCs on the 10.100.0.0/24 network" or similar things.

We’ve done some usability studies on searchlight UI and one of the most useful 
use cases that has emerged is the ability to search based on IP addresses / 
ranges / cidr (all supported by the underlying elastic search engine). In most 
searchlight plugins (e.g. glance / nova), we’ve indexed any data visible via 
the API. For sensitive fields, you can set them to be admin only (or use other 
filtering abilities in the plugin).

In addition, if you guys have any interest in doing some aggregation like 
abilities in addition to search, you can do that using the searchlight 
indexing.  For example, counts, averages, various statistics can be done via 
the aggregation API exposed up via searchlight [0] of the ElasticSearch 
aggregation API [1]. For example, one simple use case we’ve used it for is to 
get a count of images & flavors used across nova instances or hosts.

 [0] 
http://developer.openstack.org/api-ref/search/?expanded=create-an-aggregated-search-detail
 [1] 
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations.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] [tripleo] Getting the UI to talk with Undercloud API service endpoints

2016-09-29 Thread Dan Trainor 
Hi, Juan -

Actually, the third option is also not an option in the current undercloud
> setup, since making the services listen in 0.0.0.0 will break HAProxy. So
> when you're deploying with TLS things will break since we use HAProxy to
> terminate TLS connections.
>

Ah, that's correct, isn't it.



> On the other hand, we also don't want services to listen on 0.0.0.0 since
> that would become a security concern. We should instead be blocking
> everything we don't need to have exposed (as we've done with the
> undercloud's database and rabbitmq).
>

I don't disagree that we want to focus on least privilege, but we do have
documentation that talks about how to deal with this.  I addressed this in
my previous message, even if only to illustrate my understanding that there
would be concerns around this.  See more comments about this down below...


>
> Now, as we're trying to move to have more convergence between the
> undercloud and the overcloud (trying to deploy the undercloud via heat
> also, as Dan Prince has mentioned), I think some aspecs of this will bring
> a solution to this problem. for instance, just like we already do in the
> overcloud, we could have the undercloud's HAProxy always terminate the
> endpoints, which I'm attempting with these two patches:
> https://review.openstack.org/#/c/360366  https://review.openstack.org/#
> /c/360368 . Furthermore, we could have the public endpoints in HAProxy
> listen on a separate network that's accessible externally, also as we do in
> the overcloud. That way we don't need to change the actual interfaces the
> services are listening on, and rely on HAProxy, getting closer to how we do
> things in the overcloud. It seems to me that it would help solve the
> problem.
>

I like that idea.  Though, this effectively shifts the process of having
these services themselves listen on different IPs/ports and offloads that
to HAProxy.  Whatever security concerns we have with opening up network
communications would still exist, but I think that would be more broadly
accepted considering these connections are now managed by HAProxy which
*only* listens for SSL connections.

Another challenge with isolating this traffic on a separate network is that
we introduce a new dependency that's going to take administrative time to
set up and configure outside of OpenStack - do we really want that?

Thanks!
-dant




>
> On Wed, Sep 28, 2016 at 7:24 PM, Dan Trainor  wrote:
>
>> Hi -
>>
>> I want to bring up a subject that needs a little more attention.  There
>> are a few ideas floating around but it's important that we get this done
>> right.
>>
>> UI is unique in the sense that it operates almost entirely in a browser,
>> talking directly to service API endpoints which it either figures out from
>> they Keystone service catalog as using the publicURL endpoint for each
>> service, or by specifying these API endpoints in a configuration file.
>> Though overriding the API endpoints in the UI's local configuration file is
>> an option that's available, I understand that we want to move towards
>> relying exclusively on Keystone for accurate and correct endpoint
>> configuration.
>>
>> Right now, all of the service API endpoints that UI needs to talk with
>> are only listening on the ctlplane network.
>>
>> We've had several iterations of testing and development of the UI over
>> time and as a result of that, three different solutions that work -
>> depending on the exact circumstances - have been created which all can
>> achieve the same goal of allowing the UI to talk to these endpoints:
>>
>> - Local SSH port tunneling of the required ports that UI talks to, from
>> the system running the UI to the Undercloud, and configuring the UI to talk
>> to localhost:. This method "works", but it's not a solution we can
>> recommend
>> - Making the interface on which these services already listen on - the
>> ctlplane network - routable.  Again, this method "works", but we treat this
>> interface in a very special manner on purpose, not the least of which
>> because of it's ability to facilitate pxebooting
>> - Change the public endpoints in the Keystone catalog to be that of the
>> existing external, routable interface of the Undercloud for each service
>> required by the UI.  This also requires configuring each service that UI
>> needs to talk with, to listen on the existing, external, routable interface
>> on the Undercloud.  Some services support a list of interfaces and IPs to
>> listen on; others require exactly one argument, in which case the address
>> of 0.0.0.0 would need to be used
>>
>> According to the API Endpoint Configuration Recommendation guide[1], the
>> third option seems most viable and one that we can recommend.  The document
>> briefly describes the security implications of having these services open
>> on a public interface but recommends the use of a stringent network policy
>> - something we're used to recommending and helping with.  The

Re: [openstack-dev] [Kolla] Deprecation Policies (related to Heka)

2016-09-29 Thread Michał Jastrzębski 
notification = of course
relase note with information and upgrade info = of course
1 full release of supporting both heka and alternative = not so much

On 29 September 2016 at 10:54, Swapnil Kulkarni (coolsvap)
 wrote:
> On Sep 29, 2016 3:06 PM, "Christian Berendt"
>  wrote:
>>
>> > On 29 Sep 2016, at 06:26, Steven Dake (stdake)  wrote:
>> >
>> > If you have a different parsing of the deprecation policy, feel free to
>> > chime in.
>>
>> Heka is only used as an internal component of Kolla and is not provided as
>> a service for the operators. It should be sufficient to replace Heka by
>> something else without deprecating it.
>>
>> Christian.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Kolla is an operator tool and there are multiple tools only internal to
> deployment. This does not mean we can deprecate tools without operator being
> notified about it.
>
>
> __
> OpenStack Development Mailing 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] [Fuel] Weekly meeting for 9/29 is canceled

2016-09-29 Thread Andrew Woodward 
The agenda [0] is empty again this week so the meeting is closed, see you
again next week

[0] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 
Andrew Woodward
Mirantis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] Deprecation Policies (related to Heka)

2016-09-29 Thread Swapnil Kulkarni (coolsvap) 
On Sep 29, 2016 3:06 PM, "Christian Berendt" 
wrote:
>
> > On 29 Sep 2016, at 06:26, Steven Dake (stdake)  wrote:
> >
> > If you have a different parsing of the deprecation policy, feel free to
chime in.
>
> Heka is only used as an internal component of Kolla and is not provided
as a service for the operators. It should be sufficient to replace Heka by
something else without deprecating it.
>
> Christian.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Kolla is an operator tool and there are multiple tools only internal to
deployment. This does not mean we can deprecate tools without operator
being notified about it.
__
OpenStack Development Mailing 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] Release update - RC2 status & RC3

2016-09-29 Thread Emilien Macchi 
So I requested for TripleO RC2 release:
https://review.openstack.org/#/c/378620/

Once this patch will merge, we'll have stable/newton on:
- openstack/instack-undercloud
- openstack/puppet-tripleo
- openstack/tripleo-common
- openstack/tripleo-heat-templates
- openstack/tripleo-puppet-elements
- openstack/tripleo-ui

I would ask our group to carefully backport things into stable/newton
if it fix a Critical or High bug reported in Launchpad.

Tomorrow, I'll take care of moving remaining bugs to ocata-1 with
backport-potential tag.

Thanks,

On Wed, Sep 28, 2016 at 11:38 AM, Emilien Macchi  wrote:
> Greetings,
>
> We have done incredible work lately to fix a maximum of bugs in such a
> short time:
> https://review.openstack.org/#/q/topic:tripleo/rc2
>
> At this time, we still have 16 bugs open:
>
> https://launchpad.net/tripleo/+milestone/newton-rc2
>
> While some of them might be fixed by tomorrow (TripleO RC2 deadline),
> we might need to request RC3 next week, if possible.
>
> Reminder: stable/newton will be created when RC2 is out (likely
> tomorrow or Friday).
>
> Any feedback is welcome,
> --
> Emilien Macchi



-- 
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] [kolla] Deprecation Policies (related to Heka)

2016-09-29 Thread Paul Bourke 

Tagging kolla

On 29/09/16 16:22, Michał Jastrzębski wrote:

Agree with Christian, this is our internal wiring. As long as we
provide automated upgrade procedure which will seamlessly migrate from
heka to alternative we want, we should be good without deprecation per
se.

Cheers,
Michal

On 29 September 2016 at 04:36, Christian Berendt
 wrote:

On 29 Sep 2016, at 06:26, Steven Dake (stdake)  wrote:

If you have a different parsing of the deprecation policy, feel free to chime 
in.


Heka is only used as an internal component of Kolla and is not provided as a 
service for the operators. It should be sufficient to replace Heka by something 
else without deprecating it.

Christian.

__
OpenStack Development Mailing 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] [new][winstackers] networking-hyperv 3.0.0 release (newton)

2016-09-29 Thread no-reply 
We are happy to announce the release of:

networking-hyperv 3.0.0: This project tracks the work to integrate the
Hyper-V networking with Neutron. This project contains the Hyper-V
Neutron Agent Mixin, Security Groups Driver, ML2 Mechanism Driver and
the utils modules they use in order to properly bind neutron ports on
a Hyper-V host. This project resulted from the neutron core vendor
decomposition.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/networking-hyperv

With package available at:

https://pypi.python.org/pypi/networking-hyperv

Please report issues through launchpad:

http://bugs.launchpad.net/networking-hyperv

For more details, please see below.

Changes in networking-hyperv 3.0.0.0rc1..3.0.0
--

aaeab63 TrivialFix: Remove cfg import unused
d04ffc7 TrivialFix: Remove logging import unused


Diffstat (except docs and test files)
-

hyperv/neutron/hyperv_agent_notifier.py  | 4 
2 files changed, 7 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

Re: [openstack-dev] Deprecation Policies (related to Heka)

2016-09-29 Thread Michał Jastrzębski 
Agree with Christian, this is our internal wiring. As long as we
provide automated upgrade procedure which will seamlessly migrate from
heka to alternative we want, we should be good without deprecation per
se.

Cheers,
Michal

On 29 September 2016 at 04:36, Christian Berendt
 wrote:
>> On 29 Sep 2016, at 06:26, Steven Dake (stdake)  wrote:
>>
>> If you have a different parsing of the deprecation policy, feel free to 
>> chime in.
>
> Heka is only used as an internal component of Kolla and is not provided as a 
> service for the operators. It should be sufficient to replace Heka by 
> something else without deprecating it.
>
> Christian.
>
> __
> OpenStack Development Mailing 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][searchlight] searchlight Newton RC2 available

2016-09-29 Thread Davanum Srinivas 
Hello everyone,

The release candidate for searchlight for the end of the Newton cycle
is available! You can find the RC2 source code tarball at:

https://tarballs.openstack.org/searchlight/searchlight-1.0.0.0rc2.tar.gz
https://tarballs.openstack.org/searchlight-ui/searchlight-ui-1.0.0.0rc2.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as the final
Newton release on 6 October. You are therefore strongly encouraged to
test and validate this tarball!

Alternatively, you can directly test the stable/newton release branch at:

http://git.openstack.org/cgit/openstack/searchlight/log/?h=stable/newton

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/searchlight/+filebug

and tag it *newton-rc-potential* to bring it to the searchlight
release crew's attention.

Note that the "master" branch of searchlight is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Dims

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

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

[openstack-dev] [release][senlin] Senlin Newton RC2 available

2016-09-29 Thread Davanum Srinivas 
Hello everyone,

The release candidate for Senlin for the end of the Newton cycle is
available! You can find the RC2 source code tarball at:

https://tarballs.openstack.org/senlin/senlin-2.0.0.0rc2.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as the final
Newton release on 6 October. You are therefore strongly encouraged to
test and validate this tarball!

Alternatively, you can directly test the stable/newton release branch at:

http://git.openstack.org/cgit/openstack/senlin/log/?h=stable/newton

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/senlin/+filebug

and tag it *newton-rc-potential* to bring it to the senlin release
crew's attention.

Thanks,
Dims

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

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

Re: [openstack-dev] [nova][neutron] summit cross-project session

2016-09-29 Thread Matt Riedemann 

On 9/19/2016 2:49 PM, Armando M. wrote:



I asked an extra session on the Neutron side to dedicate to
nova/neutron, and I was hoping to have them back to back, but it doesn't
look possible under the current arrangement. Do you think it's worth
trying and tweak things? If not I guess we can have one on Wed the other
on Thu.





OK, I didn't realize you planned on hosting the nova/neutron thing and 
we also planned on hosting. :)


I'm fine if you guys want to host a xp session on Wednesday afternoon 
and Nova can pencil one in for Thursday afternoon for follow up if 
necessary. I think Nova has more slots than we probably need so I'm 
struggling a bit to fill them.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [murano] IRC Meeting time suggestion

2016-09-29 Thread aaronzhu1121 
Good news forcontributorfrom China, will attend the meeting.


Thanks,
Zhu Rong__
OpenStack Development Mailing 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][elections] Candidate proposals for TC (Technical Committee) positions are now open

2016-09-29 Thread Davanum Srinivas 
Folks,

3 incumbents are not running. Many thanks to Russell, Anne, Kyle for
their service and dedication (per TC meeting logs -
http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.log.html)

9 candidates are running (per
https://review.openstack.org/#/q/project:openstack/election).

Now's a good time to help shape the future of OpenStack. Please
consider stepping up to be a candidate for the TC!

Thanks,
Dims


On Sun, Sep 25, 2016 at 8:08 PM, Tristan Cacqueray  wrote:
> Candidate proposals for the Technical Committee positions (6 positions)
> are now open and will remain open until 2016-10-01, 23:45 UTC
>
> All candidacies must be submitted as a text file to the
> openstack/election repository as explained on the election website[1].
> Please note that the name of the file has changed this cycle to be the
> candidates IRC nic *not* full-name.
>
> Also for TC candidates, election officials refer to the community member
> profiles at [2] please take this opportunity to ensure that the you
> profile contains current information.
>
> Candidates for the Technical Committee Positions: Any Foundation
> individual member can propose their candidacy for an available,
> directly-elected TC seat. (except the seven (7) TC members who were
> elected for a one-year seat in April[3]).
>
> The election will be held from October 3rd through to 23:45 October 8th,
> 2015 UTC. The electorate are the Foundation individual members that are
> also committers for one of the official programs projects[4] over the
> Mitaka-Newton timeframe (September 5, 2015 00:00 UTC to September 4,
> 2016 23:59 UTC)), as well as the extra-ATCs who are acknowledged by the
> TC[5].
>
> Please see the website[1] for additional details about this election.
> Please find below the timeline:
>
> TC nomination starts   @ 2016-09-26, 00:00 UTC
> TC nomination ends @ 2016-10-01, 23:45 UTC
> TC elections begins@ 2016-10-03, 00:00 UTC
> TC elections ends  @ 2016-10-08, 23:45 UTC
>
> If you have any questions please be sure to either voice them on the
> mailing list or to the elections officials[6].
>
> Thank you, and we look forward to reading your candidate proposals,
> -Tristan
>
> [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
> [2] http://www.openstack.org/community/members/
> [3] https://wiki.openstack.org/wiki/TC_Elections_April_2016#Results
> [4]
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2016-elections
>  Note the tag for this repo, sept-2016-elections.
> [5] Look for the extra-atcs element in [4]
> [6] http://governance.openstack.org/election/#election-officials
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

Re: [openstack-dev] [stackalytics]

2016-09-29 Thread Ilya Shakhat 
Roman,

  There are certainly exist a bug in stackalytics [1]. Current contribution
> to different openstack/* projects was counted for deb-* . Now all affected
> commit records on stackalytics are removed from deb-* projects, but they
> should be moved to proper non-deb projects. Is there any one how could
> solve this bug?
>

This duplication is one of the reasons why we removed all deb-* projects
from statistics. Now it seems like we need to fix all other stats as well.

Thanks for reporting this.

--Ilya
__
OpenStack Development Mailing 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] [new][documentation] openstack-doc-tools 1.2.0 release

2016-09-29 Thread no-reply 
We are psyched to announce the release of:

openstack-doc-tools 1.2.0: Tools for OpenStack Documentation

With source available at:

http://git.openstack.org/cgit/openstack/openstack-doc-tools

Please report issues through launchpad:

http://bugs.launchpad.net/openstack-manuals

For more details, please see below.

Changes in openstack-doc-tools 1.1.0..1.2.0
---

01f284a [config-ref] update service names for diff branches
994b514 Updated from global requirements
85348f1 Updated from global requirements
ceb8afd Increase hacking version
2d1f67a Remove Babel requirement


Diffstat (except docs and test files)
-

autogenerate_config_docs/diff_branches.py | 5 -
requirements.txt  | 3 +--
test-requirements.txt | 4 ++--
3 files changed, 7 insertions(+), 5 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 4510a3f..e6c0afd 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +5,0 @@ pbr>=1.6 # Apache-2.0
-Babel>=2.3.4 # BSD
@@ -10 +9 @@ oslo.config>=3.14.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index 8a0efbc..3cac23e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9 +9 @@ doc8 # Apache-2.0
-hacking<0.11,>=0.10.0
+hacking<0.12,>=0.11.0 # Apache-2.0
@@ -13 +13 @@ reno>=1.8.0 # Apache2
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+oslosphinx>=4.7.0 # Apache-2.0



__
OpenStack Development Mailing 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] [packaging][rpm] 3rd-party gates promotion to voting gates

2016-09-29 Thread Dirk Müller 
Hi,

>> Gates that do not leave verified +1 are called non-voting, so
>> logically gates that leaves verified +1 are called voting gates.
> +1

Eh, what I wanted to +1 was:

+1 to promote the check jobs on rpm-packaging from MOS and SUSE CI as
voting jobs.

Sorry for mixing up definitions and then even quoting the wrong thing ;-)


Thanks,
Dirk

__
OpenStack Development Mailing 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] install guide has moved

2016-09-29 Thread Andreas Jaeger 
On 2016-09-29 15:10, Ruby Loo wrote:
> Hi Andreas,
> 
>  
> 
> Because you asked so nicely, tada:
> http://docs.openstack.org/project-install-guide/baremetal/newton/

Great, thanks a lot Ruby and Ironic team!

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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

Re: [openstack-dev] [cinder] [qa] Proposal to make multinode grenade job voting

2016-09-29 Thread Erlon Cruz 
+1
It seems good!


On Thu, Sep 29, 2016 at 7:25 AM, Michał Dulko 
wrote:

> On 09/29/2016 12:10 PM, Michał Dulko wrote:
> > Hello everyone,
> >
> > We have a non-voting multinode grenade job in check queue for around a
> > month now.
> >
> > https://goo.gl/Kr10s6
>
> Whoops, I've sent this by mistake. Here's the actual email:
>
> Hello everyone,
>
> We have a non-voting multinode grenade job in check pipeline for around
> a month now. It is testing rolling upgrades by checking compatibility of
> stable c-vol and c-bak with master c-api and c-sch. This is a
> requirement for Cinder to achieve an assert:supports-rolling-upgrade tag
> [1]. As the job seems fairly stable in comparison with the tempest job
> [2] and in ci-watch [3], I'm proposing to make it voting.
>
> Please note that failures seen in the beginning of September on graph
> [2] are results of bug [4], which was actually found by the job
> (although the bug itself wasn't related to upgrades).
>
> The patch making the job voting is available at [5].
>
> Thanks,
> Michal
>
> [1]
> https://governance.openstack.org/reference/tags/assert_
> supports-rolling-upgrade.html
> [2] https://goo.gl/Kr10s6
> [3] http://ci-watch.tintri.com/project?project=cinder=7+days
> [4] https://bugs.launchpad.net/cinder/+bug/1619246
> [5] https://review.openstack.org/#/c/379346/
>
> __
> OpenStack Development Mailing 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] The end-user test suite for OpenStack clusters

2016-09-29 Thread Timur Nurlygayanov 
Hi Ken,

I am guessing the above "restart nodes" is for verifying each
> OpenStack service restarts successfully, right?

Yes, this is right. And we also will check that HA logic for these
services works correctly (for example, rescheduling of L3 Neutron
agents for networks).

But these service scripts are provided by distributors, and Devstack
> itself doesn't contain service scripts IIUC.
> So I'd like to know how to verify it on Devstack clouds.

Yes, DevStack doesn't support many scenarios which are actual
and should be supported on the production clouds.
It will be not possible to run all advanced test scenarios for DevStack
clouds,
just because DevStack can't deploy OpenStack cloud with 3 controllers
now (so, probably it will be possible in the future).

Of course, some advanced scenarios will support DevStack clouds,
for example, some test scenarios which are based on customer-found
issues from the real production clouds, like upload of the large images
(100+ Gb)
to Glance with Swift backend. Such cases are important for verification of
pre-production environments, but not very important for CI gate jobs.

It is also important to note that in these advanced cases we are targeting
to check not only the logic of Python code, but also the correct
configuration
of all OpenStack components on some pre-production OpenStack clusters.

Thank you!

On Wed, Sep 28, 2016 at 2:37 AM, Ken'ichi Ohmichi 
wrote:

> Hi Timur,
>
> Thanks for picking this up, that is interesting for me.
>
> 2016-09-22 5:58 GMT-07:00 Timur Nurlygayanov :
> >
> > we have an idea to create the test suite with destructive/HA and advanced
> > end-user scenarios for the OpenStack clusters. This test suite will
> contains
> > advanced scenario integration tests for OpenStack clusters to make sure
> that
> > the cluster is ready for the production.
> >
> > The test cases which we want to cover in this test suite:
> > 1) All simple and advanced destructive actions, like a reboot of the
> nodes,
> > restart OpenStack services and etc. (we can probably use of-faults
> library
> > [1], which we already use in Rally)
> > 2) All advanced test scenarios like a migration of the bunch of VMs
> between
> > nodes and booting of the VMs with large images (10+ Gb), send traffic
> > between VMs and in parallel restart Neutron l3 agents and etc.
> >
> > The key requirements:
> > 1) The framework should know the details of the deployments (how many
> nodes
> > we have, how to ssh to OpenStack nodes, how to restart the nodes and
> etc.).
> > This is why we don't want to add such "advanced" and HA-focused test
> > scenarios to Tempest.
>
> Yeah, this point is right. This "advanced" way is different from the
> design principle of Tempest[1].
> I am guessing the above "restart nodes" is for verifying each
> OpenStack service restarts successfully, right?
> For productions(or distributions), this verifying point seems
> important because service scripts need to restart OpenStack services
> automatically.
> But these service scripts are provided by distributors, and Devstack
> itself doesn't contain service scripts IIUC.
> So I'd like to know how to verify it on Devstack clouds.
>
> Thanks
> Ken Ohmichi
> ---
>
> [1]: https://github.com/openstack/tempest#design-principles
>
> > 2) We should be ready to run these tests for any clouds: DevStack clouds
> (we
> > can skip HA cases for DevStack), Fuel clouds, clouds which were deployed
> by
> > Ansible or Puppet tools.
> > 3) This framework should allow reproduce the issue in a repeatable
> manner,
> > this is why we can't just cover all the tests with Rally load tests +
> > destructive plugins (we are working on this right now too to have an
> ability
> > to test HA-related scenarios under the load).
> >
> > As we discussed on the OpenStack summit a year ago it is better to move
> such
> > test suite in a separate repository and this framework can became a part
> of
> > the QA (or at least BigTent) program in OpenStack.
> >
> > I've created the commit to OpenStack project-config repository:
> > https://review.openstack.org/#/c/374667/
> >
> > Could you please take a look?
> >
> > We understand that it will be hard to add such test suite to the gates
> for
> > every commit in OpenStack because we will need a lot of hardware. We
> don't
> > want to add these tests to the per-commit gates for now, it is ok to run
> > them just once a day, for example. And we definitely need to have such
> test
> > suite to validate our own pre-production clouds.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Timur,
Senior QA Manager
OpenStack Projects
Mirantis Inc
__

Re: [openstack-dev] [ironic] install guide has moved

2016-09-29 Thread Loo, Ruby 
Hi Andreas,

Because you asked so nicely, tada: 
http://docs.openstack.org/project-install-guide/baremetal/newton/

Also, thanks for clarifying about ../draft/.. !

--ruby

From: Andreas Jaeger 
Organization: SUSE Linux GmbH, Nuernberg, GF: Felix Imendörffer, Jane Smithard, 
Graham Norton , HRB 21284 (AG Nuernberg)
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, September 27, 2016 at 11:04 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [ironic] install guide has moved

On 2016-09-27 17:02, Andreas Jaeger wrote:
On 2016-09-27 16:54, Ruby Loo wrote:
Hi,



Thanks to the huge efforts put in by Mathieu Mitchell (mat128) and Jay
Faulkner (JayF), we've moved ironic's install guide from the developer
documentation to the official openstack site [1]. Isn't it a beauty? :D



Please update your bookmarks to point to the new location, and help us
improve the install guide by providing feedback and submitting patches.



--ruby



[1] http://docs.openstack.org/project-install-guide/baremetal/draft/
Be aware that this is the draft location - the version from master, so
this will soon be the Ocata version.
Once newton is released, docs.openstack.org will point to the Newton
version which is published from stable/newton branch already to:
http://docs.openstack.org/project-install-guide/baremetal/newton/

Oh, the draft version is really a beauty. Can you backport that to
newton, please?

Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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

__
OpenStack Development Mailing 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] [packaging][rpm] 3rd-party gates promotion to voting gates

2016-09-29 Thread Dirk Müller 
Hi,

2016-09-29 14:12 GMT+02:00 Haïkel :

> Gates that do not leave verified +1 are called non-voting, so
> logically gates that leaves verified +1 are called voting gates.

+1


Greetings,
Dirk

__
OpenStack Development Mailing 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] [tempest] Test case for new feature failed in Jenkins check against old release

2016-09-29 Thread Matthew Treinish 
On Thu, Sep 29, 2016 at 03:49:27PM +0800, Bruce Tan wrote:
> Hello everyone,
> 
> I am having a problem writing/updating a test case to verify some new
> feature (in my case, the "description" field for a network).
> 
> Acoording to Tempest Coding Guide[1], I am supposed to check if the
> related feature is there by @test.requires_ext() like this:
> @test.requires_ext(extension="standard-attr-description",
>service="network")
> 
> And according to the same doc,
> > When running a test that requires a certain "feature" in the target
> > cloud, if that feature is missing we should fail, because either the
> > test configuration is invalid, or the cloud is broken and the expected
> > "feature" is not there even if the cloud was configured with it.
> 
> 
> However, my patch[2] got a "-1" from Jenkins because one check
> ("gate-tempest-dsvm-neutron-full-ubuntu-trusty-liberty") failed. The
> reason for failing, I think, is just what I quoted above: the
> tempest.conf[3]  file is configured as
>   [network-feature-enabled]api_extensions = all
> which means any api_extension is supported; but the feature I am
> testing is obviously not there in Liberty, so the API doesn't accept
> "description" field, and the test case failed.
> 
> So my question is, what did I do wrong? Is there some other way
> to skip the case for older releases? Or, maybe we shouldn't use
> "api_extensions=all" (explicitly list all extensions instead, which
> takes some effort obviously) in the configuration file?

You actually did everything correctly for making sure you skip properly
if the new feature isn't present on the tempest side. It's actually a bug in
devstack you're hitting. On stable branches we're supposed to hard code the
extension list of what api extensions are available when we branch the project.
But in the case of liberty, we neglected to do this:

http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/tempest?h=stable%2Fliberty#n430

Instead this should look something like what we did on the kilo branch:

http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/tempest?h=stable/kilo#n413

You just need to push up a patch to devstack's stable/liberty branch that hard
codes the extensions available like we did in previous branches.  Once that's up
add a Depends-On to your commit and it should work fine.

-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] [packaging][rpm] 3rd-party gates promotion to voting gates

2016-09-29 Thread Anita Kuno 

On 16-09-29 08:12 AM, Haïkel wrote:

2016-09-26 16:05 GMT+02:00 Anita Kuno :

On 16-09-26 07:48 AM, Haïkel wrote:

Hi,

following our discussions about 3rd party gates in RPM packaging project,
I suggest that we vote in order to promote the following gates as voting:
- MOS CI
- SUSE CI

After promotion, all patchsets submitted will have to validate these gates
in order to get merged. And gates maintainers should ensure that the gates
are running properly.

Please vote before (and/or during) our thursday meeting.


+1 to promote both MOS and SUSE CI as voting gates.

Regards,
H.


I'm not sure what you mean by voting gates. Gates don't vote, an individual
job can leave a verified +1 in the check queue or/and a verified +2 in the
gate queue.

Third party CI systems do not vote verified +2 in gerrit. They may if the
project chooses vote verified +1 on a project.


Yeah, that was pretty much what was assumed.
Gates that do not leave verified +1 are called non-voting, so
logically gates that leaves verified +1 are called voting gates.


Gate is a pipeline. Jobs run in pipelines (check, gate, post) and leave 
success or failure as results.


There is no such thing as a voting gate. There is a thing called a 
voting job. I think you mean voting job.


Thanks,
Anita.




If you need clarification in what third party ci systems may do in gerrit,
you are welcome to reply to this email, join the #openstack-infra channel or
participate in a third party meeting:
http://eavesdrop.openstack.org/#Third_Party_Meeting

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 Development Mailing 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] SRIOV-port refused to bind

2016-09-29 Thread Prasanth Anbalagan 
Murali,

I have seen this binding error once when I failed to configure the SRIOV agent. 
Please check the agent settings
as per the link below that Lenny sent.

Thanks
Prasanth

- Original Message -
From: "Lenny Verkhovsky" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Thursday, September 29, 2016 3:07:28 AM
Subject: Re: [openstack-dev] SRIOV-port refused to bind



HI, 

Did you configured everything according to 
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking ? 

( including intel_iommu=on ) ? 

Can you attach more logs and config files of the nova/neutron/neutron plugins 

Are you working with devstack or distro? 






From: Murali B [mailto:mbi...@gmail.com] 
Sent: Thursday, September 29, 2016 5:52 AM 
To: OpenStack Development Mailing List (not for usage questions) 
 
Subject: [openstack-dev] SRIOV-port refused to bind 





Hi 





I am using the SRIOV on mitaka. When I try to launch the VM with SRIOV port its 
failed. 





When I see the neutrn-server.log I see that below message on controller. 





ddf81 - - -] Refusing to bind due to unsupported vnic_type: direct bind_port 
/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/mech_agent.py:65 


2016-09-28 18:55:18.384 16531 ERROR neutron.plugins.ml2.managers 
[req-443e9b6a-45c6-4b30-aa50-52a9b0a4926c 7d0ef58dd1214f54983c9d843fec0bde 
238c9900a2ae4b57b01fa72abdeddf81 - - -] Failed to bind port 
e96eadf3-5501-442a-8bcc-0b4d64617b26 on host A1-22932-compute1 for vnic_type 
direct using segments [{'segmentation_id': 123, 'physical_network': 
u'physnet1', 'id': u'30b77081-d02c-4e29-a41a-f8997c1f9f66', 'network_type': 
u'vlan'}] 





On compute node I see the below error. 





2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] flavor, virt_type, self._host) 


2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py", line 447, in 
get_config 


2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] _("Unexpected vif_type=%s") % vif_type) 


2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] NovaException: Unexpected 
vif_type=binding_failed 





Could somebody help me to come-out this issue. 








Thanks 


-Murali 

__
OpenStack Development Mailing 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] SRIOV-port refused to bind

2016-09-29 Thread Beliveau, Ludovic 
Also, here’s the pointer to the latest guide which had been updated in this 
last cycle: http://docs.openstack.org/draft/networking-guide/config-sriov.html

Which release are you using ?

What is the content of your neutron ml2_conf.ini file ?

/ludovic

From: Lenny Verkhovsky [mailto:len...@mellanox.com]
Sent: September-29-16 3:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] SRIOV-port refused to bind

HI,
Did you configured everything according to 
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking?
( including intel_iommu=on ) ?
Can you attach more logs and config files of the nova/neutron/neutron plugins
Are you working with devstack or distro?


From: Murali B [mailto:mbi...@gmail.com]
Sent: Thursday, September 29, 2016 5:52 AM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: [openstack-dev] SRIOV-port refused to bind

Hi

I am using the SRIOV on mitaka. When I try to launch the VM with SRIOV port its 
failed.

When I see the neutrn-server.log I see that below message on controller.

ddf81 - - -] Refusing to bind due to unsupported vnic_type: direct bind_port 
/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/mech_agent.py:65
2016-09-28 18:55:18.384 16531 ERROR neutron.plugins.ml2.managers 
[req-443e9b6a-45c6-4b30-aa50-52a9b0a4926c 7d0ef58dd1214f54983c9d843fec0bde 
238c9900a2ae4b57b01fa72abdeddf81 - - -] Failed to bind port 
e96eadf3-5501-442a-8bcc-0b4d64617b26 on host A1-22932-compute1 for vnic_type 
direct using segments [{'segmentation_id': 123, 'physical_network': 
u'physnet1', 'id': u'30b77081-d02c-4e29-a41a-f8997c1f9f66', 'network_type': 
u'vlan'}]

On compute node I see the below error.

2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] flavor, virt_type, self._host)
2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482]   File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py", line 447, in 
get_config
2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] _("Unexpected vif_type=%s") % 
vif_type)
2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] NovaException: Unexpected 
vif_type=binding_failed

Could somebody help me to come-out this issue.


Thanks
-Murali
__
OpenStack Development Mailing 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] [Dragonflow] Weekly meeting on Monday, 5th Oct. is canceled

2016-09-29 Thread Omer Anson 
Hello, all.

Due to the local holidays, I have to cancel the Dragonflow weekly meeting
on Monday.
The following meeting on the 12th Oct. is planned to take place as usual.

Thank you,
Omer Anson.
__
OpenStack Development Mailing 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] [packaging][rpm] 3rd-party gates promotion to voting gates

2016-09-29 Thread Haïkel 
2016-09-26 16:05 GMT+02:00 Anita Kuno :
> On 16-09-26 07:48 AM, Haïkel wrote:
>>
>> Hi,
>>
>> following our discussions about 3rd party gates in RPM packaging project,
>> I suggest that we vote in order to promote the following gates as voting:
>> - MOS CI
>> - SUSE CI
>>
>> After promotion, all patchsets submitted will have to validate these gates
>> in order to get merged. And gates maintainers should ensure that the gates
>> are running properly.
>>
>> Please vote before (and/or during) our thursday meeting.
>>
>>
>> +1 to promote both MOS and SUSE CI as voting gates.
>>
>> Regards,
>> H.
>
>
> I'm not sure what you mean by voting gates. Gates don't vote, an individual
> job can leave a verified +1 in the check queue or/and a verified +2 in the
> gate queue.
>
> Third party CI systems do not vote verified +2 in gerrit. They may if the
> project chooses vote verified +1 on a project.
>

Yeah, that was pretty much what was assumed.
Gates that do not leave verified +1 are called non-voting, so
logically gates that leaves verified +1 are called voting gates.

> If you need clarification in what third party ci systems may do in gerrit,
> you are welcome to reply to this email, join the #openstack-infra channel or
> participate in a third party meeting:
> http://eavesdrop.openstack.org/#Third_Party_Meeting
>
> 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 Development Mailing 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] TC candidacy

2016-09-29 Thread Chris Dent 

On Thu, 29 Sep 2016, Flavio Percoco wrote:


I'm not saying it wouldn't be useful at all. What I'm saying is that
the format, and more importantly, the content will have to be studied.
I'll likely start working on this and I could use your help whether or
not you'll win the election
:)


Yeah, that sounds good. Please keep me involved.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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][infra][all] Measuring code coverage in integration tests

2016-09-29 Thread Assaf Muller 
On Thu, Sep 29, 2016 at 5:27 AM, milanisko k  wrote:

>
>
> út 27. 9. 2016 v 20:12 odesílatel Assaf Muller  napsal:
>
>> On Tue, Sep 27, 2016 at 2:05 PM, Assaf Muller  wrote:
>>
>>>
>>>
>>> On Tue, Sep 27, 2016 at 12:18 PM, Timur Nurlygayanov <
>>> tnurlygaya...@mirantis.com> wrote:
>>>
 Hi milan,

 we have measured the test coverage for OpenStack components with
 coverage.py tool [1]. It is very easy tool and it allows measure the
 coverage by lines of code and etc. (several metrics are available).

 [1] https://coverage.readthedocs.io/en/coverage-4.2/

>>>
>>> coverage also supports aggregating results from multiple runs, so you
>>> can measure results from combinations such as:
>>>
>>>
>>
>>> 1) Unit tests
>>> 2) Functional tests
>>> 3) Integration tests
>>> 4) 1 + 2
>>> 5) 1 + 2 + 3
>>>
>>> To my eyes 3 and 4 make the most sense. Unit and functional tests are
>>> supposed to give you low level coverage, keeping in mind that 'functional
>>> tests' is an overloaded term and actually means something else in every
>>> community. Integration tests aren't about code coverage, they're about user
>>> facing flows, so it'd be interesting to measure coverage
>>> from integration tests,
>>>
>>
>> Sorry, replace integration with unit + functional.
>>
>>
>>> then comparing coverage coming from integration tests, and getting the
>>> set difference between the two: That's the area that needs more unit and
>>> functional tests.
>>>
>>
>> To reiterate:
>>
>> Run coverage from integration tests, let this be c
>> Run coverage from unit and functional tests, let this be c'
>>
>> Let diff = c \ c'
>>
>> 'diff' is where you're missing unit and functional tests coverage.
>>
>
> Assaf, the tool I linked is a monkey-patched coverage.py but the collector
> stores the stats in Redis --- gives the same accumulative collecting.
> Is there any interest/effort to collect coverage stats from selected jobs
> in CI, no matter the tool used?
>

Some projects already collect coverage stats on their post-merge queue:
http://logs.openstack.org/61/61af70a734b99e61e751cfb494ddc93a85eec394/post/nova-coverage-db-ubuntu-xenial/55210aa/

It's invoked with 'tox -e cover' which you define in your project's tox.ini
file, I imagine most projects if not all have it set up to gather coverage
from a unit tests run.


>
>
>>
>>
>>>
>>>

 On Tue, Sep 27, 2016 at 1:06 PM, Jordan Pittier <
 jordan.pitt...@scality.com> wrote:

> Hi,
>
> On Tue, Sep 27, 2016 at 11:43 AM, milanisko k 
> wrote:
>
>> Dear Stackers,
>> I'd like to gather some overview on the $Sub: is there some
>> infrastructure in place to gather such stats? Are there any groups
>> interested in it? Any plans to establish such infrastructure?
>>
> I am working on such a tool with mixed results so far. Here's my
> approach taking let's say Nova as an example:
>
> 1) Print all the routes known to nova (available as a python-routes
> object:  nova.api.openstack.compute.APIRouterV21())
> 2) "Normalize" the Nova routes
> 3) Take the logs produced by Tempest during a tempest run (in
> logs/tempest.txt.gz). Grep for what looks like a Nova URL (based on port
> 8774)
> 4) "Normalize" the tested-by-tempest Nova routes.
> 5) Compare the two sets of routes
> 6) 
> 7) Profit !!
>
> So the hard part is obviously the normalizing of the URLs. I am
> currently using a tons of regex :) That's not fun.
>
> I'll let you guys know if I have something to show.
>
> I think there's real interest on the topic (it comes up every year or
> so), but no definitive answer/tool.
>
> Cheers,
> Jordan
>
>
>
>
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


 --

 Timur,
 Senior QA Manager
 OpenStack Projects
 Mirantis Inc

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


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

Re: [openstack-dev] [cinder] [qa] Proposal to make multinode grenade job voting

2016-09-29 Thread Michał Dulko 
On 09/29/2016 12:10 PM, Michał Dulko wrote:
> Hello everyone,
>
> We have a non-voting multinode grenade job in check queue for around a
> month now.
>
> https://goo.gl/Kr10s6

Whoops, I've sent this by mistake. Here's the actual email:

Hello everyone,

We have a non-voting multinode grenade job in check pipeline for around
a month now. It is testing rolling upgrades by checking compatibility of
stable c-vol and c-bak with master c-api and c-sch. This is a
requirement for Cinder to achieve an assert:supports-rolling-upgrade tag
[1]. As the job seems fairly stable in comparison with the tempest job
[2] and in ci-watch [3], I'm proposing to make it voting.

Please note that failures seen in the beginning of September on graph
[2] are results of bug [4], which was actually found by the job
(although the bug itself wasn't related to upgrades).

The patch making the job voting is available at [5].

Thanks,
Michal

[1]
https://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html
[2] https://goo.gl/Kr10s6
[3] http://ci-watch.tintri.com/project?project=cinder=7+days
[4] https://bugs.launchpad.net/cinder/+bug/1619246
[5] https://review.openstack.org/#/c/379346/

__
OpenStack Development Mailing 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] [qa] Proposal to make multinode grenade job voting

2016-09-29 Thread Michał Dulko 
Hello everyone,

We have a non-voting multinode grenade job in check queue for around a
month now.

https://goo.gl/Kr10s6

__
OpenStack Development Mailing 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] [release][mistral] mistral Newton RC3 available

2016-09-29 Thread Thierry Carrez 
Thierry Carrez wrote:
> Hello everyone,
> 
> A new release candidate for mistral for the end of the Newton cycle was
> generated, to catch release-critical fixes. You can find the source code
> tarball at:
> 
> https://tarballs.openstack.org/mistral/mistral-3.0.0.0rc2.tar.gz

Actually there was a critical security issue found and fixed in that
RC2, please test RC3 instead:

https://tarballs.openstack.org/mistral/mistral-3.0.0.0rc3.tar.gz

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [oslo][neutron] switch to to_policy_values for policy dict

2016-09-29 Thread Ihar Hrachyshka 

Hi all,

there is a patch for neutron that switches neutron policy engine from  
passing context.to_dict() into oslo.policy to using  
context.to_policy_values() that was added recently to oslo.context.


The patch is: https://review.openstack.org/#/c/370499/

The new function from oslo.context returns a dict that has less keys in it  
than .to_dict() result.


For Neutron matters, considering the patch contents, here is the diff  
between two dicts.


1. new dict misses the following keys:
- domain;
- read_only;
- show_deleted;
- auth_token;
- request_id;
- resource_uuid;
- user_identity;
- user;
- tenant;
- timestamp;
- tenant_name;
- project_name;
- user_name.

2. The following keys are renamed in the new dict:
- user_domain -> user_domain_id;
- project_domain -> project_domain_id.

Since policy.json is a file that can be modified by operators, and we can’t  
really control how they parse context in their custom rules, the change  
proposed seems backwards incompatible to me. I understand that some  
missing/renamed keys are pretty safe to drop (who would base their policy  
rules on ‘read_only’ or ‘request_id’?), but others are of more concern  
(user and tenant synonyms to user_id and project_id are dropped;  
user_domain and project_domain renamed; …)


Now, for oslo library matters, it does not seem like a big deal, because no  
existing users of to_dict are affected, and only those adopting the new  
method need to take care of potential breakages. But for Neutron to adopt  
the new method, we should consider those implications.


I would suggest we keep the list of keys available to policy engine intact,  
meaning overriding the original to_policy_values method so that the missing  
keys are still there.


Ihar

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

Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

2016-09-29 Thread Flavio Percoco 

On 28/09/16 17:49 -0400, Ryan Hallisey wrote:

Hey Flavio,

I attached two architecture diagrams highlighting the four main
lifecycle pieces of OpenStack orchestration: bootstrapping,
deployment, upgrading, and scaling. Config is also in there, but
it was constant throughout each diagram.

The diagrams are not designed to be a detailed workflow of events, but
rather an easy to consume high level architecture.

I'll iterate on this further when I get a chance.

Thanks!
-Ryan

- Original Message -
From: "Davanum Srinivas" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, September 28, 2016 12:27:45 PM
Subject: Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to 
deploy OpenStack on k8s

Here you go Flavio, Sergey and team collected some information from
fuel-ccp efforts.

Design for OpenStack Containerized Control Plane :
https://review.openstack.org/#/c/378266/
Design document for clustering services on k8s :
https://review.openstack.org/#/c/378244/
Add test plan/results for fuel-ccp : https://review.openstack.org/#/c/378271/



This is awesome! You all rock! I'll go through this info and try to come up with
a summary of what has been done and I'll report back. Let's see what comes out
of this.

Thanks again for your help and contributions :)
Flavio


Thanks,
Dims

On Tue, Sep 27, 2016 at 4:23 AM, Flavio Percoco  wrote:

On 27/09/16 00:41 +, Fox, Kevin M wrote:


I think some of the disconnect here is a potential misunderstanding about
what kolla-kubernetes is

Ultimately, to me, kolla-kubernetes is a database of architecture bits to
successfully deploy and manage OpenStack on k8s. Its building blocks. Pretty
much what you asked for.

There are a bunch of ways of building openstacks. There is no one true
way. It really depends on what the operator wants the cloud to do. Is a
daemonset or a petset the best way to deploy a cinder volume pod in k8s? The
answer is, it depends. (We have an example where one or the other is better
now)

kolla-kubernetes is taking the building block approach. It takes a bit of
information in from the operator or other tool, along with their main
openstack configs, and generates k8s templates that are optimized for that
case.

Who builds the configs, who tells it when to build what templates, and in
what order they are started is a separate thing.

You should be able to do a 'kollakube template pod nova-api' and just see
what it thinks is best.

If you want a nice set of documents, it should be easy to loop across them
and dump them to html.

I think doing them in a machine readable way rather then a document makes
much more sense, as it can be reused in multiple projects such as tripleo,
fuel, and others and we all can share a common database. We're trying to
build a community around this database.

Asking to basically make a new project, that does just a human only
readable version of the same database seems like a lot of work, with many
fewer useful outcomes.



I just want to point out that I'm not asking anyone to make a new project
and
that my intention is to collect info from other projects too, not just
kolla-kubernetes. This is a pure documentation effort. I understand you
don't
think this is useful and I appreciate your feedback.

Flavio



Please help the community make a great machine and human readable
reference architecture system by contributing to the kolla-kubernetes
project. There are plenty of opportunity to help out.

Maybe making some tools to make the data contained in the database more
human friendly would suit your interests? Maybe a nice web frontend that
asks a few questions and renders templates out in nice human friendly ways?

Thanks,
Kevin

From: Flavio Percoco [fla...@redhat.com]
Sent: Monday, September 26, 2016 9:42 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture
to deploy OpenStack on k8s

On 23/09/16 17:47 +, Steven Dake (stdake) wrote:


Flavio,

Forgive the top post and lack of responding inline – I am dealing with
lookout 2016 which apparently has a bug here [0].

Your question:

I can contribute to kolla-kubernetes all you want but that won't give me
what I
asked for in my original email and I'm pretty sure there are opinions
about the
"recommended" way for running OpenStack on kubernetes. Questions like:
Should I
run rabbit in a container? Should I put my database in there too? Now
with
PetSets it might be possible. Can we be smarter on how we place the
services in
the cluster? Or should we go with the traditional
controller/compute/storage
architecture.

You may argue that I should just read the yaml files from
kolla-kubernetes and
start from there. May be true but that's why I asked if there was
something
written already.
Your question ^

My answer:
I think what

Re: [openstack-dev] [all][oslo] Parse ISO8601 (open) time intervals

2016-09-29 Thread milanisko k 
út 27. 9. 2016 v 18:05 odesílatel Doug Hellmann 
napsal:

> Excerpts from milanisko k's message of 2016-09-27 12:30:09 +:
> > Hello Stackers!
> >
> > The ironic inspector project keeps track of introspection finished_at
> time
> > stamps.
> > We're just discussing how to reasonably query time ranges over the API[1]
> > to serve matching introspection statuses to the user.
> > Wikipedia[2] mentions the ISO8601 time interval specification (and there
> > are open-interval extensions to that).
> > It would be nice to be able to specify a query like :
> >  /v1/introspection?finished_at=2016:09:27:14:17/PT1H
> > to fetch all introspection statuses that finished within 1hour around
> 14:17
> > Today,
> > or to be able to state an open-ended interval:
> > /v1/introspection?finished_at=2016:09:27:14:17/
> > but oslo_utils.timeutils lacks parsing support for ISO8061 time
> intervals.
> >
> > I'd like to ask whether other projects need to parse time intervals
> and/or
> > how do they achieve that.
> >
> > Thanks!
> > milan
> >
> > [1]
> >
> https://review.openstack.org/#/c/375045/3/specs/list-introspection-statuses.rst
> > [2] https://en.wikipedia.org/wiki/ISO_8601#Time_intervals
>
> You may want to have a look at the dateutil library.
> https://dateutil.readthedocs.io/en/stable/
>
> Doug, I'm afraid that dateutil.parser.parse doesn't support intervals
either: http://paste.openstack.org/show/583452/
Is there any interest in oslo_utils.timeutils parsing ISO8601 time
intervals as in [2]?
What do OS projects use instead especially w/r http api queries?


> 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] TC candidacy

2016-09-29 Thread Flavio Percoco 

On 28/09/16 20:59 +0100, Chris Dent wrote:

On Wed, 28 Sep 2016, Jim Rollenhagen wrote:


+1 to release notes or something of that like. i was asked to give an
update on the TC internally and it seems the only information out there
is to read through backlog of meeting logs or track the items that do
get raised to ML. even then, it's hard to define what deliverables were
achieved in the cycle.



FWIW, the resolutions that passed are listed here:
https://governance.openstack.org/


And the git tree, with a changelog, is here:
http://git.openstack.org/cgit/openstack/governance/


I assume, but I'd prefer if he confirm, that the point gordc was
trying to make was that there's more to what the TC gets up to than
merging changes to governance. That's certainly a major aspect and
one can track those changes by tracking both of those resources.

Part of the point I was trying to make in the message to which gordc was
responding is that whereas a git tree can allow someone to dig through
and acquire details, a thing that is more like release notes[1] is far
more human oriented and more likely to operate as a consumable digest of
what has happened. Notably a git log will not reflect important
conversations that did not result in a governance change nor activity
that could have led to a governance change but was rejected. Certainly
where a community says "no" is just as important as where it says "yes"?
Further, merged changes are changes that have already been decided. We
need more engagement, more broadly, while decisions are being
considered. That means being more verbose, sooner.

[1] Note that I don't actually think that release notes is the proper
form for some extra communication from the TC. Rather the justifications
that lead some projects to add release notes, in addition to the git
log, are something to consider for TC activity.


One thing that's been baking in the back of my head is to produce some sort of
summary of what the TC has done during the cycle. One reason I've not brought
this up is that I believe the information provided through the communication
subteam is probably more useful than a final write up and the end of the cycle.
In addition to this, the TC positions are 1 year long.

I'm not saying it wouldn't be useful at all. What I'm saying is that the format,
and more importantly, the content will have to be studied. I'll likely start
working on this and I could use your help whether or not you'll win the election
:)

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] Deprecation Policies (related to Heka)

2016-09-29 Thread Christian Berendt 
> On 29 Sep 2016, at 06:26, Steven Dake (stdake)  wrote:
> 
> If you have a different parsing of the deprecation policy, feel free to chime 
> in.

Heka is only used as an internal component of Kolla and is not provided as a 
service for the operators. It should be sufficient to replace Heka by something 
else without deprecating it.

Christian.


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] [QA][infra][all] Measuring code coverage in integration tests

2016-09-29 Thread milanisko k 
út 27. 9. 2016 v 20:12 odesílatel Assaf Muller  napsal:

> On Tue, Sep 27, 2016 at 2:05 PM, Assaf Muller  wrote:
>
>>
>>
>> On Tue, Sep 27, 2016 at 12:18 PM, Timur Nurlygayanov <
>> tnurlygaya...@mirantis.com> wrote:
>>
>>> Hi milan,
>>>
>>> we have measured the test coverage for OpenStack components with
>>> coverage.py tool [1]. It is very easy tool and it allows measure the
>>> coverage by lines of code and etc. (several metrics are available).
>>>
>>> [1] https://coverage.readthedocs.io/en/coverage-4.2/
>>>
>>
>> coverage also supports aggregating results from multiple runs, so you can
>> measure results from combinations such as:
>>
>>
>
>> 1) Unit tests
>> 2) Functional tests
>> 3) Integration tests
>> 4) 1 + 2
>> 5) 1 + 2 + 3
>>
>> To my eyes 3 and 4 make the most sense. Unit and functional tests are
>> supposed to give you low level coverage, keeping in mind that 'functional
>> tests' is an overloaded term and actually means something else in every
>> community. Integration tests aren't about code coverage, they're about user
>> facing flows, so it'd be interesting to measure coverage
>> from integration tests,
>>
>
> Sorry, replace integration with unit + functional.
>
>
>> then comparing coverage coming from integration tests, and getting the
>> set difference between the two: That's the area that needs more unit and
>> functional tests.
>>
>
> To reiterate:
>
> Run coverage from integration tests, let this be c
> Run coverage from unit and functional tests, let this be c'
>
> Let diff = c \ c'
>
> 'diff' is where you're missing unit and functional tests coverage.
>

Assaf, the tool I linked is a monkey-patched coverage.py but the collector
stores the stats in Redis --- gives the same accumulative collecting.
Is there any interest/effort to collect coverage stats from selected jobs
in CI, no matter the tool used?


>
>
>>
>>
>>>
>>> On Tue, Sep 27, 2016 at 1:06 PM, Jordan Pittier <
>>> jordan.pitt...@scality.com> wrote:
>>>
 Hi,

 On Tue, Sep 27, 2016 at 11:43 AM, milanisko k 
 wrote:

> Dear Stackers,
> I'd like to gather some overview on the $Sub: is there some
> infrastructure in place to gather such stats? Are there any groups
> interested in it? Any plans to establish such infrastructure?
>
 I am working on such a tool with mixed results so far. Here's my
 approach taking let's say Nova as an example:

 1) Print all the routes known to nova (available as a python-routes
 object:  nova.api.openstack.compute.APIRouterV21())
 2) "Normalize" the Nova routes
 3) Take the logs produced by Tempest during a tempest run (in
 logs/tempest.txt.gz). Grep for what looks like a Nova URL (based on port
 8774)
 4) "Normalize" the tested-by-tempest Nova routes.
 5) Compare the two sets of routes
 6) 
 7) Profit !!

 So the hard part is obviously the normalizing of the URLs. I am
 currently using a tons of regex :) That's not fun.

 I'll let you guys know if I have something to show.

 I think there's real interest on the topic (it comes up every year or
 so), but no definitive answer/tool.

 Cheers,
 Jordan




 

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


>>>
>>>
>>> --
>>>
>>> Timur,
>>> Senior QA Manager
>>> OpenStack Projects
>>> Mirantis Inc
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __
> OpenStack Development Mailing 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][infra][all] Measuring code coverage in integration tests

2016-09-29 Thread milanisko k 
út 27. 9. 2016 v 18:21 odesílatel Timur Nurlygayanov <
tnurlygaya...@mirantis.com> napsal:

> Hi milan,
>
> we have measured the test coverage for OpenStack components with
> coverage.py tool [1]. It is very easy tool and it allows measure the
> coverage by lines of code and etc. (several metrics are available).
>
> [1] https://coverage.readthedocs.io/en/coverage-4.2/
>
> Timur, the project  I linked was, besides an experimental AST-based stats
processor, a monkey-patch to the coverage.py module that allowed  remote
code coverage collection through a Redis store. It would allow one to
instrument multiple running processes from couple of nodes at the same time
while executing e.g functional tests.
The main point of it was to create a service that one would run if they
wanted to collect the stats from a project; of course all would get slowed
down 100-fold.

I'm curious if the OS projects want to execute similar code measurements on
e.g daily basis w/ selected DSVM jobs to collect stats.



> On Tue, Sep 27, 2016 at 1:06 PM, Jordan Pittier <
> jordan.pitt...@scality.com> wrote:
>
>> Hi,
>>
>> On Tue, Sep 27, 2016 at 11:43 AM, milanisko k  wrote:
>>
>>> Dear Stackers,
>>> I'd like to gather some overview on the $Sub: is there some
>>> infrastructure in place to gather such stats? Are there any groups
>>> interested in it? Any plans to establish such infrastructure?
>>>
>> I am working on such a tool with mixed results so far. Here's my approach
>> taking let's say Nova as an example:
>>
>> 1) Print all the routes known to nova (available as a python-routes
>> object:  nova.api.openstack.compute.APIRouterV21())
>> 2) "Normalize" the Nova routes
>> 3) Take the logs produced by Tempest during a tempest run (in
>> logs/tempest.txt.gz). Grep for what looks like a Nova URL (based on port
>> 8774)
>> 4) "Normalize" the tested-by-tempest Nova routes.
>> 5) Compare the two sets of routes
>> 6) 
>> 7) Profit !!
>>
> So the hard part is obviously the normalizing of the URLs. I am currently
>> using a tons of regex :) That's not fun.
>>
> I took simpler approach that just collects the stats (code execution hit
count) through coverage.py but with a "central" store, not sure that would
satisfy your use case.


> I'll let you guys know if I have something to show.
>>
>> I think there's real interest on the topic (it comes up every year or
>> so), but no definitive answer/tool.
>>
>> That wouldn't imply much interest :)


> Cheers,
>> Jordan
>>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Timur,
> Senior QA Manager
> OpenStack Projects
> Mirantis Inc
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [stackalytics]

2016-09-29 Thread Roman Vasilets 
Hi,
  There are certainly exist a bug in stackalytics [1]. Current contribution
to different openstack/* projects was counted for deb-* . Now all affected
commit records on stackalytics are removed from deb-* projects, but they
should be moved to proper non-deb projects. Is there any one how could
solve this bug?

[1] https://bugs.launchpad.net/stackalytics/+bug/1625060

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

[openstack-dev] Fwd: Questions regardin https://review.openstack.org/#/c/289595/11/tools/database-migration-from-v1-to-v2.py

2016-09-29 Thread Alex Stafeyev 
Hi

I am trying to execute the lbaas db upgrade procedure but I have several
question regarding this.

>From the patch:

I moved to /neutron-lbaas/neutron_lbaas/db/migration


 - Create a revision file
I executed "neutron-db-manage revision -m "description of revision"
--autogenerate"

At this point I saw an error:
ERROR [alembic.util.messaging] Multiple heads are present; please specify
the head revision on which the new revision should be based, or perform a
merge.
  FAILED: Multiple heads are present; please specify the head revision on
which the new revision should be based, or perform a merge.
[
 but checking history and migration  ( neutron-db-manage check_migration
and neutron-db-manage history) I saw no error.

No files seemed to be generated.

 - Edit the created file and fill the content properly with this file
This step is not clear to me ^
 - Run alembic upgrade head
What is the commend for that? (neutron-db-manage upgrade ? Did , fails)

 - Run the migration upgrade code
what is the best way to execute the command? ( python the_script.py?)

Kind regards
__
OpenStack Development Mailing 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] [sahara] Skip next meeting

2016-09-29 Thread Vitaly Gridnev 
Ok, next meeting is canceled.

On Wed, Sep 28, 2016 at 6:12 PM, Vitaly Gridnev 
wrote:

> Hi team,
>
> Since all of us are preparing for future summit and there is no specific
> topics to cover, I think that we should skip meeting tomorrow at Sept 29.
> If there is topic to discuss, please write email to mailing list about your
> topic.
>
> PS: Please, continue sharing your ideas about future summit, so I'm
> recommending to spend time of meeting for filling up etherpad [0] with your
> ideas.
>
> [0] https://etherpad.openstack.org/p/sahara-ocata-summit
>
> --
> Best Regards,
> Vitaly Gridnev,
> Project Technical Lead of OpenStack DataProcessing Program (Sahara)
> Mirantis, Inc
>



-- 
Best Regards,
Vitaly Gridnev,
Project Technical Lead of OpenStack DataProcessing Program (Sahara)
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tempest] Test case for new feature failed in Jenkins check against old release

2016-09-29 Thread Bruce Tan 

Hello everyone,

I am having a problem writing/updating a test case to verify some new
feature (in my case, the "description" field for a network).

Acoording to Tempest Coding Guide[1], I am supposed to check if the
related feature is there by @test.requires_ext() like this:
@test.requires_ext(extension="standard-attr-description",
   service="network")

And according to the same doc,
> When running a test that requires a certain "feature" in the target
> cloud, if that feature is missing we should fail, because either the
> test configuration is invalid, or the cloud is broken and the expected
> "feature" is not there even if the cloud was configured with it.


However, my patch[2] got a "-1" from Jenkins because one check
("gate-tempest-dsvm-neutron-full-ubuntu-trusty-liberty") failed. The
reason for failing, I think, is just what I quoted above: the
tempest.conf[3]  file is configured as
  [network-feature-enabled]api_extensions = all
which means any api_extension is supported; but the feature I am
testing is obviously not there in Liberty, so the API doesn't accept
"description" field, and the test case failed.

So my question is, what did I do wrong? Is there some other way
to skip the case for older releases? Or, maybe we shouldn't use
"api_extensions=all" (explicitly list all extensions instead, which
takes some effort obviously) in the configuration file?

Thank you in advance.

[1] 
http://docs.openstack.org/developer/tempest/HACKING.html#new-tests-for-new-features

[2] https://review.openstack.org/#/c/374645/
[3]
http://logs.openstack.org/45/374645/2/check/gate-tempest-dsvm-neutron-full-ubuntu-trusty-liberty/31bb416/logs/tempest_conf.txt.gz


--
Bruce Tan


__
OpenStack Development Mailing 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][neutron] neutron Newton RC3 available

2016-09-29 Thread Thierry Carrez 
Hello everyone,

A new release candidate for neutron for the end of the Newton cycle was
generated, to catch release-critical fixes and update to the latest
available translations. You can find the source code tarball at:

https://tarballs.openstack.org/neutron/neutron-9.0.0.0rc3.tar.gz

Unless new release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the final
Newton release on 6 October. You are therefore strongly encouraged to
test and validate this tarball!

Alternatively, you can directly test the stable/newton release branch at:

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/newton

As always, if you find an issue that could be considered
release-critical, please file it at:

https://bugs.launchpad.net/neutron/+filebug

and tag it *newton-rc-potential* to bring it to the neutron release
crew's attention.

Thanks!

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [release][mistral] mistral Newton RC2 available

2016-09-29 Thread Thierry Carrez 
Hello everyone,

A new release candidate for mistral for the end of the Newton cycle was
generated, to catch release-critical fixes. You can find the source code
tarball at:

https://tarballs.openstack.org/mistral/mistral-3.0.0.0rc2.tar.gz

Unless new release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the final
Newton release on 6 October. You are therefore strongly encouraged to
test and validate this tarball!

Alternatively, you can directly test the stable/newton release branch at:

http://git.openstack.org/cgit/openstack/mistral/log/?h=stable/newton

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/mistral/+filebug

and tag it *newton-rc-potential* to bring it to the mistral release
crew's attention.

Thanks!

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [release][horizon] horizon Newton RC2 available

2016-09-29 Thread Thierry Carrez 
Thierry Carrez wrote:
> A new release candidate for horizon for the end of the Newton cycle was
> generated, to catch release-critical fixes and include recent
> translations. You can find the source code tarball at:
> 
> [...]

Woops, missing link:
https://tarballs.openstack.org/horizon/horizon-10.0.0.0rc2.tar.gz

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] SRIOV-port refused to bind

2016-09-29 Thread Lenny Verkhovsky 
HI,
Did you configured everything according to 
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking?
( including intel_iommu=on ) ?
Can you attach more logs and config files of the nova/neutron/neutron plugins
Are you working with devstack or distro?


From: Murali B [mailto:mbi...@gmail.com]
Sent: Thursday, September 29, 2016 5:52 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] SRIOV-port refused to bind

Hi

I am using the SRIOV on mitaka. When I try to launch the VM with SRIOV port its 
failed.

When I see the neutrn-server.log I see that below message on controller.

ddf81 - - -] Refusing to bind due to unsupported vnic_type: direct bind_port 
/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/mech_agent.py:65
2016-09-28 18:55:18.384 16531 ERROR neutron.plugins.ml2.managers 
[req-443e9b6a-45c6-4b30-aa50-52a9b0a4926c 7d0ef58dd1214f54983c9d843fec0bde 
238c9900a2ae4b57b01fa72abdeddf81 - - -] Failed to bind port 
e96eadf3-5501-442a-8bcc-0b4d64617b26 on host A1-22932-compute1 for vnic_type 
direct using segments [{'segmentation_id': 123, 'physical_network': 
u'physnet1', 'id': u'30b77081-d02c-4e29-a41a-f8997c1f9f66', 'network_type': 
u'vlan'}]

On compute node I see the below error.

2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] flavor, virt_type, self._host)
2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482]   File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py", line 447, in 
get_config
2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] _("Unexpected vif_type=%s") % 
vif_type)
2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] NovaException: Unexpected 
vif_type=binding_failed

Could somebody help me to come-out this issue.


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

Re: [openstack-dev] [Keystone] Project name DB length

2016-09-29 Thread Boris Bobrov 

Hi,


At any rate, would be great to know, and if there isn't a strong reason
against it we can make project name 255 for some more flexibility.

Plus although there is no true official standard, most projects in
OpenStack seem to use 255 as the default for a lot of string fields.
Weirdly enough, a lot of projects seem to use 255 even for project.id,
which seeing as it's 64 in keystone, and a uuid4 anyway, seems like a
bit of a waste.


Feel free to fire some bugreports!


On 29/09/16 16:19, Steve Martinelli wrote:

We may have to ask Adam or Dolph, or pull out the history textbook for
this one. I imagine that trying to not bloat the token was definitely
a concern. IIRC User name was 64 also, but we had to increase to 255
because we're not in control of name that comes from external sources
(like LDAP).

On Wed, Sep 28, 2016 at 11:06 PM, Adrian Turjak
> wrote:

Hello Keystone Devs,

Just curious as to the choice to have the project name be only 64
characters:

https://github.com/openstack/keystone/blob/master/keystone/resource/backends/sql.py#L241



Seems short, and an odd choice when the user.name
 field is 255 characters:

https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql_model.py#L216



Is there a good reason for it only being 64 characters, or is this
just
something that was done a long time ago and no one thought about it?

Not hugely important, just seemed odd and may prove limiting for
something I'm playing with.

Cheers,
Adrian Turjak


__
OpenStack Development Mailing 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] [tripleo] Getting the UI to talk with Undercloud API service endpoints

2016-09-29 Thread Juan Antonio Osorio 
Actually, the third option is also not an option in the current undercloud
setup, since making the services listen in 0.0.0.0 will break HAProxy. So
when you're deploying with TLS things will break since we use HAProxy to
terminate TLS connections. On the other hand, we also don't want services
to listen on 0.0.0.0 since that would become a security concern. We should
instead be blocking everything we don't need to have exposed (as we've done
with the undercloud's database and rabbitmq).

Now, as we're trying to move to have more convergence between the
undercloud and the overcloud (trying to deploy the undercloud via heat
also, as Dan Prince has mentioned), I think some aspecs of this will bring
a solution to this problem. for instance, just like we already do in the
overcloud, we could have the undercloud's HAProxy always terminate the
endpoints, which I'm attempting with these two patches:
https://review.openstack.org/#/c/360366
https://review.openstack.org/#/c/360368 . Furthermore, we could have the
public endpoints in HAProxy listen on a separate network that's accessible
externally, also as we do in the overcloud. That way we don't need to
change the actual interfaces the services are listening on, and rely on
HAProxy, getting closer to how we do things in the overcloud. It seems to
me that it would help solve the problem.

On Wed, Sep 28, 2016 at 7:24 PM, Dan Trainor  wrote:

> Hi -
>
> I want to bring up a subject that needs a little more attention.  There
> are a few ideas floating around but it's important that we get this done
> right.
>
> UI is unique in the sense that it operates almost entirely in a browser,
> talking directly to service API endpoints which it either figures out from
> they Keystone service catalog as using the publicURL endpoint for each
> service, or by specifying these API endpoints in a configuration file.
> Though overriding the API endpoints in the UI's local configuration file is
> an option that's available, I understand that we want to move towards
> relying exclusively on Keystone for accurate and correct endpoint
> configuration.
>
> Right now, all of the service API endpoints that UI needs to talk with are
> only listening on the ctlplane network.
>
> We've had several iterations of testing and development of the UI over
> time and as a result of that, three different solutions that work -
> depending on the exact circumstances - have been created which all can
> achieve the same goal of allowing the UI to talk to these endpoints:
>
> - Local SSH port tunneling of the required ports that UI talks to, from
> the system running the UI to the Undercloud, and configuring the UI to talk
> to localhost:. This method "works", but it's not a solution we can
> recommend
> - Making the interface on which these services already listen on - the
> ctlplane network - routable.  Again, this method "works", but we treat this
> interface in a very special manner on purpose, not the least of which
> because of it's ability to facilitate pxebooting
> - Change the public endpoints in the Keystone catalog to be that of the
> existing external, routable interface of the Undercloud for each service
> required by the UI.  This also requires configuring each service that UI
> needs to talk with, to listen on the existing, external, routable interface
> on the Undercloud.  Some services support a list of interfaces and IPs to
> listen on; others require exactly one argument, in which case the address
> of 0.0.0.0 would need to be used
>
> According to the API Endpoint Configuration Recommendation guide[1], the
> third option seems most viable and one that we can recommend.  The document
> briefly describes the security implications of having these services open
> on a public interface but recommends the use of a stringent network policy
> - something we're used to recommending and helping with.  The first two
> options, not so much.
>
> Based on discussions I've had with other people, it's my impression that
> the third option is likely the one that we should proceed with.
>
> This concern is largely transparent to how we're currently testing and
> developing the UI because most of that work is done on local, virtualized
> environments.  When this happens, libvirt does the heavy lifting of
> creating a network that's easily routable from the host system.  If not
> that, then the evolution of instructions for setting up these local
> environments over time have recommended using SSH port forwarding.
> However, neither of these options should be recommended.
>
> Thoughts?
>
> Thanks
> -dant
>
> --
>
> P.S. and full disclosure:  I'm biased towards the third option.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan