[openstack-dev] [octavia]Request for change of irc meeting time

[Santhosh Fernandes]

Hi Michael and all,

Can we schedule our meeting couple of hours early on Wedneseday, So, few
more folks from India can join the meeting.

I am proposing new timing will be

PST 10:00 AM (EST 1:00 PM and IST 10:30 PM).

Meeting rooms are available during this time :

#openstack-meeting
#openstack-meeting-3
#openstack-meeting-4
#openstack-meeting-cp

Let us know your opinions. if all fine with this timing, we will move the
meeting.

Thank you,

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

[openstack-dev] [neutron] [l2gw] DSVM gates for networking-l2gw

[Ricardo Noriega De Soto]

Hello L2GWers

Currently networking-l2gw CI only covers unit tests. However, there is an
experimental check that starts a devstack VM to be able to run more complex
tests. That experimental check is not working, and we are trying to fix it,
however we encountered some difficulties that we wanted to share with you.

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

The configuration of the experimental check uses the L2GW agent which is
very good, however, the API tests try to create a l2gw connection and fail
since there is not an ovsdb instance with the vtep schema to execute.

If we use the dummy driver, these three failing testcases will be skipped
and we have a way to test the API (without backend).

So for now, our proposal is to modify this experimental check using the
dummy driver, and convert it to a possible non-voting -> voting gate
executing pure API tests.

Furthermore, we will start working on a new gate with the l2gw agent and
create a new OVS entity in a namespace or something similar to be able to
test api and agent together.

Any comment is more than welcome!

Thanks guys

-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] Meeting Thursday June 15th at 8:00 UTC (NOTE: time changed from 9UTC to 8UTC)

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, June 15th at 8:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_Jun_15th_2017_.280800_UTC.29

Anyone is welcome to add an item to the agenda.

-gmann

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

Re: [openstack-dev] [Product] PTG attendance

[Rochelle Grober]

In many ways, having the PWG at the PTG is a great idea.  The only problem with 
that is that the PWG and the InteropWG would overlap in the current way the PTG 
is arranged.  Having both at the same place is great for synergy, but having 
them at the same times is not :(  We actually have a chance to grow both teams 
through cross-pollination if we could arrange them not to overlap.

--Rocky

From: UKASICK, ANDREW [mailto:au3...@att.com]
Sent: Wednesday, June 14, 2017 4:29 PM
To: OpenStack Development Mailing List (not for usage questions) 
; user-commit...@lists.openstack.org; 
'Arkady Kanevsky (arkady.kanev...@dell.com)' 
Subject: Re: [User-committee] [Product] PTG attendance

Hi Arkady/Leong/Shamail

I don't know yet if I'll be attending the PTG in Denver, but at present, I 
think that it's unlikely.  If the PWG mid-cycle was co-located with the PTG, 
then I expect that I'd be able to attend at least the PWG days.

That said, contrary to what I thought in our meeting on Monday, it would work 
out better for me to have our PWG mid-cycle collocated with the Ops Meetup.

Thanks,

-Andy

Andrew Ukasick
Principal Systems Engineer
AT Integrated Cloud (AIC),  Openstack Community Coordination

From: arkady.kanev...@dell.com 
[mailto:arkady.kanev...@dell.com]
Sent: Tuesday, June 13, 2017 9:05 PM
To: openstack-dev@lists.openstack.org
Cc: 
user-commit...@lists.openstack.org
Subject: Re: [openstack-dev] [Product] PTG attendance

Fellow Product WG members,
We are taking informal poll on how many of us plan to attend
PTG meeting in Denver?

Second question should we have mid-cycle meeting co-located with PTG or with 
operator summit in Mexico city?

Please, respond to this email so Shamail and Leong can tally the results.
Thanks,
Arkady

Arkady Kanevsky, Ph.D.
Director of SW Development
Dell EMC CPSD
Dell Inc. One Dell Way, MS PS2-91
Round Rock, TX 78682, USA
Phone: 512 723 5264

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

Re: [openstack-dev] [Product] PTG attendance

[UKASICK, ANDREW]

Hi Arkady/Leong/Shamail

I don't know yet if I'll be attending the PTG in Denver, but at present, I 
think that it's unlikely.  If the PWG mid-cycle was co-located with the PTG, 
then I expect that I'd be able to attend at least the PWG days.

That said, contrary to what I thought in our meeting on Monday, it would work 
out better for me to have our PWG mid-cycle collocated with the Ops Meetup.

Thanks,

-Andy

Andrew Ukasick
Principal Systems Engineer
AT Integrated Cloud (AIC),  Openstack Community Coordination

From: arkady.kanev...@dell.com 
[mailto:arkady.kanev...@dell.com]
Sent: Tuesday, June 13, 2017 9:05 PM
To: openstack-dev@lists.openstack.org
Cc: 
user-commit...@lists.openstack.org
Subject: Re: [openstack-dev] [Product] PTG attendance

Fellow Product WG members,
We are taking informal poll on how many of us plan to attend
PTG meeting in Denver?

Second question should we have mid-cycle meeting co-located with PTG or with 
operator summit in Mexico city?

Please, respond to this email so Shamail and Leong can tally the results.
Thanks,
Arkady

Arkady Kanevsky, Ph.D.
Director of SW Development
Dell EMC CPSD
Dell Inc. One Dell Way, MS PS2-91
Round Rock, TX 78682, USA
Phone: 512 723 5264

__
OpenStack Development Mailing List (not for 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] Role updates

[Alex Schultz]

On Tue, Jun 13, 2017 at 11:11 AM, Alex Schultz  wrote:
> On Tue, Jun 13, 2017 at 6:58 AM, Dan Prince  wrote:
>> On Fri, 2017-06-09 at 09:24 -0600, Alex Schultz wrote:
>>> Hey folks,
>>>
>>> I wanted to bring to your attention that we've merged the change[0]
>>> to
>>> add a basic set of roles that can be combined to create your own
>>> roles_data.yaml as needed.  With this change the roles_data.yaml and
>>> roles_data_undercloud.yaml files in THT should not be changed by
>>> hand.
>>
>> In general I like the feature.
>>
>> I added some comments to your validations [1] patch below. We need
>> those validations, but I think we need to carefully consider adding a
>> hard dependency on python-tripleoclient simply to have validations in
>> tree. Wondering if perhaps a t-h-t-utils library project might be in
>> order here to contain routines we use in t-h-t and in higher level
>> workflow tools in Mistral and on the CLI? This might also make the
>> tools/process-templates.py stuff cleaner as well.
>>
>> Thoughts?
>
> So my original implementation of the roles stuff included a standalone
> script in THT to generate the roles_data.yaml files.  This was -1'd as
> realistically the actions for managing this should probably live
> within python-tripleoclient.  This made sense to me as that's how the
> end user really should be interacting with these things.  Given that
> the tripleoclient and the UI are the two ways and operator is going to
> consume with THT I think there is already an undocumented requirement
> that should be there.
>
> An alternative would be to move the roles generation items into
> tripleo-common but then we would have to write two distinct ways of
> then executing this code. One being tripleoclient and the other being
> a standalone script which basically would have to reinvent the
> interface provided by tripleoclient/openstackclient.  Since we're not
> allowing folks to dynamically construct the roles_data.yaml as part of
> the overcloud deployment yet, I'm not sure we should try and move this
> around further unless there's an agreed upon way we want to handle
> this.
>
> I think the better work would be to split the
> tripleoclient/instack-undercloud dependency which is really where the
> problem lies.  We shouldn't be pulling in the world for tripleoclient
> if we are just going to operate on only the overcloud.

As a follow up, I've taken some time to move the roles functions in to
tripleo-common[0] and out of tripleoclient[1]. With this, I've also
updated the validation patch with a small python script that leverages
the tripleo-common work.

Of course while writing this email I noticed that tripleo-common also
pulls in instack-undercloud[3] like tripleoclient[4] so I'm not sure
this is actually an improvement.  ¯\_(ツ)_/¯

Thanks,
-Alex

[0] https://review.openstack.org/#/c/474332/
[1] https://review.openstack.org/#/c/474343/
[2] https://review.openstack.org/#/c/472731/
[3] 
https://github.com/rdo-packages/tripleo-common-distgit/blob/rpm-master/openstack-tripleo-common.spec#L21
[4] 
https://github.com/rdo-packages/tripleoclient-distgit/blob/rpm-master/python-tripleoclient.spec#L36

>
> Thanks,
> -Alex
>
>>
>> Dan
>>
>>> Instead if you have an update to a role, please update the
>>> appropriate
>>> roles/*.yaml file. I have proposed a change[1] to THT with additional
>>> tools to validate that the roles/*.yaml files are updated and that
>>> there are no unaccounted for roles_data.yaml changes.  Additionally
>>> this change adds in a new tox target to assist in the generate of
>>> these basic roles data files that we provide.
>>>
>>> Ideally I would like to get rid of the roles_data.yaml and
>>> roles_data_undercloud.yaml so that the end user doesn't have to
>>> generate this file at all but that won't happen this cycle.  In the
>>> mean time, additional documentation around how to work with roles has
>>> been added to the roles README[2].
>>>
>>> Thanks,
>>> -Alex
>>>
>>> [0] https://review.openstack.org/#/c/445687/
>>> [1] https://review.openstack.org/#/c/472731/
>>> [2] https://github.com/openstack/tripleo-heat-templates/blob/master/r
>>> oles/README.rst
>>>
>>> _
>>> _
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
>>> cribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [api][horizon][all] Poorly Pagination UX

[McLellan, Steven]

This is what we envisaged for searchlight; a single endpoint to retrieve 
information across multiple services and regions to make it easier for a user 
of horizon (for instance) to ask those kinds of arbitrary questions about the 
current state of resources.

It's unfortunate our swift integration stalled a little; being able to run the 
kinds of searches across swift containers that are possible on your local 
filesystem still seems quite compelling.

Steve


 Original message 
From: Jay Pipes 
Date: 6/14/17 17:53 (GMT+00:00)
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [api][horizon][all] Poorly Pagination UX

On 06/14/2017 12:25 PM, John Dickinson wrote:
> What is this tracker service? elastic? glance? glare? searchlight? something 
> else? I don't know.

Searchlight (which is just ES under the hood with integration of various
notification queues for indexing automation).

Best,
-jay

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

Re: [openstack-dev] [api][horizon][all] Poorly Pagination UX

[Jay Pipes]

On 06/14/2017 12:25 PM, John Dickinson wrote:

What is this tracker service? elastic? glance? glare? searchlight? something 
else? I don't know.


Searchlight (which is just ES under the hood with integration of various 
notification queues for indexing automation).


Best,
-jay

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

Re: [openstack-dev] [all] os-api-ref 1.4.0 about to hit upper-constraints

[Matt Riedemann]

On 6/14/2017 6:01 AM, Sean Dague wrote:

There were some changes in Sphinx 1.6.x that removed functions that
os-api-ref was using to warn for validation. Which meant that when
things failed instead of getting the warning you got a huge cryptic
stack trace. :(


https://bugs.launchpad.net/openstack-doc-tools/+bug/1697736 if you want 
the dirty details.




Those are fixed in 1.4.0, however with the other changes in Sphinx about
how warnings work, I'm not 100% confident this is going to be smooth for
everyone. If you hit an issue in your api-ref building after this lands,
please pop up on #openstack-dev and we'll try to work through it.

-Sean




--

Thanks,

Matt

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

Re: [openstack-dev] [api][horizon][all] Poorly Pagination UX

[John Dickinson]

On 14 Jun 2017, at 9:03, Ivan Kolodyazhny wrote:

> Hi stackers,
>
>
>
> There are several bugs in Horizon [1], [2] and [3] related to pagination.
> TBH, these issues are reproducible via CLI too. Unfortunately, all of them
> are related to our API’s implementation [4].
>
> Bugs [1] and [2] can’t be fixed in current API’s implementations because we
> use ‘marker’ object in them [4]. We can try to implement some hacks on the
> Horizon’s side to play with ‘sort order’ param, but even that in some cases
> we can fix all bugs because we don’t have necessary params to good paging
> implementation.
>
> What does it mean? E.g:
>
> You have 2 volumes and 1 item per page like described at [5]. In this case,
> when we remove volume B we can’t open a page with volume A because current
> ‘marker’ is volume B and regardless to sort order API will return zero
> volumes with this marker.
>
> As a double workaround, we can redirect to the first page. But this makes
> Horizon UX more terrible when user has a lot of pages of instances,
> volumes, etc and want to delete several of them without using filtering
> feature.
>
> As an another option, we can do some hacks on the Horizon side, but it
> requires to make more API calls what is not a good option in big production
> deployments.
>
> As a long-term solution it could be good to change our API’s to have better
> paging. E.g. use ‘page number’ param instead of ‘marker’. API could also
> return total_page number so Horizon will be able to use these options to
> render paged tables well.

The problem with "page number" is that it completely breaks down for large 
sets. If I've got a few million items in a result set, finding the current page 
number and the total number of pages becomes very expensive server-side. Using 
the marker pattern allows for walking over the set and returning results 
without needing to know the total set at the time of creating the response.

Unfortunately, for the marker to work effectively, the result set needs to have 
a defined order, and this can end up pushing a lot of the work to the client[1] 
to provide nice sorting, searching, and pagination.

In an ideal world, I'd love to see a service that keeps track of the different 
"things" that are managed. Want to know all the server images created before 
Tuesday? Ask the tracker service. Want to know all the cat pictures smaller 
than 1MB and marked as having a blue background? Ask the tracker service. etc.

What is this tracker service? elastic? glance? glare? searchlight? something 
else? I don't know.

[1] In general, pushing work to the client is a fantastic idea, but it does 
come with a "cost", namely developer mental overhead.


--John



>
> In the world of microversions, we can implement such changes without
> breaking any existing API users and change API Guidelines with note about
> these changes.
>
> I’m glad to get any feedback from Horizon users, API WG and component teams
> if community is interested in this big cross-project effort.
>
> [1] https://bugs.launchpad.net/horizon/+bug/1564498
> [2] https://bugs.launchpad.net/horizon/+bug/1212174
> [3] https://bugs.launchpad.net/horizon/+bug/1274427
> [4]
> https://github.com/openstack/api-wg/blob/master/guidelines/pagination_filter_sort.rst
> [5] https://bugs.launchpad.net/horizon/+bug/1564498/comments/5
>
>
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/


> __
> OpenStack Development Mailing 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] [kolla][kolla-ansible] Proposing Surya (spsurya) for core

[Jeffrey Zhang]

+1 nice jobs ;)

On Wed, Jun 14, 2017 at 11:52 PM, Paul Bourke 
wrote:

> +1, thanks Surya for all your work
>
>
> On 14/06/17 16:46, Michał Jastrzębski wrote:
>
>> Hello,
>>
>> With great pleasure I'm kicking off another core voting to
>> kolla-ansible and kolla teams:) this one is about spsurya. Voting will
>> be open for 2 weeks (till 28th Jun).
>>
>> Consider this mail my +1 vote, you know the drill:)
>>
>> Regards,
>> Michal
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [api][horizon][all] Poorly Pagination UX

[Ivan Kolodyazhny]

Hi stackers,



There are several bugs in Horizon [1], [2] and [3] related to pagination.
TBH, these issues are reproducible via CLI too. Unfortunately, all of them
are related to our API’s implementation [4].

Bugs [1] and [2] can’t be fixed in current API’s implementations because we
use ‘marker’ object in them [4]. We can try to implement some hacks on the
Horizon’s side to play with ‘sort order’ param, but even that in some cases
we can fix all bugs because we don’t have necessary params to good paging
implementation.

What does it mean? E.g:

You have 2 volumes and 1 item per page like described at [5]. In this case,
when we remove volume B we can’t open a page with volume A because current
‘marker’ is volume B and regardless to sort order API will return zero
volumes with this marker.

As a double workaround, we can redirect to the first page. But this makes
Horizon UX more terrible when user has a lot of pages of instances,
volumes, etc and want to delete several of them without using filtering
feature.

As an another option, we can do some hacks on the Horizon side, but it
requires to make more API calls what is not a good option in big production
deployments.

As a long-term solution it could be good to change our API’s to have better
paging. E.g. use ‘page number’ param instead of ‘marker’. API could also
return total_page number so Horizon will be able to use these options to
render paged tables well.

In the world of microversions, we can implement such changes without
breaking any existing API users and change API Guidelines with note about
these changes.

I’m glad to get any feedback from Horizon users, API WG and component teams
if community is interested in this big cross-project effort.

[1] https://bugs.launchpad.net/horizon/+bug/1564498
[2] https://bugs.launchpad.net/horizon/+bug/1212174
[3] https://bugs.launchpad.net/horizon/+bug/1274427
[4]
https://github.com/openstack/api-wg/blob/master/guidelines/pagination_filter_sort.rst
[5] https://bugs.launchpad.net/horizon/+bug/1564498/comments/5



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

[openstack-dev] [infra] Status of Zuul v3

[James E. Blair]

Greetings!

This periodic update is primarily intended as a way to keep
contributors to the OpenStack community apprised of Zuul v3 project
status, including future changes and milestones on our way to use in
production. Additionally, the numerous existing and future users of
Zuul outside of the OpenStack community may find this update useful as
a way to track Zuul v3 development status.

If "changes are coming in the land of Zuul" is new news to you, please
read the section "About Zuul and Zuul v3" towards the end of this
email.

== Zuul v3 project status and updates ==

The biggest recent development is that basic support for GitHub has
merged!  Thanks to Jan, Tobias, Jonathan, Jamie, Jesse, and everyone
else that helped with that years-long effort!  We're still working to
achieve feature parity (notably, cross-repo dependency support hasn't
been implemented yet), but basic operations work and we have a good base
to start from.

We've also landed support for bubblewrap, so that untrusted job content
can run in a restricted environment.  This is a big improvement for
executor security.  Thanks to Clint and others who helped with this!

We merged support for live-streaming interleaved ansible logs and
console logs from all of the hosts in a job.  The streaming protocol is
compatible with finger, so you can easily request the log for a job by
running "finger UUID@executor".  That's handy for using unix tools to
deal with the output (think grep, sed, awk, etc).  To make this
accessible over the web, we are working on a websocket based console
streamer, which uses the finger-compatible endpoints on the backend.
When we're done, we'll have a nice web frontend for easily viewing
console logs linked to from the status page, and finger URLs for users
who want to view or process their logs from a unix shell.  Thanks to
David and Monty for work on this!

We've created some new repositories to hold Zuul jobs and the Ansible
roles that they use.  We're going to try something new here -- we want
to create a standard library of jobs that any Zuul installation (not
just those related to OpenStack) can use.  Flexibility and local
customization of jobs is very important in Zuul v3, but with job
inheritance and Ansible roles, we have two very useful methods of
composition that we can use to share job content so that not everyone
has to reinvent the wheel.  These are the repos we've created and how we
expect to use them:

  openstack-infra/zuul-jobs

This is what we're calling the "standard library".  We're going to
put any jobs which we think are not inherently OpenStack-specific.
For example, jobs to run python unit tests, java builds, go tests,
autoconf/makefile based projects, etc.

  openstack-infra/openstack-zuul-jobs

This is where we will put OpenStack-specific jobs (or
OpenStack-specific variants of standard library jobs).

In the near term, we're going to start populating these repos with what
we need for OpenStack's Zuul, and will probably move things around quite
a bit as we figure out where they should go.  We are also working on a
Sphinx extension (in the openstack-infra/zuul-sphinx repo) to
automatically document all of the jobs and roles in these repos.  We
should have self-documenting jobs with published documentation right
from the start.  Thanks to Paul for his help on this!

Also thanks to Paul for setting up OpenStack's production instance of
Zuul v3 at zuulv3.openstack.org server and our first executor at
ze01.openstack.org.  That's running now, and we're currently working
through some things that we deferred from setting up our dev instance,
notably log publishing.

With the approval of the nodepool drivers spec:

  
http://specs.openstack.org/openstack-infra/infra-specs/specs/nodepool-drivers.html

Tristan has started work on an implementation supporting multiple
backend drivers for nodepool.  This will initially include a driver for
static nodes, and later we will use this to support multiple cloud
technologies:

  http://lists.openstack.org/pipermail/openstack-infra/2017-June/005387.html

Tristan has also proposed a proof-of-concept implementation of a
dashboard for Zuul, which has prompted a conversation about web
frameworks:

  http://lists.openstack.org/pipermail/openstack-infra/2017-June/005402.html

We're working to come to consensus on that so that we can ultimately
converge our webhooks, status page, websocket console streaming, and
dashboard onto one framework.

Upcoming tasks and focus:
* Re-enabling disabled tests: We're continuing to make our way through
the list of remaining tests that need enabling. See the list, which
includes an annotation as to complexity for each test, here:
https://etherpad.openstack.org/p/zuulv3skips
* Github parity
* Log streaming
* Standard jobs
* Set up production zuulv3.openstack.org server
* Full task list and plan is in the Zuul v3 storyboard:
https://storyboard.openstack.org/#!/board/41

Recent changes:
* Zuul v3:

Re: [openstack-dev] [rally][no-admin] Finally Rally can be run without admin user

[Lance Bragstad]

On Tue, Jun 13, 2017 at 3:51 PM, Morgan Fainberg 
wrote:

> On Tue, Jun 13, 2017 at 1:04 PM, Boris Pavlovic  wrote:
> > Hi stackers,
> >
> > Intro
> >
> > Initially Rally was targeted for developers which means running it from
> > admin was OK.
> > Admin was basically used to simplify preparing environment for testing:
> > create and setup users/tenants, networks, quotas and other resources that
> > requires admin role.
> > As well it was used to cleanup all resources after test was executed.
> >
> > Problem
> >
> > More and more operators were running Rally against their production
> > environments, and they were not happy with the thing that they should
> > provide admin, they would rather prepare environment by hand and provide
> > already existing users than allow Rally to mess up with admin rights =)
> >
> > Solution
> >
> > After years of refactoring we changed almost everything;) and we managed
> to
> > keep Rally as simple as it was and support Operators and Developers
> needs.
> >
> > Now Rally supports 3 different modes:
> >
> > admin mode -> Rally manages users that are used for testing
> > admin + existing users mode -> Rally uses existing users for testing (if
> no
> > user context)
> > [new one] existing users mode -> Rally uses existing users for testing
> >
> > In every mode input task will look the same, however in case of only
> > existing users mode you won't be able to use plugins that requires admin
> > role.
> >
> > This patch finishes works: https://review.openstack.org/#/c/465495/
> >
> > Thanks to everybody that was involved in this huge effort!
> >
> >
> > Best regards,
> > Boris Pavlovic
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> Good work, and fantastic news. This will make rally a more interesting
> tool to use against real-world deployments.
>
> Congrats on a job well done.
>

I completely agree here. Nice work!


> --Morgan
>
> __
> OpenStack Development Mailing List (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][kolla-ansible] Proposing Surya (spsurya) for core

[Paul Bourke]

+1, thanks Surya for all your work

On 14/06/17 16:46, Michał Jastrzębski wrote:

Hello,

With great pleasure I'm kicking off another core voting to
kolla-ansible and kolla teams:) this one is about spsurya. Voting will
be open for 2 weeks (till 28th Jun).

Consider this mail my +1 vote, you know the drill:)

Regards,
Michal

__
OpenStack Development Mailing List (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] [kolla][kolla-ansible] Proposing Surya (spsurya) for core

[Michał Jastrzębski]

Hello,

With great pleasure I'm kicking off another core voting to
kolla-ansible and kolla teams:) this one is about spsurya. Voting will
be open for 2 weeks (till 28th Jun).

Consider this mail my +1 vote, you know the drill:)

Regards,
Michal

__
OpenStack Development Mailing List (not for 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][nova] Goodbye^W See you later

[Loo, Ruby]

I was hoping that if I ignored this, it wouldn't be true. Who am I kidding... 
sigh... sob...

Good bye Jim, last of the Js (Josh, Jay) from Rackspace, thank you for IPA, for 
sacrificing yourself and being PTL, for sacrificing yourself and talking to the 
nova folks :-), and for everything else you brought to ironic!

Needless to say, I have, and will, miss you.

Good luck Jim, I know you'll go on to do great things!

--ruby


From: Jim Rollenhagen 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, June 8, 2017 at 8:45 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [ironic][nova] Goodbye^W See you later

Hey friends,

I've been mostly missing for the past six weeks while looking for a new job, so 
maybe you've forgotten me already, maybe not. I'm happy to tell you I've found 
one that I think is a great opportunity for me. But, I'm sad to tell you that 
it's totally outside of the OpenStack community.

The last 3.5 years have been amazing. I'm extremely grateful that I've been 
able to work in this community - I've learned so much and met so many awesome 
people. I'm going to miss the insane(ly awesome) level of collaboration, the 
summits, the PTGs, and even some of the bikeshedding. We've built amazing 
things together, and I'm sure y'all will continue to do so without me.

I'll still be lurking in #openstack-dev and #openstack-ironic for a while, if 
people need me to drop a -2 or dictate old knowledge or whatever, feel free to 
ping me. Or if you just want to chat. :)

<3 jroll

P.S. obviously my core permissions should be dropped now :P
__
OpenStack Development Mailing List (not for 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] Future of the tripleo-quickstart-utils project

[Raoul Scarazzini]

On 13/06/2017 21:14, Emilien Macchi wrote:
[...]>> Moving this stuff in the tripleo-validations project would impose a
>> massive change in the approach HA validation is made today.
>> The bash script way is something that was used to make someone able to
>> do the validation even without ansible. Anyone could write his test by
>> just adding the script inside the test (and recovery) dir.
>> This is the tech reason behind the choice, and today this is doing great
>> as it is.
>> So I think that until I can reserve a slot to make this "port" this can
>> stay where it is today.
> It's unclear to me if yes or no you're willing to move this bash
> script into tripleo-validations.

Mine it's basically a yes, I just need to figure out a coherent
migration path. I don't see this as a thing I can do one day to another,
but I'll start working on it.

[...]>> Since we're moving into integrating stonith and (hopefully)
instance HA
>> directly inside tripleo, then this can stay where it is today, it would
>> be useless giving effort in putting this since soon we will have the
>> same directly inside tripleo.
> Ok, so forget this one if the problem is solved within TripleO.

Yes, this seems reasonable.

[...]
>>> I would suggest to move it to tripleo-docs, so we have a single place for 
>>> doc.
>> Action item for me here: move this document under tripleo-docs. I'm
>> already preparing a review for this.

So I finally updated a review [1] for the documentation, it took quite a
bit to adapt it to the audience of the tripleo-docs project, but it now
seems fine... at least to me :)

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

Many thanks for your time Emilien.

-- 
Raoul Scarazzini
ra...@redhat.com

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

[openstack-dev] [Acceleration]Cyborg Team Weekly Meeting 2017.06.14

[Zhipeng Huang]

Hi Team,

A kind reminder for our regular meeting today at #openstack-cyborg
startging ET 11:00 am. Initial agenda could be found at
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting .

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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

Re: [openstack-dev] [EXTERNAL] Re: [Tripleo] deploy software on Openstack controller on the Overcloud

[Abhishek Kane]

Thank you for the comments Emilien!

Updated as per your suggestions:
puppet-veritas-hyperscale: 
https://github.com/abhishek-kane/puppet-veritas-hyperscale

Also, please find the inline replies to your comments.

We had been able to call the old puppet modules (which had scripts) using the 
generic puppet way (puppet agent --test). But we are unable to deploy the new 
puppet modules (which use existing puppet classes) the tripleo way. Following 
paste shows a sample puppet module which we are trying to deploy on an 
overcloud which is already deployed. We see that our resources are in 
“CREATE_COMPLETE” status, but the actual operation hasn’t happened.
http://paste.openstack.org/show/612537/

Regards,
Abhishek

On 6/14/17, 1:18 AM, "Emilien Macchi"  wrote:

On Wed, Jun 7, 2017 at 10:38 AM, Abhishek Kane
 wrote:
> Hi,
>
> On cinder node- we need to modify the cinder.conf. We don’t change any 
config apart from this. We want to keep the config changes in heat template, 
package installation in puppet, and trigger rest of the operations via Horizon 
(as it’s done today). We are also trying to get rid of the nova.conf file 
changes. Once the approach for cinder is sorted, will get back on this.
>
> If this is correct approach for cinder, I will raise review requests for 
the following projects:
> puppet-tripleo: http://paste.openstack.org/show/611697/
> puppet-cinder: http://paste.openstack.org/show/611698/
> tripleo-heat-templates: http://paste.openstack.org/show/611700/
>
> Also, I am not sure which TripleO repos need to be patched for the 
controller components.
>
> We have decomposed the controller bin installer into idempotent 
modules/scripts. Now, the installer is not a black box operation:
> https://github.com/abhishek-kane/puppet-veritas-hyperscale
> The inline replies below are w.r.t. this project. The product installer 
bin currently works in atomic fashion. One issue which we see in puppet is the 
error handling and rollback operations.
>
> Thanks,
> Abhishek
>
> On 6/1/17, 8:41 PM, "Emilien Macchi"  wrote:
>
> On Thu, Jun 1, 2017 at 3:47 PM, Abhishek Kane 
 wrote:
> > Hi Emilien,
> >
> > The bin does following things on controller:
> > 1. Install core HyperScale packages.
>
> Should be done by Puppet, with Package resource.
> Ak> It’s done.
>
> > 2. Start HyperScale API server
>
> Should be done by Puppet, with Service resource.
> AK> It’s done.
>
> > 3. Install UI packages. This will add new files to and modify some 
existing files of Horison.
>
> Should be done by Puppet, with Package resource and also some changes
> in puppet-horizon maybe if you need to change Horizon config.
> Ak> We have got rid of the horizon dependency right now. Our GUI 
components get installed via separate package.
>
> > 4. Create HyperScale user in mysql db. Create database and dump 
config. Add permissions of nova and cinder DB to HyperScale user.
>
> We have puppet-openstacklib which already manages DBs, you could
> easily re-use it. Please look at puppet-nova for example to see how
> things works in nova::db::mysql, etc.
> AK> TBD
>
> > 5. Add ceilometer pollsters for additional stats and modify 
ceilometer files.
>
> puppet-ceilometer I guess. What do you mean by "files"? Config files?
> Ak> We are trying to get rid of this dependency as well. TBD.
>
> > 6. Change OpenStack configuration:
> > a. Create rabbitmq exchanges
>
> puppet-* modules already does it.
> AK> It’s done via script. Do we need to patch any module?

Everything that touch *.conf files of OpenStack services need to be
done by existing openstack/puppet-* modules.

AK> 
https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/hs_rabbitmq.pp
 We are still doing some operation via script, but it’s idempotent.

>
> > b. Create keystone user
>
> puppet-keystone already does it.
> AK> It’s done via script. Do we need to patch keystone module?

No, you'll need to create the right user/roles/endpoints/... in
puppet-tripleo, in a new profile, most probably.
You'll probably need to read a bit about:
https://github.com/openstack/puppet-keystone#setup
Let me know if you need more help on this thing.

AK> I have already. 
https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/hs_keystone.pp

>
> > c. Define new flavors
>
> puppet-nova can manage flavors.
> AK> It’s done via script. Do we need to patch nova module?

Same as Keystone.
See: 

[openstack-dev] [all] os-api-ref 1.4.0 about to hit upper-constraints

[Sean Dague]

There were some changes in Sphinx 1.6.x that removed functions that
os-api-ref was using to warn for validation. Which meant that when
things failed instead of getting the warning you got a huge cryptic
stack trace. :(

Those are fixed in 1.4.0, however with the other changes in Sphinx about
how warnings work, I'm not 100% confident this is going to be smooth for
everyone. If you hit an issue in your api-ref building after this lands,
please pop up on #openstack-dev and we'll try to work through it.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [sahara] Sahara-ci is down

[Telles Nobrega]

Thanks for the info Evgeny. I'm looking for a new place for the CI and will
let everyone knows once we get some resources to deploy it.



On Wed, Jun 14, 2017 at 4:32 AM Evgeny Sikachev 
wrote:

> Hi, guys!
>
> Today I got the information about sahara-ci servers. They have been
> returned to the data center and unfortunately, we cannot use the sahara-ci
> for testing our patches.
>
> We need to find a new place for storing sahara-ci service. If you have any
> ideas it will be very useful. I am ready to help in setting up new servers
> and deploying our structure of CI or something else.
>
>
> P.S. My new email is esikac...@gmail.com
>
> -
> Best Regards,
>
> Evgeny Sikachev
> QA Engineer
> 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
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

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

Re: [openstack-dev] [horizon] Approach for bugs in xstatic packages

[Radomir Dopieralski]

I can see several possible ways forward with this:

* provide a complete fix for the issue that would be more likely to get
merged upstream,
* instead of adding hacks in the code, actually rename the wrongly named
files,
* instead of adding hacks, actually fix all the references to use proper
capitalization,
* if everything else fails, look for a better supported project that
provides this functionality.



On Tue, Jun 13, 2017 at 11:25 PM, Mateusz Kowalski  wrote:

> Hi everyone,
>
> I would like to raise a question about our approach to xstatic packages,
> more specifically xstatic-roboto-fontface, and its updates/bugfixes. What
> we have encountered was https://bugs.launchpad.net/horizon/+bug/1671004 what
> according to our knowledge affects everyone using stable/ocata with
> Material design (though I get there may not be many operators using this
> setup).
>
> What I did at the very first was to submit a patch https://review.
> openstack.org/#/c/443025/ but unfortunately a policy is to take xstatic
> packages from the upstream in their unchanged form. As I totally understand
> this, I raised this issue to the upstream package provider in March —
> https://github.com/choffmeister/roboto-fontface-bower/issues/41. Again,
> unfortunately, as since then there was no any response I submitted a merge
> request for this issue — https://github.com/choffmeister/roboto-fontface-
> bower/pull/47. However, it’s complete openstack-wise, but it does not
> solve the issue in general (long story short, more than just one file
> requires patching, but Horizon uses only the one I have patched).
>
> Anyway, seeing no much response for my initial upstream report since
> March, I don’t have much hope with the merge request I have just submitted.
> From the other side, any advice on how I can proceed in this particular
> case would be helpful as I have no any experience in this kind of workflow
> (bugs in xstatic packages).
>
> Thanks for any suggestions,
> Mateusz
>
> __
> OpenStack Development Mailing List (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] [Product] PTG attendance

[Thierry Carrez]

arkady.kanev...@dell.com wrote:
> Fellow Product WG members,
> 
> We are taking informal poll on how many of us plan to attend
> PTG meeting in Denver?
> 
> Second question should we have mid-cycle meeting co-located with PTG or
> with operator summit in Mexico city?

Note that we set aside a room for 2 days (Monday and Tuesday) for use by
the User Committee and its subteams (in particular the Product Working
Group). Looking forward the results of this consultation, to confirm
that room usage. Also if you have any idea of how many people would
join, we could size the room accordingly.

-- 
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] [sahara] Sahara-ci is down

[Evgeny Sikachev]

Hi, guys!

Today I got the information about sahara-ci servers. They have been
returned to the data center and unfortunately, we cannot use the sahara-ci
for testing our patches.

We need to find a new place for storing sahara-ci service. If you have any
ideas it will be very useful. I am ready to help in setting up new servers
and deploying our structure of CI or something else.


P.S. My new email is esikac...@gmail.com

-
Best Regards,

Evgeny Sikachev
QA Engineer
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