Re: [Openstack-operators] [openstack-dev] [nova] Default scheduler filters survey

[Massimo Sgaravatto]

enabled_filters =
AggregateInstanceExtraSpecsFilter,AggregateMultiTenancyIsolation,RetryFilter,AvailabilityZoneFilter,RamFilter,CoreFilter,AggregateRamFilter,AggregateCoreFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter

Cheers, Massimo

On Wed, Apr 18, 2018 at 10:20 PM, Simon Leinen 
wrote:

> Artom Lifshitz writes:
> > To that end, we'd like to know what filters operators are enabling in
> > their deployment. If you can, please reply to this email with your
> > [filter_scheduler]/enabled_filters (or
> > [DEFAULT]/scheduler_default_filters if you're using an older version)
> > option from nova.conf. Any other comments are welcome as well :)
>
> We have the following enabled on our semi-public (academic community)
> cloud, which runs on Newton:
>
> AggregateInstanceExtraSpecsFilter
> AvailabilityZoneFilter
> ComputeCapabilitiesFilter
> ComputeFilter
> ImagePropertiesFilter
> PciPassthroughFilter
> RamFilter
> RetryFilter
> ServerGroupAffinityFilter
> ServerGroupAntiAffinityFilter
>
> (sorted alphabetically) Recently we've also been trying
>
> AggregateImagePropertiesIsolation
>
> ...but it looks like we'll replace it with our own because it's a bit
> awkward to use for our purpose (scheduling Windows instance to licensed
> compute nodes).
> --
> Simon.
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] Nova VNC console broken

[Bernd Bausch]

According to the command output that you posted, the first API that
fails is this:

GET http://controller:8774/v2.1/servers/zktubntu 

It's the equivalent of openstack server show zktubntu. I wonder if you
run console url show as the owner of that instance, or as admin. As
admin, you can't find an instance by its name (except if the instance is
owned by admin).

What happens if you issue the server show command? What happens if you
issue console url show with the instance ID instead of its name?

In any case, it would be useful to check the Nova logs to understand why
this API fails.

On 4/21/2018 4:36 AM, Torin Woltjer wrote:
> After setting up HA for my openstack cluster, the nova console no longer 
> works. Nothing of note appears in any of the logs at /var/log/nova on the 
> controller or the compute node running the instance. I get a single line that 
> looks relevant output to /var/log/apache2/errors.log on the controller node:
>
> [Fri Apr 20 15:14:07.666495 2018] [wsgi:error] [pid 25807:tid 
> 139801204832000] WARNING horizon.exceptions Recoverable error: No available 
> console found.
>
> Trying to run the command "openstack console url show" with a verbosity of 2 
> outputs the following:
> http://paste.openstack.org/show/719660/
>
> Does anybody know the solution to this or of any way that I can further 
> troubleshoot the issue?
>
> Thanks,
>
>
>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [tc] campaign question related to new projects

[Zhipeng Huang]

As the one who just lead a new project into governance last year, I think I
could take a first stab at it.

For me the current requirements in general works fine, as I emphasized in
my recent blog [0], the four opens are extremely important. Open Design is
one of the most important out the four I guess, because it actually will
lead to the diversity question. A team with a single vendor, although it
could satisfy all the other three easily, could not have a good open design
rather well.

Another criteria (more related to the mission statement specifically) I
would consider important is the ability to demonstrate (1)its scope does
not overlap with existing official projects and (2) its ability to actively
work with related projects. The cross project collaboration does not have
to be waited after the project got anointed, rather started when the
project is in conception.

Well I guess that is my two cents :)

[0] https://hannibalhuang.github.io/



On Sat, Apr 21, 2018 at 5:26 AM, Doug Hellmann 
wrote:

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> We are discussing adding at least one new project this cycle, and
> the specific case of Adjutant has brought up questions about the
> criteria we use for evaluating new projects when they apply to
> become official.  Although the current system does include some
> well-defined requirements [1], it was also designed to rely on TC
> members to use their judgement in some other areas, to account for
> changing circumstances over the life of the project and to reflect
> the position that governance is not something we can automate away.
>
> Without letting the conversation devolve too much into a discussion
> of Adjutant's case, please talk a little about how you would evaluate
> a project's application in general.  What sorts of things do you
> consider when deciding whether a project "aligns with the OpenStack
> Mission," for example?
>
> Doug
>
> [1] https://governance.openstack.org/tc/reference/new-projects-
> requirements.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
>



-- 
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] [cyborg][release][Release-job-failures] Pre-release of openstack/cyborg failed

[Zhipeng Huang]

Thanks Doug we will take a look into it

On Sat, Apr 21, 2018 at 12:02 AM, Doug Hellmann 
wrote:

> Excerpts from zuul's message of 2018-04-20 13:59:14 +:
> > Build failed.
> >
> > - release-openstack-python http://logs.openstack.org/fa/
> fabeaffa6efe8b1ef3d828f5b8c2cdc896e4afe9/pre-release/
> release-openstack-python/c624655/ : FAILURE in 6m 07s
> > - announce-release announce-release : SKIPPED
> > - propose-update-constraints propose-update-constraints : SKIPPED
> >
>
> The cyborg milestone release failed to build because the packaging step
> could not find some expected rootwrap files:
>
> http://logs.openstack.org/fa/fabeaffa6efe8b1ef3d828f5b8c2cd
> c896e4afe9/pre-release/release-openstack-python/
> c624655/job-output.txt.gz#_2018-04-20_13_58_20_454319
>
> 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
>



-- 
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] Nova VNC console broken

[Erik McCormick]

Could you describe your HA set up a little bit? I assume your controllers
are behind a load balancer. Did you alter the novnc URL to point to the
virtual ip?

-Erik

On Apr 20, 2018 3:43 PM, "Torin Woltjer" 
wrote:

After setting up HA for my openstack cluster, the nova console no longer
works. Nothing of note appears in any of the logs at /var/log/nova on the
controller or the compute node running the instance. I get a single line
that looks relevant output to /var/log/apache2/errors.log on the controller
node:

[Fri Apr 20 15:14:07.666495 2018] [wsgi:error] [pid 25807:tid
139801204832000] WARNING horizon.exceptions Recoverable error: No available
console found.

Trying to run the command "openstack console url show" with a verbosity of
2 outputs the following:
http://paste.openstack.org/show/719660/

Does anybody know the solution to this or of any way that I can further
troubleshoot the issue?

Thanks,
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [tc] campaign question related to new projects

[Doug Hellmann]

[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]

We are discussing adding at least one new project this cycle, and
the specific case of Adjutant has brought up questions about the
criteria we use for evaluating new projects when they apply to
become official.  Although the current system does include some
well-defined requirements [1], it was also designed to rely on TC
members to use their judgement in some other areas, to account for
changing circumstances over the life of the project and to reflect
the position that governance is not something we can automate away.

Without letting the conversation devolve too much into a discussion
of Adjutant's case, please talk a little about how you would evaluate
a project's application in general.  What sorts of things do you
consider when deciding whether a project "aligns with the OpenStack
Mission," for example?

Doug

[1] https://governance.openstack.org/tc/reference/new-projects-requirements.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

[openstack-dev] [keystone] Keystone Team Update - Week of 16 April 2018

[Colleen Murphy]

# Keystone Team Update - Week of 16 April 2018

## News

### Retrospective scheduled

We're planning on having our milestonely team retrospective next week 
immediately after the weekly meeting[1]. We usually do this as a video 
conference. Come with your feedback!

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129444.html

### Milestone releases

We released our main libraries and keystone for Milestone 1 of the Rocky 
cycle[2][3][4][5].

[2] https://review.openstack.org/562735
[3] https://review.openstack.org/562730
[4] https://review.openstack.org/562723
[5] https://review.openstack.org/562732

### Forum topics submitted

We submitted topic proposals for the Vancouver Forum[6]. We're proposing to 
discuss the next stage of Unified Limits[7], the default roles cross-project 
initiative[8], and have a standard feedback session[9]. We opted not to submit 
anything on application credentials since we think there is not much 
controversy over the projected direction (mainly adding fine-grained access 
control).

[6] https://etherpad.openstack.org/p/YVR-keystone-forum-sessions
[7] http://forumtopics.openstack.org/cfp/details/130
[8] http://forumtopics.openstack.org/cfp/details/131
[9] http://forumtopics.openstack.org/cfp/details/132

### JWT still under discussion

There are still a number of open questions[10] on the design of the proposed 
JWT token provider[11]. We're not sure if the token ought to be encrypted 
(fernet tokens are) and we're not sure whether we want symmetric or asymmetric 
signing (and encryption). Part of the issue is that we don't have a specific 
ask from stakeholders, so this is mostly all in "it would be nice" territory. 
The latest revision of the spec has been updated to include potential use 
cases. If you have a vested interest in this work, please engage with us on the 
spec.

[10] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-04-17.log.html#t2018-04-17T17:37:43
[11] https://review.openstack.org/541903

### Default roles cross-project spec

The keystone team is satisfied with the current state of the cross-project spec 
to agree upon a set of default roles across projects[12] but we need more 
feedback and eventual approval from cross-project liasons[13]. If you have 
input or questions, please reach out to us.

[12] https://review.openstack.org/523973
[13] https://review.openstack.org/#/admin/groups/1372,members

## Open Specs

Search query: https://goo.gl/eyTktx

No new specs have been proposed for Rocky this week, and today is the deadline 
so we'll only expect to continue refinement of the current proposals.

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 14 changes this week.

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 55 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

These week we opened 7 new bugs and fixed 4 bugs across keystone, keystoneauth, 
keystonemiddleware, python-keystoneclient, and oslo.policy.

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

The time for submitting spec ideas is over. We'll continue to refine the 
current proposals until the Rocky-2 deadline in about six weeks.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter

__
OpenStack Development Mailing 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-Infra] Stop supporting bindep-fallback.txt moving forward

[Paul Belanger]

On Fri, Apr 20, 2018 at 05:34:09PM +, Jeremy Stanley wrote:
> On 2018-04-20 12:31:24 -0400 (-0400), Paul Belanger wrote:
> [...]
> > That is fine, if we want to do the mass migration to bionic first,
> > then start looking at which projects are still using
> > bindep-fallback.txt is fine with me.
> > 
> > I just wanted to highlight I think it is time we start pushing a
> > little harder on projects to stop using this logic and start
> > managing bindep.txt themself.
> 
> Yep, this is something I _completely_ agree with. We could even
> start with a deprecation warning in the fallback path so it starts
> showing up more clearly in the job logs too.
> -- 
> Jeremy Stanley

Okay, looking at codesearch.o.o, I've been able to start pushing up changes to
remove bindep-fallback.txt.

https://review.openstack.org/#/q/topic:bindep.txt

This adds bindep.txt to projects that need it, and also removes the legacy
install-distro-packages.sh scripts in favor of our bindep role.

Paul

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [all][requirements] uncapping eventlet

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-04-11 12:20:46 -0400:
> Excerpts from Matthew Thode's message of 2018-04-05 10:47:37 -0500:
> > eventlet-0.22.1 has been out for a while now, we should try and use it.
> > Going to be fun times.
> > 
> > I have a review projects can depend upon if they wish to test.
> > https://review.openstack.org/533021
> 
> I have proposed a bunch of patches to projects to remove the cap
> for eventlet [1]. If they don't pass tests, please take them over
> and fix them up as needed (I anticipate some trouble with the new
> check-requirements rules, for example).
> 
> Doug
> 
> [1] 
> https://review.openstack.org/#/q/topic:uncap-eventlet+(status:open+OR+status:merged)

We have made great progress on this but we do still have quite a
few of these patches that have not been approved.  Many are failing
test jobs and will need a little attention ( the failing requirements
jobs are real problems and rechecking will not fix them).  If you
have time to help, please jump in and take over a patch and get it
working.

https://review.openstack.org/#/q/status:open+topic:uncap-eventlet

Thanks,
Doug

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

[Openstack] Nova VNC console broken

[Torin Woltjer]

After setting up HA for my openstack cluster, the nova console no longer works. 
Nothing of note appears in any of the logs at /var/log/nova on the controller 
or the compute node running the instance. I get a single line that looks 
relevant output to /var/log/apache2/errors.log on the controller node:

[Fri Apr 20 15:14:07.666495 2018] [wsgi:error] [pid 25807:tid 139801204832000] 
WARNING horizon.exceptions Recoverable error: No available console found.

Trying to run the command "openstack console url show" with a verbosity of 2 
outputs the following:
http://paste.openstack.org/show/719660/

Does anybody know the solution to this or of any way that I can further 
troubleshoot the issue?

Thanks,


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [tripleo] Reminder about openstack/instack-undercloud contributions

[Emilien Macchi]

In case you missed it, the TripleO team is working on making the
containerized undercloud by default during Rocky.

It means that any patch in instack-undercloud won't probably be useful for
Rocky, unless you need to backport something in stable branches then fine.
Anything that is new, has to be ported in tripleoclient and
tripleo-heat-templates.

Feel free to reach out on #tripleo if you have any question!

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

Re: [openstack-dev] [tripleo] roadmap on containers workflow

[Emilien Macchi]

So the role has proven to be useful and we're now sure that we need it to
deploy a container registry before any container in the deployment, which
means we can't use the puppet code anymore for this service.

I propose that we move the role to OpenStack:
https://review.openstack.org/#/c/563197/
https://review.openstack.org/#/c/563198/
https://review.openstack.org/#/c/563200/

So we can properly peer review and gate the new role.

In the meantime, we continue to work on the new workflow.
Thanks,

On Sun, Apr 15, 2018 at 7:24 PM, Emilien Macchi  wrote:

> On Fri, Apr 13, 2018 at 5:58 PM, Emilien Macchi 
> wrote:
>
>>
>> A bit of progress today, I prototyped an Ansible role for that purpose:
>> https://github.com/EmilienM/ansible-role-container-registry
>>
>> The next step is, I'm going to investigate if we can deploy Docker and
>> Docker Distribution (to deploy the registry v2) via the existing composable
>> services in THT by using external_deploy_tasks maybe (or another interface).
>> The idea is really to have the registry ready before actually deploying
>> the undercloud containers, so we can modify them in the middle (run
>> container-check in our case).
>>
>
> This patch: https://review.openstack.org/#/c/561377 is deploying Docker
> and Docker Registry v2 *before* containers deployment in the docker_steps.
> It's using the external_deploy_tasks interface that runs right after the
> host_prep_tasks, so still before starting containers.
>
> It's using the Ansible role that was prototyped on Friday, please take a
> look and raise any concern.
> Now I would like to investigate how we can run container workflows between
> the deployment and docker and containers deployments.
> --
> 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] Glance image definition using V2 API

[Remo Mattei]

Here is a script I use on the fly..


for i in $(ls -l *.img |awk -F " " '{print $9}'); do openstack image create 
--disk-format qcow2 --container-format bare --public --file $i $i; done



> On Apr 20, 2018, at 02:04, Cory Hawkless  wrote:
> 
> Are you referring to 
> https://developer.openstack.org/api-ref/image/v2/#create-an-image 
>  ?
> There seems to be no support for specifying a location in the API V2 
> create-image call (POST /v2/images)
> Perhaps the location attribute could be updated after creation using the 
> update-image call (PATCH /v2/images) but I couldn't find a definitive answer 
> on that
> 
> 
> -Original Message-
> From: Remo Mattei [mailto:r...@italy1.com] 
> Sent: Thursday, 19 April 2018 5:00 PM
> To: Cory Hawkless 
> Cc: openstack@lists.openstack.org
> Subject: Re: [Openstack] Glance image definition using V2 API
> 
> Did you look at the Openstack commas api options? I am traveling now but I 
> could check it later. 
> 
> Inviato da iPhone
> 
>> Il giorno 19 apr 2018, alle ore 06:15, Cory Hawkless  
>> ha scritto:
>> 
>> Looking for some help with defining glance images. I'm running a new Queens 
>> installation and do not have the V1 API enabled in Glance.
>> 
>> So the Glance V1 API has been deprecated for some time now (I believe) and 
>> best I can tell there is no support in the V2 API for defining an existing 
>> image into glance.
>> I.E, I have some volumes in my Ceph pool that I'd like to expose to Glance, 
>> but the old method of using "glance image-create --disk-format raw --id 
>> $IMAGE_ID  --location rbd://$CLUSTER_ID/$POOL/$IMAGE_ID/snap" no longer 
>> works because this is a V1 command with the V2 API having no support for the 
>> --location flag.
>> 
>> I'm primarily dealing with large(ish) windows images around 100GB mark, so 
>> exporting them to a file then importing them using the --file command is 
>> very sub optimal.
>> 
>> Without an outright database hack, is there any way to define an existing 
>> Ceph based volume to be used by Glance?
>> If there is not a way to do this then can I safely enable the V1 API in 
>> Queens? How long until V1 support is removed and I'm back to square 1
>> 
>> Thanks in advance
>> Cory
>> 
>> ___
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [OpenStack-Infra] PTG September 10-14 in Denver

[Melvin Hillsman]

Planning on being in attendance (travel approval pending)

On Fri, Apr 20, 2018 at 12:58 PM, Jeremy Stanley  wrote:

> On 2018-04-20 10:42:48 -0700 (-0700), Clark Boylan wrote:
> [...]
> > Let me know (doesn't have to be to the list if you aren't
> > comfortable with that) and thanks!
>
> You can expect me there. Not only was the venue great, the
> restaurants within walking distance were just my speed and, as icing
> on the cake, Denver is one of the few airports to/from which I can
> get direct flights!
> --
> Jeremy Stanley
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>



-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [all][ptl][release][masakari][murano][qinling][searchlight][zaqar] reminder for rocky-1 milestone deadline

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-04-19 09:15:49 -0400:
> Today is the deadline for proposing a release for the Rocky-1 milestone.
> Please don't forget to include your libraries (client or otherwise) as
> well.
> 
> Doug

A few projects have missed the first milestone tagging deadline:

  masakari-monitors
  masakari

  murano-dashboard

  qinling

  searchlight-ui
  searchlight

  zaqar-ui
  zaqar

The policy on missing deadlines this cycle is changing [1]:

  Projects using milestones are expected to tag at least 2 out of
  the 3 for each cycle, or risk being dropped as an official project.
  The release team will remind projects that miss the first milestone,
  and force tags on any later milestones by tagging HEAD at the
  time of the deadline.

The masakari, murano, qinling, searchlight, and zaqar teams should
consider this your reminder.

We really don't want to be making decisions for you about what
constitutes a good release, but we also do not want to have projects
that are not preparing releases. Please keep up with the deadlines.

Doug

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

__
OpenStack Development Mailing 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] [docs] When should we say 'run as root' in the docs?

[Matt Riedemann]

On 4/20/2018 2:04 AM, Andreas Jaeger wrote:

We use in openstack-manuals "# root-command" and "$ non-root command", see:
https://docs.openstack.org/install-guide/common/conventions.html



I learned something new today.



But looking at
https://git.openstack.org/cgit/openstack/nova/tree/doc/source/install/verify.rst#n103,
it is there - so, closed invalid IMHO,


Done, thanks for the feedback.

--

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-Infra] PTG September 10-14 in Denver

[Jeremy Stanley]

On 2018-04-20 10:42:48 -0700 (-0700), Clark Boylan wrote:
[...]
> Let me know (doesn't have to be to the list if you aren't
> comfortable with that) and thanks!

You can expect me there. Not only was the venue great, the
restaurants within walking distance were just my speed and, as icing
on the cake, Denver is one of the few airports to/from which I can
get direct flights!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] PTG September 10-14 in Denver

[Paul Belanger]

On Fri, Apr 20, 2018 at 10:42:48AM -0700, Clark Boylan wrote:
> Hello everyone,
> 
> I've been asked if the Infra team plans to attend the next PTG in Denver. My 
> current position is that it would be good to attend as a team as I think it 
> will give us a good opportunity to work on modernizing config management 
> efforts. But before I go ahead and commit to that it would be helpful to get 
> a rough headcount of who intends to go (if it will just be me then likely 
> don't need to have team space).
> 
> Don't worry if you don't have approval yet or have to sort out other details. 
> Mostly just interested in a "do we intend on being there or not" type of 
> answer.
> 
> More details on the event can be found at 
> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129564.html. 
> Feel free to ask questions if that will help you too.
> 
> Let me know (doesn't have to be to the list if you aren't comfortable with 
> that) and thanks!
> 
Intend on being there (pending travel approval)

-Paul

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[openstack-dev] [magnum] K8S apiserver key sync

[Sergey Filatov]

Hello,

I looked into k8s drivers for magnum I see that each api-server on master node 
generates it’s own service-account-key-file. This causes issues with 
service-accounts authenticating on api-server. (In case api-server endpoint 
moves).
As far as I understand we should have either all api-server keys synced on 
api-servesr or pre-generate single api-server key.

What is the way for magnum to get over this issue?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack] OpenStack Summit Vancouver Speed Mentoring Workshop—Call for Mentors

[Amy Marrich]

*Calling All OpenStack Mentors!We’re quickly nearing the Vancouver Summit,
and gearing up for another successful Speed Mentoring workshop! This
workshop, now a mainstay at OpenStack Summits, is designed to provide
guidance to newcomers so that they can dive in and actively engage,
participate and contribute to our community. And we couldn’t do this
without you—our fearless mentors!Speed Mentoring Workshop & LunchMonday,
May 21, 12:15 – 1:30 pmVancouver Convention Centre West, Level 2, Room
215-216https://bit.ly/2HCGjMo Who should sign
up?Are you excited about OpenStack and interested in sharing your career,
community or technical advice and expertise with others? Contributed (code
and non-code contributions welcome) to the OpenStack community for at least
one year? Any mentor of any gender with a technical or non-technical
background is encouraged to join us. Share your insights, inspire those new
to our community, grab lunch, and pick up special mentor gifts!How does it
work?Simply sign up here
,
and fill in a short survey about your areas of interests and expertise.
Your answers will be used to produce fun, customized baseball cards that
you can use to introduce yourself to the mentees. You will be provided with
mentees’ areas of interest and questions in advance to help you prepare,
and we’ll meet as a team ahead of time to go over logistics and answer any
questions you may have. On the day of the event, plan to arrive ~ 15
minutes before the session. During the session, you will meet with small
groups of mentees in 15-minute intervals and answer their questions about
how to grow in the community.It’s a fast-paced event and a great way to
meet new people, introduce them to the Summit and welcome them to the
OpenStack community.Be sure to sign up today
!*

*Thanks,*

*Amy (spotz)*
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [OpenStack-Infra] Stop supporting bindep-fallback.txt moving forward

[Jeremy Stanley]

On 2018-04-20 12:31:24 -0400 (-0400), Paul Belanger wrote:
[...]
> That is fine, if we want to do the mass migration to bionic first,
> then start looking at which projects are still using
> bindep-fallback.txt is fine with me.
> 
> I just wanted to highlight I think it is time we start pushing a
> little harder on projects to stop using this logic and start
> managing bindep.txt themself.

Yep, this is something I _completely_ agree with. We could even
start with a deprecation warning in the fallback path so it starts
showing up more clearly in the job logs too.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[Openstack-operators] OpenStack Summit Vancouver Speed Mentoring Workshop—Call for Mentors

[Amy Marrich]

*Calling All OpenStack Mentors!We’re quickly nearing the Vancouver Summit,
and gearing up for another successful Speed Mentoring workshop! This
workshop, now a mainstay at OpenStack Summits, is designed to provide
guidance to newcomers so that they can dive in and actively engage,
participate and contribute to our community. And we couldn’t do this
without you—our fearless mentors!Speed Mentoring Workshop & LunchMonday,
May 21, 12:15 – 1:30 pmVancouver Convention Centre West, Level 2, Room
215-216https://bit.ly/2HCGjMo Who should sign
up?Are you excited about OpenStack and interested in sharing your career,
community or technical advice and expertise with others? Contributed (code
and non-code contributions welcome) to the OpenStack community for at least
one year? Any mentor of any gender with a technical or non-technical
background is encouraged to join us. Share your insights, inspire those new
to our community, grab lunch, and pick up special mentor gifts!How does it
work?Simply sign up here
,
and fill in a short survey about your areas of interests and expertise.
Your answers will be used to produce fun, customized baseball cards that
you can use to introduce yourself to the mentees. You will be provided with
mentees’ areas of interest and questions in advance to help you prepare,
and we’ll meet as a team ahead of time to go over logistics and answer any
questions you may have. On the day of the event, plan to arrive ~ 15
minutes before the session. During the session, you will meet with small
groups of mentees in 15-minute intervals and answer their questions about
how to grow in the community.It’s a fast-paced event and a great way to
meet new people, introduce them to the Summit and welcome them to the
OpenStack community.Be sure to sign up today
!*

*Thanks,*

*Amy (spotz)*
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] OpenStack Summit Vancouver Speed Mentoring Workshop—Call for Mentors

[Amy Marrich]

*Calling All OpenStack Mentors!We’re quickly nearing the Vancouver Summit,
and gearing up for another successful Speed Mentoring workshop! This
workshop, now a mainstay at OpenStack Summits, is designed to provide
guidance to newcomers so that they can dive in and actively engage,
participate and contribute to our community. And we couldn’t do this
without you—our fearless mentors!Speed Mentoring Workshop & LunchMonday,
May 21, 12:15 – 1:30 pmVancouver Convention Centre West, Level 2, Room
215-216https://bit.ly/2HCGjMo Who should sign
up?Are you excited about OpenStack and interested in sharing your career,
community or technical advice and expertise with others? Contributed (code
and non-code contributions welcome) to the OpenStack community for at least
one year? Any mentor of any gender with a technical or non-technical
background is encouraged to join us. Share your insights, inspire those new
to our community, grab lunch, and pick up special mentor gifts!How does it
work?Simply sign up here
,
and fill in a short survey about your areas of interests and expertise.
Your answers will be used to produce fun, customized baseball cards that
you can use to introduce yourself to the mentees. You will be provided with
mentees’ areas of interest and questions in advance to help you prepare,
and we’ll meet as a team ahead of time to go over logistics and answer any
questions you may have. On the day of the event, plan to arrive ~ 15
minutes before the session. During the session, you will meet with small
groups of mentees in 15-minute intervals and answer their questions about
how to grow in the community.It’s a fast-paced event and a great way to
meet new people, introduce them to the Summit and welcome them to the
OpenStack community.Be sure to sign up today
!*

*Thanks,*

*Amy (spotz)*
__
OpenStack Development Mailing 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-operators] Intro and Containerized Control Plane

[Fabian Zimmermann]

Hi,

we run completely in containers. I would recommend to take a look at how kolla 
is creating and managing the containers.

This should prevent you from the bigger pitfalls :)

If you have any specific questions. Don't hesitate to ask.

Fabian Zimmermann

Am 20. April 2018 17:22:46 MESZ schrieb Michael Damkot :
>Hello Operators!!
>
>I wanted to say "Hello" to the community once again! I've come back
>into
>the OpenStack fold after my time as a former member of the Time Warner
>Cable Team.
>
>Salesforce is working toward greatly increasing the size and scale of
>our
>OpenStack use cases as well as our participation in the community.
>We're
>currently deep diving on a few things including containerizing a number
>of
>control plane components. Is anyone willing to share any hurdles or
>hiccups
>they've hit while exploring containerization? I didn't see much of
>anything
>in the archives but I know we aren't the only ones heading down this
>path.
>
>Thanks in advance!
>
>--
>Michael Damkot
>@mdamkot - twitter
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [OpenStack-Infra] Stop supporting bindep-fallback.txt moving forward

[Paul Belanger]

On Fri, Apr 20, 2018 at 09:13:17AM -0700, Clark Boylan wrote:
> On Fri, Apr 20, 2018, at 9:01 AM, Jeremy Stanley wrote:
> > On 2018-04-19 19:15:18 -0400 (-0400), Paul Belanger wrote:
> > [...]
> > > today ubuntu-bionic does seem to pass properly with
> > > bindep-fallback.txt, but perhaps we prime it with a bad package on
> > > purpose to force the issue. As clarkb points out, the downside to
> > > this it does make it harder for projects to be flipped to
> > > ubuntu-bionic.
> > [...]
> > 
> > My main concern is that this seems sort of at odds with how we
> > discussed simply forcing all PTI jobs from ubuntu-xenial to
> > ubuntu-bionic on master branches rather than giving projects the
> > option to transition on their own timelines (which worked out pretty
> > terribly when we tried being flexible with them on the ubuntu-trusty
> > to ubuntu-xenial transition a couple years ago). Adding a forced
> > mass migration to in-repo bindep.txt files at the same moment we
> > also force all the PTI jobs to a new platform will probably result
> > in torches and pitchforks.
> 
> Yup, this was my concern as well. I think the value of not being on older 
> platforms outweighs needing to manage a list of packages for longer. We 
> likely just need to keep pushing on projects to add/update bindep.txt in repo 
> instead. We can run a logstash query against job-output.txt looking for 
> output of using the fallback file and nicely remind projects if they show up 
> on that list.
> 
That is fine, if we want to do the mass migration to bionic first, then start
looking at which projects are still using bindep-fallback.txt is fine with me.

I just wanted to highlight I think it is time we start pushing a little harder
on projects to stop using this logic and start managing bindep.txt themself.

-Paul

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Stop supporting bindep-fallback.txt moving forward

[Clark Boylan]

On Fri, Apr 20, 2018, at 9:01 AM, Jeremy Stanley wrote:
> On 2018-04-19 19:15:18 -0400 (-0400), Paul Belanger wrote:
> [...]
> > today ubuntu-bionic does seem to pass properly with
> > bindep-fallback.txt, but perhaps we prime it with a bad package on
> > purpose to force the issue. As clarkb points out, the downside to
> > this it does make it harder for projects to be flipped to
> > ubuntu-bionic.
> [...]
> 
> My main concern is that this seems sort of at odds with how we
> discussed simply forcing all PTI jobs from ubuntu-xenial to
> ubuntu-bionic on master branches rather than giving projects the
> option to transition on their own timelines (which worked out pretty
> terribly when we tried being flexible with them on the ubuntu-trusty
> to ubuntu-xenial transition a couple years ago). Adding a forced
> mass migration to in-repo bindep.txt files at the same moment we
> also force all the PTI jobs to a new platform will probably result
> in torches and pitchforks.

Yup, this was my concern as well. I think the value of not being on older 
platforms outweighs needing to manage a list of packages for longer. We likely 
just need to keep pushing on projects to add/update bindep.txt in repo instead. 
We can run a logstash query against job-output.txt looking for output of using 
the fallback file and nicely remind projects if they show up on that list.

Clark

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [Openstack] which SDK to use?

[Chris Friesen]

On 04/20/2018 01:48 AM, Adrian Turjak wrote:

What version of the SDK are you using?


Originally I just used what was installed in my devstack VM, which seems to be 
0.9.17. Upgrading to 0.12.0 allowed it to work.


Thanks,
Chris


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [OpenStack-Infra] Stop supporting bindep-fallback.txt moving forward

[Jeremy Stanley]

On 2018-04-19 19:15:18 -0400 (-0400), Paul Belanger wrote:
[...]
> today ubuntu-bionic does seem to pass properly with
> bindep-fallback.txt, but perhaps we prime it with a bad package on
> purpose to force the issue. As clarkb points out, the downside to
> this it does make it harder for projects to be flipped to
> ubuntu-bionic.
[...]

My main concern is that this seems sort of at odds with how we
discussed simply forcing all PTI jobs from ubuntu-xenial to
ubuntu-bionic on master branches rather than giving projects the
option to transition on their own timelines (which worked out pretty
terribly when we tried being flexible with them on the ubuntu-trusty
to ubuntu-xenial transition a couple years ago). Adding a forced
mass migration to in-repo bindep.txt files at the same moment we
also force all the PTI jobs to a new platform will probably result
in torches and pitchforks.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [cyborg][release][Release-job-failures] Pre-release of openstack/cyborg failed

[Doug Hellmann]

Excerpts from zuul's message of 2018-04-20 13:59:14 +:
> Build failed.
> 
> - release-openstack-python 
> http://logs.openstack.org/fa/fabeaffa6efe8b1ef3d828f5b8c2cdc896e4afe9/pre-release/release-openstack-python/c624655/
>  : FAILURE in 6m 07s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> 

The cyborg milestone release failed to build because the packaging step
could not find some expected rootwrap files:

http://logs.openstack.org/fa/fabeaffa6efe8b1ef3d828f5b8c2cdc896e4afe9/pre-release/release-openstack-python/c624655/job-output.txt.gz#_2018-04-20_13_58_20_454319

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] [barbican] NEW weekly meeting time

[Ade Lee]

Due to the DST change in the States, by popular agreement, we're going
to move the Barbican meeting time back an hour.

So the new meeting time will be:

2 am UTC Tuesday == 10 pm EST Monday == 10 am CST (China) Tuesday

Thanks!
Ade

On Mon, 2018-03-05 at 15:16 -0500, Ade Lee wrote:
> Based on a few replies, we'll try moving the Barbican weekly meeting
> to
>  
> 
> 3 am UTC Tuesday == 10 pm EST Monday == 11 am CST (China) Tuesday
> 
> starting Tuesday March 12 2018 (next week).
> 
> See you then!
> 
> Ade
> 
> 
> On Fri, 2018-02-16 at 09:42 -0500, Ade Lee wrote:
> > Thanks Jiong,
> > 
> > Preference noted.  Anyone else want to make the meeting time
> > switch?
> > (Or prefer not to).
> > 
> > Ade
> > 
> > On Wed, 2018-02-14 at 14:13 +0800, Jiong Liu wrote:
> > > Hi Ade,
> > > 
> > > Thank you for proposing this change!
> > > I'm in China, and the second time slot works better for me.
> > > 
> > > Regards,
> > > Jiong
> > > 
> > > > Message: 35
> > > > Date: Tue, 13 Feb 2018 10:17:59 -0500
> > > > From: Ade Lee 
> > > > To: "OpenStack Development Mailing List (not for usage
> > > > questions)"
> > > > 
> > > > Subject: [openstack-dev] [barbican] weekly meeting time
> > > > Message-ID: <1518535079.22990.9.ca...@redhat.com>
> > > > Content-Type: text/plain; charset="UTF-8"
> > > > Hi all,
> > > > The Barbican weekly meeting has been fairly sparsely attended
> > > > for
> > > > a
> > > > little while now, and the most active contributors these days
> > > > appear to
> > > > be in Asia.
> > > > Its time to consider moving the weekly meeting to a time when
> > > > more
> > > > contributors can attend.  I'm going to propose a couple times
> > > > below
> > > > to
> > > > start out.
> > > > 2 am UTC Tuesday == 9 pm EST Monday == 10 am CST (China)
> > > > Tuesday
> > > > 3 am UTC Tuesday == 10 pm EST Monday == 11 am CST (China)
> > > > Tuesday
> > > > Feel free to propose other days/times.
> > > > Thanks, 
> > > > Ade
> > > > P.S. Until decided otherwise, the Barbican meeting remains on
> > > > Mondays
> > > > at 2000 UTC
> > > 
> > > 
> > > 
> > > _
> > > __
> > > __
> > > _
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > > su
> > > bs
> > > 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:unsu
> > bs
> > 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: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-operators] Intro and Containerized Control Plane

[Michael Damkot]

Hello Operators!!

I wanted to say "Hello" to the community once again! I've come back into
the OpenStack fold after my time as a former member of the Time Warner
Cable Team.

Salesforce is working toward greatly increasing the size and scale of our
OpenStack use cases as well as our participation in the community. We're
currently deep diving on a few things including containerizing a number of
control plane components. Is anyone willing to share any hurdles or hiccups
they've hit while exploring containerization? I didn't see much of anything
in the archives but I know we aren't the only ones heading down this path.

Thanks in advance!

--
Michael Damkot
@mdamkot - twitter
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [mistral] September PTG in Denver

[Dougal Matthews]

Hey all,

You may have seen the news already, but yesterday the next PTG location was
announced [1]. It will be in Denver again.

Can you let me know if you are planning to attend and go to Mistral
sessions? I have been asked about numbers and need to reply by May 5th.

Thanks,
Dougal


[1]:
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129564.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

[openstack-dev] [chef] State of the Kitchen - 3rd Edition

[Samuel Cassiba]

This is the third installment of what is going on in Chef OpenStack. The
goal is to give a quick overview to see our progress and what is on the
menu. Feedback is always welcome on the usefulness of the content.

Appetizers
==
=> Chef 14 support has arrived in the cookbooks. Test Kitchen will be
updated to 14 Soon(tm). The gate is still testing against 13. The 12
release is considered EOL as of May 1, 2018, so we will not be able to
support releases older than 13 at that time.
https://blog.chef.io/2018/04/19/whats-new-in-chef-14-and-chefdk-3/
=> Numerous community cookbooks received updates, the highest visibility
being Poise itself. This resolves issues with installing pip 10 on both
platforms, and system Python on RHEL.

Entrees
===
=> Installing Python has been centralized to the common cookbook, as
opposed to multiple attempts to install the same Python instance. This
produces a more consistent, repeatable outcome.
=> The dokken yaml has been fixed up to allow for testing in containers
once more.
=> Work has begun on overhauling the aging documentation, in an attempt to
align things closer to community standards. Parts are shamelessly inspired
from other projects (Puppet OpenStack, OpenStack-Ansible), so it will look
a bit familiar in some places.

Desserts

=> Rakefiles are going away! As tooling has matured, and the emergence of
the ChefDK, the functionality of what the reliable Rakefiles provide are
being replaced with tools such as Test Kitchen and Delivery.

On The Menu
===
=> Creamy Jalapeno Sauce
-- 1 cup (170g) sour cream / creme fraiche
-- 1 cup (170g) mayonnaise
-- 5 tbsp (75g) dry Ranch dressing powder
-- 2 tbsp (28g) dry Jalapeno powder
-- 4-5 pickled jalapeno chiles, with the stem removed (use some of the
pickling juice to thin things out if the consistency is too thick)
-- 1/2 cup (64g) fresh picked cilantro (dry works here, but... dry)
-- 1/2 cup (64g) salsa verde
-- 2 tbsp (28g) lime juice
-- (Optional) Heavy cream / double cream if the consistency is too thin

Add ingredients to a blender or food processor. Blend until desired
consistency, or until you do not see pieces of jalapeno.

Your humble line cook,
Samuel Cassiba (scas)
__
OpenStack Development Mailing List (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] [kuryr] Kuryr PTG survey

[Daniel Mellado]

Hi Kuryrs,

As you might've already been informed, next PTG [1] will be held again
in Denver, Colorado[1]. Where the pretty Rocky Mountains are and the
trains like to blow. We'd like you to have a minute and consider whether
we should be participating in this one. I personally consider that we
made great progress on last one at Dublin but would like you to fill
this form [2] before May 2nd so we can provide feedback to the
foundation. As usual, another options would be a VTG or a mid-cycle
somewhere else, depending on the planned participation.

Also take note if you haven't already that prices have changed quite a
lot, so the sooner we decide, the better.

Thanks!

Daniel

[1] https://www.openstack.org/ptg
[2]https://goo.gl/forms/HfiNnEF2CwuMva6n1



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] [ironic][infra][qa] Jobs failing; pep8 not found

[Jim Rollenhagen]

>
> In the short term we only need to fix the few projects with conflicting
> requirements. In the longer term we could have a concerted effort to
> move those dependencies. Someone creative might even be able to script
> it, since we do have a list of the blacklisted items.
>

Agree this is something we should do eventually.

For now, rloo came up with a better solution - remove ironic's pycodestyle
pin. We had backported the pin, then fixed and unpinned in master, but
didn't backport the unpin. After backporting the patch to unpin it, we're
all green again.

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

[openstack-dev] [mistral] Rocky-1 Release and Rocky-2 Plans

[Dougal Matthews]

Hey all,

Mistral Rocky-1 [1] has been released and mistral-lib [2] and mistral
client [3] are on their way.

I have moved all of the open bugs and blueprints assigned to Rocky-1 to the
Rocky-2 cycle.

Can you please check the following:

- All the bugs and blueprints important to you are correctly assigned to
Rocky 2.
- That you still plan on working on bugs and blueprints that are assigned
to you.

In the coming weeks I plan on going through the bugs in Rocky-2 and trying
to determine what is realistic. At the moment I believe we have more than
we can finish. [4]

Thanks all,
Dougal

[1]: https://review.openstack.org/#/c/562734/
[2]: https://review.openstack.org/#/c/562742/
[3]: https://review.openstack.org/#/c/562743/
[4]: https://launchpad.net/mistral/+milestone/rocky-2
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack] [OSSA-2018-001] Raw underlying encrypted volume access (CVE-2017-18191)

[Tristan Cacqueray]

=
OSSA-2018-001: Raw underlying encrypted volume access
=

:Date: April 20, 2018
:CVE: CVE-2017-18191


Affects
~~~
- Nova: >=15.0.0 <=15.1.0, >=16.0.0 <=16.1.1


Description
~~~
Lee Yarwood (Red Hat) reported a vulnerability in Nova encrypted
volumes handling. By detaching and reattaching an encrypted volume an
attacker may access the underlying raw volume and corrupt the LUKS
header resuling in a denial of service attack on the compute host. All
Nova setups supporting encrypted volumes are affected.


Patches
~~~
- https://review.openstack.org/561604 (Ocata)
- https://review.openstack.org/543569 (Pike)
- https://review.openstack.org/460243 (Queens)


Credits
~~~
- Lee Yarwood from Red Hat (CVE-2017-18191)


References
~~
- https://launchpad.net/bugs/1739593
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18191


Notes
~
- Pike and Ocata patches disable encrypted volume swapping, this feature is now
 only supported in Nova version >= 17.0.0.

--
Tristan Cacqueray
OpenStack Vulnerability Management Team


pgpYVP6CazoiT.pgp
Description: PGP signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-announce] [OSSA-2018-001] Raw underlying encrypted volume access (CVE-2017-18191)

[Tristan Cacqueray]

=
OSSA-2018-001: Raw underlying encrypted volume access
=

:Date: April 20, 2018
:CVE: CVE-2017-18191


Affects
~~~
- Nova: >=15.0.0 <=15.1.0, >=16.0.0 <=16.1.1


Description
~~~
Lee Yarwood (Red Hat) reported a vulnerability in Nova encrypted
volumes handling. By detaching and reattaching an encrypted volume an
attacker may access the underlying raw volume and corrupt the LUKS
header resuling in a denial of service attack on the compute host. All
Nova setups supporting encrypted volumes are affected.


Patches
~~~
- https://review.openstack.org/561604 (Ocata)
- https://review.openstack.org/543569 (Pike)
- https://review.openstack.org/460243 (Queens)


Credits
~~~
- Lee Yarwood from Red Hat (CVE-2017-18191)


References
~~
- https://launchpad.net/bugs/1739593
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18191


Notes
~
- Pike and Ocata patches disable encrypted volume swapping, this feature is now
 only supported in Nova version >= 17.0.0.

--
Tristan Cacqueray
OpenStack Vulnerability Management Team


pgpQPFKKqnqPu.pgp
Description: PGP signature
___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

Re: [OpenStack-Infra] Stop supporting bindep-fallback.txt moving forward

[Andreas Jaeger]

On 2018-04-20 16:05, Paul Belanger wrote:
> On Fri, Apr 20, 2018 at 09:07:25AM +0200, Andreas Jaeger wrote:
>> On 2018-04-20 01:15, Paul Belanger wrote:
>>> Greetings,
>>>
>>> I'd like to propose we hard freeze changes to bindep-fallback.txt[1] and 
>>> push
>>> projects to start using a local bindep.txt file.
>>>
>>> This would mean, moving forward with ubuntu-bionic, if a project was still
>>> depending on bindep-fallback.txt, their jobs may raise a syntax error.
>>>
>>> In fact, today ubuntu-bionic does seem to pass properly with
>>> bindep-fallback.txt, but perhaps we prime it with a bad package on purpose 
>>> to
>>> force the issue. As clarkb points out, the downside to this it does make it
>>> harder for projects to be flipped to ubuntu-bionic.  It is possible we could
>>> also prime gerrit patches for projects that are missing bindep.txt to help 
>>> push
>>> this effort along.
>>>
>>> Thoughts?
>>>
>>> [1] 
>>> http://git.openstack.org/cgit/openstack-infra/project-config/tree/nodepool/elements/bindep-fallback.txt
>>
>> This might break all stable branches as well. Pushing those changes in
>> is a huge effort ;( Is that worth it?
>>
> I wouldn't expect stable branches to be running bionic, unless I am missing
> something obvious.

How do you want to change the set up tox jobs, especially python27,
sphinx-docs, and python35?

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-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [TripleO][ci][ceph] switching to config-download by default

[James Slagle]

On Thu, Apr 5, 2018 at 10:38 AM, James Slagle  wrote:
> I've pushed up for review a set of patches to switch us over to using
> config-download by default:
>
> https://review.openstack.org/#/q/topic:bp/config-download-default
>
> I believe I've come up with the proper series of steps to switch
> things over. Let me know if you have any feedback or foresee any
> issues:
>
> FIrst, we update remaining multinode jobs
> (https://review.openstack.org/558965) and ovb jobs
> (https://review.openstack.org/559067) that run against master to
> opt-in to config-download. This will expose any issues with these jobs
> and config-download and let us fix those issues.
>
> We can then switch tripleoclient (https://review.openstack.org/558925)
> over to use config-download by default. Since this also requires a
> Heat environment, we must forcibly inject that environment via
> tripleoclient.

FYI, the above work is completed and config-download is now the
default with tripleoclient.

>
> Once the tripleoclient patch lands, we can update
> tripleo-heat-templates to use the mappings from config-download in the
> default resource registry (https://review.openstack.org/558927).
>
> We can then remove the forcibly injected environment from
> tripleoclient (https://review.openstack.org/558931)

We're now moving forward with the above 2 patches. jtomasek is making
good progress with the UI and support for config-download should be
landing there soon.

>
> Finally, we can go back and update the multinode/ovb jobs on master to
> not be opt-in for config-download since it would now be the default
> (no patch yet).
>
> Now...for Ceph it will be slightly different:

It took some CI wrangling, but Ceph is now switched over to use
external_deploy_tasks. There are patches in progress to clean up the
old workflow_tasks:

https://review.openstack.org/563040
https://review.openstack.org/563113

There will be some further patches for CI to remove other explicit
opt-in's for config-download since it's now the default.

Feel free to ping me directly if you think you've found any issues
related to any of the config-download work, or file bugs in launchpad
using the official "config-download" tag.

-- 
-- James Slagle
--

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

Re: [openstack-dev] [all][infra] ubuntu-bionic and legacy nodesets

[Paul Belanger]

On Fri, Apr 20, 2018 at 08:16:07AM +0100, Jean-Philippe Evrard wrote:
> That's very cool.
> Any idea of the repartition of nodes xenial vs bionic? Is that a very
> restricted amount of nodes?
> 
According to upstream, ubuntu-bionic releases next week. In openstack-infra we
are in really good shape to have projects start using it once we rebuild using
the released version. Projects are able to use ubuntu-bionic today, we just ask
they don't gate on them until the official release.

As for switching the PTI job to use ubuntu-bionic, that is a different
discussion. It would bump python to 3.6 and likely be too late in the cycle to
do it.  I guess something we can hash out with infra / requirements / tc /
EALLTHEPROJECTS.

-Paul

> 
> On 20 April 2018 at 00:37, Paul Belanger  wrote:
> > Greetings,
> >
> > With ubuntu-bionic release around the corner we'll be starting discussions 
> > about
> > migrating jobs from ubuntu-xenial to ubuntu-bionic.
> >
> > On topic I'd like to raise, is round job migrations from legacy to native
> > zuulv3.  Specifically, I'd like to propose we do not add 
> > legacy-ubuntu-bionic
> > nodesets into openstack-zuul-jobs. Projects should be working towards moving
> > away from the legacy format, as they were just copypasta from our previous 
> > JJB
> > templates.
> >
> > Projects would still be free to move them intree, but I would highly 
> > encourage
> > projects do not do this, as it only delays the issue.
> >
> > The good news is the majority of jobs have already been moved to native 
> > zuulv3
> > jobs, but there are still some projects still depending on the legacy 
> > nodesets.
> > For example, tox bases jobs would not be affected.  It mostly would be dsvm
> > based jobs that haven't been switch to use the new devstack jobs for zuulv3.
> >
> > -Paul
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Jim Rollenhagen]

On Fri, Apr 20, 2018 at 4:02 AM, Chen CH Ji  wrote:

> Thanks a lot for your sharing, that's good info, just curious why [1] need
> zip and base64 encode if my understand is correct
> I was told nova need format should be pure vfat or iso9660, I assume it's
> because actually the config drive itself is making by iso by default
> then wrap a zip/base64 format ... thanks
>

We only gzip and base64 to send it to the ironic API. It is decoded and
unzipped before writing it to disk, so it is a pure iso9660 on the disk.

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

Re: [openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits

[Giulio Fidente]

On 04/19/2018 07:01 PM, Emilien Macchi wrote:
> Greetings,
> 
> As you probably know mcornea on IRC, Marius Cornea has been contributing
> on TripleO for a while, specially on the upgrade bits.
> Part of the quality team, he's always testing real customer scenarios
> and brings a lot of good feedback in his reviews, and quite often takes
> care of fixing complex bugs when it comes to advanced upgrades scenarios.
> He's very involved in tripleo-upgrade repository where he's already
> core, but I think it's time to let him +2 on other tripleo repos for the
> patches related to upgrades (we trust people's judgement for reviews).
> 
> As usual, we'll vote!
> 
> Thanks everyone for your feedback and thanks Marius for your hard work
> and involvement in the project.

+1

thanks Marius for your hard and very important work

-- 
Giulio Fidente
GPG KEY: 08D733BA

__
OpenStack Development Mailing 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-Infra] Stop supporting bindep-fallback.txt moving forward

[Paul Belanger]

On Fri, Apr 20, 2018 at 09:07:25AM +0200, Andreas Jaeger wrote:
> On 2018-04-20 01:15, Paul Belanger wrote:
> > Greetings,
> > 
> > I'd like to propose we hard freeze changes to bindep-fallback.txt[1] and 
> > push
> > projects to start using a local bindep.txt file.
> > 
> > This would mean, moving forward with ubuntu-bionic, if a project was still
> > depending on bindep-fallback.txt, their jobs may raise a syntax error.
> > 
> > In fact, today ubuntu-bionic does seem to pass properly with
> > bindep-fallback.txt, but perhaps we prime it with a bad package on purpose 
> > to
> > force the issue. As clarkb points out, the downside to this it does make it
> > harder for projects to be flipped to ubuntu-bionic.  It is possible we could
> > also prime gerrit patches for projects that are missing bindep.txt to help 
> > push
> > this effort along.
> > 
> > Thoughts?
> > 
> > [1] 
> > http://git.openstack.org/cgit/openstack-infra/project-config/tree/nodepool/elements/bindep-fallback.txt
> 
> This might break all stable branches as well. Pushing those changes in
> is a huge effort ;( Is that worth it?
> 
I wouldn't expect stable branches to be running bionic, unless I am missing
something obvious.

> 
> 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-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [ironic][infra][qa] Jobs failing; pep8 not found

[Doug Hellmann]

Excerpts from Jim Rollenhagen's message of 2018-04-20 09:05:23 -0400:
> On Fri, Apr 20, 2018 at 7:33 AM, Jim Rollenhagen 
> wrote:
> 
> > On Thu, Apr 19, 2018 at 3:21 PM, Doug Hellmann 
> > wrote:
> >>
> >>
> >> Reading through that log more carefully, I see an early attempt to pin
> >> pycodestyle <= 2.3.1 [1], followed later by pycodestyle == 2.4.0 being
> >> pulled in as a dependency of flake8-import-order==0.12 when neutron's
> >> test-requirements.txt is installed [2]. Then later when ironic's
> >> test-requirements.txt is installed pycodestyle is downgraded to 2.3.1
> >> [3].
> >>
> >> Reproducing those install & downgrade steps, I see that pycodestyle
> >> 2.4.0 claims to own pep8.py but pycodestyle 2.3.1 does not [4]. So that
> >> explains why pep8 is not re-installed when pycodestyle is downgraded.
> >>
> >
> > Aha, interesting! That's a fun one. :)
> >
> > I think the real problem here is that we have linter dependencies listed
> >> in the test-requirements.txt files for our projects, and they are
> >> somehow being installed without the constraints.
> >
> >
> > This is because they're in the blacklist, right?
> >
> >
> >> I don't think they need
> >> to be installed for devstack at all, so one way to fix it would be to
> >> move those dependencies to the tox.ini section for running pep8, or to
> >> have devstack look at the blacklisted packages and skip installing them.
> >>
> >
> > Yeah, seems like either would work. With the latter, would devstack edit
> > these out of test-requirements.txt before installing, I presume? The former
> > seems less hacky, I'll proceed with that unless folks have objections.
> >
> 
> Although... this would need to be done in every project installed from
> source during the devstack run. I'm going to look into doing this in
> devstack instead to avoid spending all day moving patches.

In the short term we only need to fix the few projects with conflicting
requirements. In the longer term we could have a concerted effort to
move those dependencies. Someone creative might even be able to script
it, since we do have a list of the blacklisted items.

> 
> // jim

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

Re: [openstack-dev] [ironic][infra][qa] Jobs failing; pep8 not found

[Doug Hellmann]

Excerpts from Jim Rollenhagen's message of 2018-04-20 07:33:51 -0400:
> On Thu, Apr 19, 2018 at 3:21 PM, Doug Hellmann 
> wrote:
> >
> >
> > Reading through that log more carefully, I see an early attempt to pin
> > pycodestyle <= 2.3.1 [1], followed later by pycodestyle == 2.4.0 being
> > pulled in as a dependency of flake8-import-order==0.12 when neutron's
> > test-requirements.txt is installed [2]. Then later when ironic's
> > test-requirements.txt is installed pycodestyle is downgraded to 2.3.1
> > [3].
> >
> > Reproducing those install & downgrade steps, I see that pycodestyle
> > 2.4.0 claims to own pep8.py but pycodestyle 2.3.1 does not [4]. So that
> > explains why pep8 is not re-installed when pycodestyle is downgraded.
> >
> 
> Aha, interesting! That's a fun one. :)
> 
> I think the real problem here is that we have linter dependencies listed
> > in the test-requirements.txt files for our projects, and they are
> > somehow being installed without the constraints.
> 
> 
> This is because they're in the blacklist, right?

Yes, that's probably it.

> > I don't think they need
> > to be installed for devstack at all, so one way to fix it would be to
> > move those dependencies to the tox.ini section for running pep8, or to
> > have devstack look at the blacklisted packages and skip installing them.
> >
> 
> Yeah, seems like either would work. With the latter, would devstack edit
> these out of test-requirements.txt before installing, I presume? The former
> seems less hacky, I'll proceed with that unless folks have objections.

I like updating the tox.ini, too, since it has the added benefit of
putting the linter (and other blacklisted) dependencies in a file the
requirements check job ignores.

> 
> Thanks for the help, Doug! :)
> 
> // jim

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

Re: [openstack-dev] [ironic][infra][qa] Jobs failing; pep8 not found

[Jim Rollenhagen]

On Fri, Apr 20, 2018 at 7:33 AM, Jim Rollenhagen 
wrote:

> On Thu, Apr 19, 2018 at 3:21 PM, Doug Hellmann 
> wrote:
>>
>>
>> Reading through that log more carefully, I see an early attempt to pin
>> pycodestyle <= 2.3.1 [1], followed later by pycodestyle == 2.4.0 being
>> pulled in as a dependency of flake8-import-order==0.12 when neutron's
>> test-requirements.txt is installed [2]. Then later when ironic's
>> test-requirements.txt is installed pycodestyle is downgraded to 2.3.1
>> [3].
>>
>> Reproducing those install & downgrade steps, I see that pycodestyle
>> 2.4.0 claims to own pep8.py but pycodestyle 2.3.1 does not [4]. So that
>> explains why pep8 is not re-installed when pycodestyle is downgraded.
>>
>
> Aha, interesting! That's a fun one. :)
>
> I think the real problem here is that we have linter dependencies listed
>> in the test-requirements.txt files for our projects, and they are
>> somehow being installed without the constraints.
>
>
> This is because they're in the blacklist, right?
>
>
>> I don't think they need
>> to be installed for devstack at all, so one way to fix it would be to
>> move those dependencies to the tox.ini section for running pep8, or to
>> have devstack look at the blacklisted packages and skip installing them.
>>
>
> Yeah, seems like either would work. With the latter, would devstack edit
> these out of test-requirements.txt before installing, I presume? The former
> seems less hacky, I'll proceed with that unless folks have objections.
>

Although... this would need to be done in every project installed from
source during the devstack run. I'm going to look into doing this in
devstack instead to avoid spending all day moving patches.

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

Re: [openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits

[Michele Baldessari]

+1

On Thu, Apr 19, 2018 at 10:01:50AM -0700, Emilien Macchi wrote:
> Greetings,
> 
> As you probably know mcornea on IRC, Marius Cornea has been contributing on
> TripleO for a while, specially on the upgrade bits.
> Part of the quality team, he's always testing real customer scenarios and
> brings a lot of good feedback in his reviews, and quite often takes care of
> fixing complex bugs when it comes to advanced upgrades scenarios.
> He's very involved in tripleo-upgrade repository where he's already core,
> but I think it's time to let him +2 on other tripleo repos for the patches
> related to upgrades (we trust people's judgement for reviews).
> 
> As usual, we'll vote!
> 
> Thanks everyone for your feedback and thanks Marius for your hard work and
> involvement in the project.
> -- 
> 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


-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

__
OpenStack Development Mailing 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] Proposing Marius Cornea core on upgrade bits

[Julie Pichon]

On 19 April 2018 at 18:01, Emilien Macchi  wrote:
> Greetings,
>
> As you probably know mcornea on IRC, Marius Cornea has been contributing on
> TripleO for a while, specially on the upgrade bits.
> Part of the quality team, he's always testing real customer scenarios and
> brings a lot of good feedback in his reviews, and quite often takes care of
> fixing complex bugs when it comes to advanced upgrades scenarios.
> He's very involved in tripleo-upgrade repository where he's already core,
> but I think it's time to let him +2 on other tripleo repos for the patches
> related to upgrades (we trust people's judgement for reviews).
>
> As usual, we'll vote!
>
> Thanks everyone for your feedback and thanks Marius for your hard work and
> involvement in the project.

+1

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

Re: [openstack-dev] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

[Thomas Herve]

On Thu, Apr 19, 2018 at 2:59 PM, Harald Jensås  wrote:
> Hi,

Hi, thanks for sending this. Responses inline.

> When configuring TripleO deployments with nodes on routed ctlplane
> networks we need to pass some per-network properties to the
> NetworkConfig resource[1] in THT. We get the ``ControlPlaneIp``
> property using get_attr, but the NIC configs need a couple of more
> parameters[2], for example: ``ControlPlaneSubnetCidr``,
> ``ControlPlaneDefaultRoute`` and ``DnsServers``.
>
> Since queens these templates are jinja templated, to generate things
> from from network_data.yaml. When using routed ctlplane networks, the
> parameters ``ControlPlaneSubnetCidr`` and ``ControlPlaneDefaultRoute``
> will be different. So we need to use static per-role
> Net::SoftwareConfig templates, and add parameters such as
> ``ControlPlaneDefaultRouteLeafX``.
>
> The values the use need to pass in for these are already available in
> the neutron ctlplane network configuration on the undercloud. So
> ideally we should not need to ask the user to provide them in
> parameter_defaults, we should resolve the correct values automatically.

To make it clear, what you want to prevent is the need to add more
keys in network_data.yaml?

As those had to be provided at some point, I wonder if tripleo can't
find a way to pass them again on the overcloud deploy.

Inspecting neutron is an elegant solution, though.

> : We can get the port ID using get_attr:
>
>  {get_attr: [, addresses, , 0, port]}
>
> : From there outside of heat we can get the subnet_id:
>
>  openstack port show 2fb4baf9-45b0-48cb-8249-c09a535b9eda \
>  -f yaml -c fixed_ips
>
>  fixed_ips: ip_address='172.20.0.10', subnet_id='2b06ae2e-423f-4a73-
> 97ad-4e9822d201e5'
>
> : And finally we can get the gateway_ip and cidr of the subnet:
>
>   openstack subnet show 2b06ae2e-423f-4a73-97ad-4e9822d201e5 \
>   -f yaml -c gateway_ip -c cidr
>
>  cidr: 172.20.0.0/26
>  gateway_ip: 172.20.0.62
>
>
> The problem is getting there using heat ...
> a couple of ideas:
>
> a) Use heat's ``external_resource`` to create a port resource,
>and then  a external subnet resource. Then get the data
>from the external resources. We probably would have to make
>it possible for a ``external_resource`` depend on the server
>resource, and verify that these resource have the required
>attributes.

I believe that's a relatively easy fix. It's unclear why we didn't
allow that in the first place, probably because we were missing a use
case, but it seems valuable here.

> b) Extend attributes of OS::Nova::Server (OS::Neutron::Port as
>well probably) to include the data.
>
>If we do this we should probably aim to be in parity with
>what is made available to clients getting the configuration
>from dhcp. (mtu, dns_domain, dns_servers, prefixlen,
>gateway_ip, host_routes, ipv6_address_mode, ipv6_ra_mode
>etc.)

I'm with you on exposing more neutron data to the Port resource. It
can be complicated because some of them are implementation specific,
but we can look into those.

I don't think adding them directly to the Server resource makes a ton
of sense though.

> c) Create a new heat function to read properties of any
>openstack resource, without having to make use of the
>external_resource in heat.

It's an interesting idea, but I think it would look a lot like what
external resources are supposed to be.

I see a few changes:
 * Allow external resource to depend on other resources
 * Expose more port attributes
 * Expose more subnet attributes

If you can list the attributes you care about that'd be great.

Thanks,

-- 
Thomas

__
OpenStack Development Mailing 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] Proposing Marius Cornea core on upgrade bits

[Arx Cruz]

+1 Congrats man!!!

On Fri, Apr 20, 2018 at 2:29 PM, Brent Eagles  wrote:

> +1 !!!
>
> On Fri, Apr 20, 2018 at 9:42 AM, Brad P. Crochet  wrote:
>
>> +1 from me!
>>
>> On Fri, Apr 20, 2018 at 8:04 AM Yolanda Robla Mota 
>> wrote:
>>
>>> +1, Marius has been a great help
>>>
>>> On Thu, Apr 19, 2018 at 7:01 PM, Emilien Macchi 
>>> wrote:
>>>
 Greetings,

 As you probably know mcornea on IRC, Marius Cornea has been
 contributing on TripleO for a while, specially on the upgrade bits.
 Part of the quality team, he's always testing real customer scenarios
 and brings a lot of good feedback in his reviews, and quite often takes
 care of fixing complex bugs when it comes to advanced upgrades scenarios.
 He's very involved in tripleo-upgrade repository where he's already
 core, but I think it's time to let him +2 on other tripleo repos for the
 patches related to upgrades (we trust people's judgement for reviews).

 As usual, we'll vote!

 Thanks everyone for your feedback and thanks Marius for your hard work
 and involvement in the project.
 --
 Emilien Macchi

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


>>>
>>>
>>> --
>>>
>>> Yolanda Robla Mota
>>>
>>> Principal Software Engineer, RHCE
>>>
>>> Red Hat
>>>
>>> 
>>>
>>> C/Avellana 213
>>>
>>> Urb Portugal
>>>
>>> yrobl...@redhat.comM: +34605641639
>>> 
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> --
>> Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
>> Principal Software Engineer
>> (c) 704.236.9385
>>
>>
>> 
>> __
>> 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
>
>
__
OpenStack Development Mailing 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] Proposing Marius Cornea core on upgrade bits

[Brent Eagles]

+1 !!!

On Fri, Apr 20, 2018 at 9:42 AM, Brad P. Crochet  wrote:

> +1 from me!
>
> On Fri, Apr 20, 2018 at 8:04 AM Yolanda Robla Mota 
> wrote:
>
>> +1, Marius has been a great help
>>
>> On Thu, Apr 19, 2018 at 7:01 PM, Emilien Macchi 
>> wrote:
>>
>>> Greetings,
>>>
>>> As you probably know mcornea on IRC, Marius Cornea has been contributing
>>> on TripleO for a while, specially on the upgrade bits.
>>> Part of the quality team, he's always testing real customer scenarios
>>> and brings a lot of good feedback in his reviews, and quite often takes
>>> care of fixing complex bugs when it comes to advanced upgrades scenarios.
>>> He's very involved in tripleo-upgrade repository where he's already
>>> core, but I think it's time to let him +2 on other tripleo repos for the
>>> patches related to upgrades (we trust people's judgement for reviews).
>>>
>>> As usual, we'll vote!
>>>
>>> Thanks everyone for your feedback and thanks Marius for your hard work
>>> and involvement in the project.
>>> --
>>> 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
>>>
>>>
>>
>>
>> --
>>
>> Yolanda Robla Mota
>>
>> Principal Software Engineer, RHCE
>>
>> Red Hat
>>
>> 
>>
>> C/Avellana 213
>>
>> Urb Portugal
>>
>> yrobl...@redhat.comM: +34605641639
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
> Principal Software Engineer
> (c) 704.236.9385
>
>
> __
> OpenStack Development Mailing List (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] Proposing Marius Cornea core on upgrade bits

[Brad P. Crochet]

+1 from me!

On Fri, Apr 20, 2018 at 8:04 AM Yolanda Robla Mota 
wrote:

> +1, Marius has been a great help
>
> On Thu, Apr 19, 2018 at 7:01 PM, Emilien Macchi 
> wrote:
>
>> Greetings,
>>
>> As you probably know mcornea on IRC, Marius Cornea has been contributing
>> on TripleO for a while, specially on the upgrade bits.
>> Part of the quality team, he's always testing real customer scenarios and
>> brings a lot of good feedback in his reviews, and quite often takes care of
>> fixing complex bugs when it comes to advanced upgrades scenarios.
>> He's very involved in tripleo-upgrade repository where he's already core,
>> but I think it's time to let him +2 on other tripleo repos for the patches
>> related to upgrades (we trust people's judgement for reviews).
>>
>> As usual, we'll vote!
>>
>> Thanks everyone for your feedback and thanks Marius for your hard work
>> and involvement in the project.
>> --
>> 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
>>
>>
>
>
> --
>
> Yolanda Robla Mota
>
> Principal Software Engineer, RHCE
>
> Red Hat
>
> 
>
> C/Avellana 213
>
> Urb Portugal
>
> yrobl...@redhat.comM: +34605641639
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [placement] placement update 18-16

[Chris Dent]

This is a "contract" update, the lists of specs and other has not
had new things added to it, only stuff that is done removed. There
are of course new things out there, but they will be added next
week.

# Most Important

Nested providers in allocation candidates remains the important
stuff. There was a big email thread about some aspects of this

http://lists.openstack.org/pipermail/openstack-dev/2018-April/129477.html

which eventually led to a modification of the spec on granular
resource requests for a new query parameter:

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

The other main thing in progress is consumer generations.

There's nothing currently in a runway or the runways queue related
to placement. Anything ready to go?

# What's Changed

Besides the new query parameter above we've also got: forbidden
traits support merged on both the placement and extra specs
processing sides, and some performance improvements in the SQL for
checking capacity when doing allocations. The framework that allows
error responses to include an error code has merged. Future errors
should provide codes, see:


https://docs.openstack.org/nova/latest/contributor/placement.html#adding-a-new-handler

for information on how to do that. This is especially important for
the many different types of 409 responses that we can produce (even
more coming with consumer generations).

With forbidden being some definition of "done" it's no longer a main
theme and "Granular" will take its place as a new theme. This is
closely tied to nested providers but is enough of an undertaking to
get its own theme.

Update provider tree is also effectively done, so it is gone from
themes as well. There's ongoing work to use ProviderTree in the virt
drivers but that's not captured by the theme.

# Bugs

* Placement related bugs not yet in progress:  https://goo.gl/TgiPXb
 16, +2 on last week
* In progress placement bugs: https://goo.gl/vzGGDQ
 12, -1 on last week

# Specs

There have been some spec additions or modifications this week, but
those are not present here. This is last week's list, with abandoned
or merged stuff trimmed. Move these along before moving the others
along, if possible. Total last week: 14. Now: 12 (just from this
list). Merge or abandon more specs!

* https://review.openstack.org/#/c/549067/
VMware: place instances on resource pool
(using update_provider_tree)

* https://review.openstack.org/#/c/552924/
   Proposes NUMA topology with RPs

* https://review.openstack.org/#/c/544683/
   Account for host agg allocation ratio in placement

* https://review.openstack.org/#/c/552105/
   Support default allocation ratios

* https://review.openstack.org/#/c/438640/
   Spec on preemptible servers

* https://review.openstack.org/#/c/557065/
 Proposes Multiple GPU types

* https://review.openstack.org/#/c/555081/
 Standardize CPU resource tracking

* https://review.openstack.org/#/c/502306/
 Network bandwidth resource provider

* https://review.openstack.org/#/c/509042/
 Propose counting quota usage from placement

* https://review.openstack.org/#/c/560174/
   Add history behind nullable project_id and user_id

* https://review.openstack.org/#/c/559466/
   Return resources of entire trees in Placement

* https://review.openstack.org/#/c/560974/
   Numbered request groups use different providers

# Main Themes

## Nested providers in allocation candidates

Representing nested provides in the response to GET
/allocation_candidates is required to actually make use of all the
topology that update provider tree will report. That work is in
progress at:

  https://review.openstack.org/#/q/topic:bp/nested-resource-providers
  
https://review.openstack.org/#/q/topic:bp/nested-resource-providers-allocation-candidates

(Someone want to clue me in as to whether that first topic is still
legit?)

## Mirror nova host aggregates to placement

This makes it so some kinds of aggregate filtering can be done
"placement side" by mirroring nova host aggregates into placement
aggregates.

https://review.openstack.org/#/q/topic:bp/placement-mirror-host-aggregates

This is still in progress but took a little attention break while
nested provider discussions took up (and destroyed) brains.

## Consumer Generations

This allows multiple agents to "safely" update allocations for a
single consumer. The code is in progress:

 https://review.openstack.org/#/q/topic:bp/add-consumer-generation

This is moving along.

## Granular

Ways and means of addressing granular requests when dealing with
nested resource providers. Granular in this sense is grouping
resource classes and traits together in their own lumps as required.
The email debate mentioned above is about how those lumps would like
to associate with one another. Topic is:

https://review.openstack.org/#/q/topic:bp/granular-resource-requests

# Extraction

The spec for optional database handling, which helps provide options

Re: [openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits

[Yolanda Robla Mota]

+1, Marius has been a great help

On Thu, Apr 19, 2018 at 7:01 PM, Emilien Macchi  wrote:

> Greetings,
>
> As you probably know mcornea on IRC, Marius Cornea has been contributing
> on TripleO for a while, specially on the upgrade bits.
> Part of the quality team, he's always testing real customer scenarios and
> brings a lot of good feedback in his reviews, and quite often takes care of
> fixing complex bugs when it comes to advanced upgrades scenarios.
> He's very involved in tripleo-upgrade repository where he's already core,
> but I think it's time to let him +2 on other tripleo repos for the patches
> related to upgrades (we trust people's judgement for reviews).
>
> As usual, we'll vote!
>
> Thanks everyone for your feedback and thanks Marius for your hard work and
> involvement in the project.
> --
> 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
>
>


-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat



C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639


__
OpenStack Development Mailing 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][infra][qa] Jobs failing; pep8 not found

[Jim Rollenhagen]

On Thu, Apr 19, 2018 at 3:21 PM, Doug Hellmann 
wrote:
>
>
> Reading through that log more carefully, I see an early attempt to pin
> pycodestyle <= 2.3.1 [1], followed later by pycodestyle == 2.4.0 being
> pulled in as a dependency of flake8-import-order==0.12 when neutron's
> test-requirements.txt is installed [2]. Then later when ironic's
> test-requirements.txt is installed pycodestyle is downgraded to 2.3.1
> [3].
>
> Reproducing those install & downgrade steps, I see that pycodestyle
> 2.4.0 claims to own pep8.py but pycodestyle 2.3.1 does not [4]. So that
> explains why pep8 is not re-installed when pycodestyle is downgraded.
>

Aha, interesting! That's a fun one. :)

I think the real problem here is that we have linter dependencies listed
> in the test-requirements.txt files for our projects, and they are
> somehow being installed without the constraints.


This is because they're in the blacklist, right?


> I don't think they need
> to be installed for devstack at all, so one way to fix it would be to
> move those dependencies to the tox.ini section for running pep8, or to
> have devstack look at the blacklisted packages and skip installing them.
>

Yeah, seems like either would work. With the latter, would devstack edit
these out of test-requirements.txt before installing, I presume? The former
seems less hacky, I'll proceed with that unless folks have objections.

Thanks for the help, Doug! :)

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

Re: [openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits

[Marios Andreou]

+1 !

On Thu, Apr 19, 2018 at 8:01 PM, Emilien Macchi  wrote:

> Greetings,
>
> As you probably know mcornea on IRC, Marius Cornea has been contributing
> on TripleO for a while, specially on the upgrade bits.
> Part of the quality team, he's always testing real customer scenarios and
> brings a lot of good feedback in his reviews, and quite often takes care of
> fixing complex bugs when it comes to advanced upgrades scenarios.
> He's very involved in tripleo-upgrade repository where he's already core,
> but I think it's time to let him +2 on other tripleo repos for the patches
> related to upgrades (we trust people's judgement for reviews).
>
> As usual, we'll vote!
>
> Thanks everyone for your feedback and thanks Marius for your hard work and
> involvement in the project.
> --
> 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] [monasca] Monasca PTG participation survey

[Bedyk, Witold]

Hello everyone,

The next PTG will take place September 10-14, 2018 in Denver, Colorado [1]. 
Again we have to decide if Monasca will participate and gather together with 
other projects. The last PTG was a great success which is measurable in new 
code already submitted and number of reviews. But I also understand that it's 
not always easy to travel.
Please take a minute, consider all the pros and cons, and fill out this form 
[2] until Wednesday, May 2nd.

Cheers
Witek

[1] https://www.openstack.org/ptg
[2] https://goo.gl/forms/z2Bu5RlXin30wTpA3

__
OpenStack Development Mailing 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] Ironic Inspector in the overcloud

[Derek Higgins]

On 18 April 2018 at 17:12, Derek Higgins  wrote:

>
>
> On 18 April 2018 at 14:22, Bogdan Dobrelya  wrote:
>
>> On 4/18/18 12:07 PM, Derek Higgins wrote:
>>
>>> Hi All,
>>>
>>> I've been testing the ironic inspector containerised service in the
>>> overcloud, the service essentially works but there is a couple of hurdles
>>> to tackle to set it up, the first of these is how to get  the IPA kernel
>>> and ramdisk where they need to be.
>>>
>>> These need to be be present in the ironic_pxe_http container to be
>>> served out over http, whats the best way to get them there?
>>>
>>> On the undercloud this is done by copying the files across the
>>> filesystem[1][2] to /httpboot  when we run "openstack overcloud image
>>> upload", but on the overcloud an alternative is required, could the files
>>> be pulled into the container during setup?
>>>
>>
>> I'd prefer keep bind-mounting IPA kernel and ramdisk into a container via
>> the /var/lib/ironic/httpboot host-path. So the question then becomes how to
>> deliver those by that path for overcloud nodes?
>>
> Yup it does, I'm currently looking into using DeployArtifactURLs to
> download the files to the controller nodes
>
It turns out this wont work as Deploy artifacts downloads to all hosts
which we don't want,

I'm instead going to propose we add a docker config to download the files
over http, by default it will use the same images that were used by the
undercloud
https://review.openstack.org/#/c/563072/1



>
>
>>
>>
>>> thanks,
>>> Derek
>>>
>>> 1 - https://github.com/openstack/python-tripleoclient/blob/3cf44
>>> eb/tripleoclient/v1/overcloud_image.py#L421-L433
>>> 2 - https://github.com/openstack/python-tripleoclient/blob/3cf44
>>> eb/tripleoclient/v1/overcloud_image.py#L181
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> --
>> Best regards,
>> Bogdan Dobrelya,
>> Irc #bogdando
>>
>> 
>> __
>> 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

Re: [openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits

[Sergii Golovatiuk]

+1. Well done.

On Fri, Apr 20, 2018 at 11:23 AM, Jiří Stránský  wrote:
> +1!
>
> On 19.4.2018 19:01, Emilien Macchi wrote:
>>
>> Greetings,
>>
>> As you probably know mcornea on IRC, Marius Cornea has been contributing
>> on
>> TripleO for a while, specially on the upgrade bits.
>> Part of the quality team, he's always testing real customer scenarios and
>> brings a lot of good feedback in his reviews, and quite often takes care
>> of
>> fixing complex bugs when it comes to advanced upgrades scenarios.
>> He's very involved in tripleo-upgrade repository where he's already core,
>> but I think it's time to let him +2 on other tripleo repos for the patches
>> related to upgrades (we trust people's judgement for reviews).
>>
>> As usual, we'll vote!
>>
>> Thanks everyone for your feedback and thanks Marius for your hard work and
>> involvement in the project.
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best Regards,
Sergii Golovatiuk

__
OpenStack Development Mailing List (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] Technical Committee Status update, April 20th

[Thierry Carrez]

Hi!

This is the weekly summary of Technical Committee initiatives. You can
find the full list of currently-considered changes at:
https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923


== Recently-approved changes ==

* Adjust TC election target to 6 weeks before summit [1]
* Update docs job info to match current PTI [2]
* Goal updates: barbican
* New repos: tripleo-ha-utils, puppet-senlin

[1] https://review.openstack.org/#/c/560002/
[2] https://review.openstack.org/#/c/556576/

The main change this week is a TC charter change moving the dates for
future TC elections, six weeks away from the summit rather than just
three weeks away, giving more time for newly-elected members to plan
their summit presence. You can read the full TC charter here:

https://governance.openstack.org/tc/reference/charter.html


== Election season ==

We are renewing 7 seats from the Technical Committee's 13 seats.
We have 10 great candidates with some geographic diversity. Voting will
start early next week. If you have questions for the candidates, please
ask them on the mailing-list ASAP ! You can find details on the process at:

https://governance.openstack.org/election/


== Under discussion ==

We have two open patches which will probably wait until the end of the
election season to be finally approved.

The first one is a review proposing the split of the kolla-kubernetes
deliverable out of the Kolla team. The various teams involved are coming
to an agreement that Kolla-k8s should be abandoned in favor of
OpenStack-Helm. A (new) change should be proposed soon to do that. If
you have an opinion on that, please chime in on the (currently-proposed)
review or the Kolla team ML thread:

https://review.openstack.org/#/c/552531/
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129452.html

The other discussion is around the proposed Adjutant project team
addition. At this point the discussion is expected to restart after the
election, and culminate in a Forum session in Vancouver where we hope
the various involved parties will be able to discuss more directly. You
can jump in the discussion here:

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


== TC member actions/focus/discussions for the coming week(s) ==

Voting will be open to renew part of the TC next week.

I also started a thread around potential topics the joint
Board+TC+UC+Staff meeting in Vancouver, please join in if you have
suggestions:

http://lists.openstack.org/pipermail/openstack-dev/2018-April/129428.html


== Office hours ==

To be more inclusive of all timezones and more mindful of people for
which English is not the primary language, the Technical Committee
dropped its dependency on weekly meetings. So that you can still get
hold of TC members on IRC, we instituted a series of office hours on
#openstack-tc:

* 09:00 UTC on Tuesdays
* 01:00 UTC on Wednesdays
* 15:00 UTC on Thursdays

Feel free to add your own office hour conversation starter at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Cheers,

-- 
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] [tripleo] Proposing Marius Cornea core on upgrade bits

[Jiří Stránský]

+1!

On 19.4.2018 19:01, Emilien Macchi wrote:

Greetings,

As you probably know mcornea on IRC, Marius Cornea has been contributing on
TripleO for a while, specially on the upgrade bits.
Part of the quality team, he's always testing real customer scenarios and
brings a lot of good feedback in his reviews, and quite often takes care of
fixing complex bugs when it comes to advanced upgrades scenarios.
He's very involved in tripleo-upgrade repository where he's already core,
but I think it's time to let him +2 on other tripleo repos for the patches
related to upgrades (we trust people's judgement for reviews).

As usual, we'll vote!

Thanks everyone for your feedback and thanks Marius for your hard work and
involvement in the project.



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




__
OpenStack Development Mailing List (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] about cloud-init

[Huang, Haibin]

Hi All,

I have a problem about cloud-init.
I want to both transfer files and execute script. So I give below script to 
user-data when I create instance.
#cloud-config
write_files:
-   encoding: b64
content: H4sICMxh2VoAA2hoYgCzKE5JK07hAgDCo1pOBw==
owner: root:root
path: /root/hhb.gz
permissions: '0644'

#!/bin/bash
mkdir -p /home/ubuntu/config

but, I can't get /root/hhb.gz and /home/Ubuntu/config.
If I separate transfer files and execute script. It is ok.
Any idea?

Below is my debug info

ubuntu@onap-hhb7:~$ sudo cloud-init --version

sudo: unable to resolve host onap-hhb7

cloud-init 0.7.5



security-groupsubuntu@onap-hhb7:~$ curl  
http://169.254.169.254/2009-04-04/user-data

#cloud-config

write_files:

-   encoding: b64

content: H4sICMxh2VoAA2hoYgCzKE5JK07hAgDCo1pOBw==

owner: root:root

path: /root/hhb.gz

permissions: '0644'



#!/bin/bash

mkdir -p /home/ubuntu/config



ubuntu@onap-hhb7:~$ sudo ls /root/ -a

.  ..  .bashrc  .profile  .ssh



ubuntu@onap-hhb7:/var/lib/cloud/instance$ ls

boot-finished datasource  obj.pkl  semuser-data.txt.i  
vendor-data.txt.i

cloud-config.txt  handlersscripts  user-data.txt  vendor-data.txt

ubuntu@onap-hhb7:/var/lib/cloud/instance$ sudo cat user-data.txt

sudo: unable to resolve host onap-hhb7

#cloud-config

write_files:

-   encoding: b64

content: H4sICMxh2VoAA2hoYgCzKE5JK07hAgDCo1pOBw==

owner: root:root

path: /root/hhb.gz

permissions: '0644'



#!/bin/bash

mkdir -p /home/ubuntu/config


---
Huang.haibin
11628530
86+18106533356

__
OpenStack Development Mailing 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] Proposing Marius Cornea core on upgrade bits

[Yurii Prokulevych]

+1 Well deserved!

On Thu, 2018-04-19 at 18:05 +, Juan Antonio Osorio wrote:
> +1 :D hell yeah!
> 
> On Thu, 19 Apr 2018, 20:05 John Fulton,  wrote:
> > +1
> > 
> > On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi  > > wrote:
> > > Greetings,
> > >
> > > As you probably know mcornea on IRC, Marius Cornea has been
> > contributing on
> > > TripleO for a while, specially on the upgrade bits.
> > > Part of the quality team, he's always testing real customer
> > scenarios and
> > > brings a lot of good feedback in his reviews, and quite often
> > takes care of
> > > fixing complex bugs when it comes to advanced upgrades scenarios.
> > > He's very involved in tripleo-upgrade repository where he's
> > already core,
> > > but I think it's time to let him +2 on other tripleo repos for
> > the patches
> > > related to upgrades (we trust people's judgement for reviews).
> > >
> > > As usual, we'll vote!
> > >
> > > Thanks everyone for your feedback and thanks Marius for your hard
> > work and
> > > involvement in the project.
> > > --
> > > Emilien Macchi
> > >
> > >
> > ___
> > ___
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > subscribe
> > > 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:unsu
> > bscribe
> > 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:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

Thanks a lot for your sharing, that's good info, just curious why [1] need
zip and base64 encode if my understand is correct
I was told nova need format should be pure vfat or iso9660, I assume it's
because actually the config drive itself is making by iso by default
then wrap a zip/base64 format ... thanks

[1]
https://github.com/openstack/nova/blob/324899c621ee02d877122ba3412712ebb92831f2/nova/virt/ironic/driver.py#L977

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



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

Date:   04/19/2018 12:02 AM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat



On Wed, Apr 18, 2018 at 10:56 AM, Matthew Booth  wrote:

  > I agree with Mikal that needing more agent behavior than cloud-init
  does
  > a disservice to the users.
  >
  > I feel like we get a lot of "but no, my hypervisor is special!"
  > reasoning when people go to add a driver to nova. So far, I think
  > they're a lot more similar than people think. Ironic is the weirdest
  one
  > we have (IMHO and no offense to the ironic folks) and it can support
  > configdrive properly.

  I was going to ask this. Even if the contents of the disk can't be
  transferred in advance... how does ironic do this? There must be a
  way.

I'm not sure if this is a rhetorical question, so I'll just answer it. :)
We basically build the configdrive in nova-compute, then gzip and base64
it, and send it to ironic with the deploy request. On the ironic side, we
unpack it and write it to the end of the boot disk.

https://github.com/openstack/nova/blob/324899c621ee02d877122ba3412712ebb92831f2/nova/virt/ironic/driver.py#L952-L985


// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=oGbSbjsg1aTX1kg1lAQIkEY8abfQ9632w8YmP3Lrt-U=Q8_XusVUibDx7ee5WguroOVm00Fl4rw2XSNEHIVOGb0=



__
OpenStack Development Mailing 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] which SDK to use?

[Adrian Turjak]

What version of the SDK are you using?On 20 Apr. 2018 19:28, Chris Friesen  wrote:On 04/19/2018 09:19 PM, Adrian Turjak wrote:
> On 20/04/18 01:46, Chris Friesen wrote:
>> On 04/19/2018 07:01 AM, Jeremy Stanley wrote:
>>> Or, for that matter, leverage OpenStackSDK's ability to pass
>>> arbitrary calls to individual service APIs when you need something
>>> not exposed by the porcelain layer.
>>
>> Is that documented somewhere?  I spent some time looking at
>> https://docs.openstack.org/openstacksdk/latest/ and didn't see
>> anything that looked like that.
>>
> Not that I believe, but basically it amounts to that on any service
> proxy object you can call .get .post etc. So if the SDK doesn't yet
> support a given feature, you can still use the feature yourself, but you
> need to do some raw requests work, which honestly isn't that bad.
>
> servers = list(conn.compute.servers())
> vs
> servers_resp = conn.compute.get("/servers")
I think the second statement above is not quite right.
 >>> from openstack import connection
 >>> conn = connection.Connection(auth_url=)
 >>> [flavor.name for flavor in conn.compute.flavors()]
[u'small', u'medium']
 >>> conn.compute.get("/servers")
Traceback (most recent call last):
   File "", line 1, in 
AttributeError: 'Proxy' object has no attribute 'get'
Chris
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] which SDK to use?

[Chris Friesen]

On 04/19/2018 09:19 PM, Adrian Turjak wrote:

On 20/04/18 01:46, Chris Friesen wrote:

On 04/19/2018 07:01 AM, Jeremy Stanley wrote:



Or, for that matter, leverage OpenStackSDK's ability to pass
arbitrary calls to individual service APIs when you need something
not exposed by the porcelain layer.


Is that documented somewhere?  I spent some time looking at
https://docs.openstack.org/openstacksdk/latest/ and didn't see
anything that looked like that.


Not that I believe, but basically it amounts to that on any service
proxy object you can call .get .post etc. So if the SDK doesn't yet
support a given feature, you can still use the feature yourself, but you
need to do some raw requests work, which honestly isn't that bad.

servers = list(conn.compute.servers())
vs
servers_resp = conn.compute.get("/servers")


I think the second statement above is not quite right.

>>> from openstack import connection
>>> conn = connection.Connection(auth_url=)
>>> [flavor.name for flavor in conn.compute.flavors()]
[u'small', u'medium']
>>> conn.compute.get("/servers")
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'Proxy' object has no attribute 'get'

Chris

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [all][infra] ubuntu-bionic and legacy nodesets

[Jean-Philippe Evrard]

That's very cool.
Any idea of the repartition of nodes xenial vs bionic? Is that a very
restricted amount of nodes?


On 20 April 2018 at 00:37, Paul Belanger  wrote:
> Greetings,
>
> With ubuntu-bionic release around the corner we'll be starting discussions 
> about
> migrating jobs from ubuntu-xenial to ubuntu-bionic.
>
> On topic I'd like to raise, is round job migrations from legacy to native
> zuulv3.  Specifically, I'd like to propose we do not add legacy-ubuntu-bionic
> nodesets into openstack-zuul-jobs. Projects should be working towards moving
> away from the legacy format, as they were just copypasta from our previous JJB
> templates.
>
> Projects would still be free to move them intree, but I would highly encourage
> projects do not do this, as it only delays the issue.
>
> The good news is the majority of jobs have already been moved to native zuulv3
> jobs, but there are still some projects still depending on the legacy 
> nodesets.
> For example, tox bases jobs would not be affected.  It mostly would be dsvm
> based jobs that haven't been switch to use the new devstack jobs for zuulv3.
>
> -Paul
>
> __
> OpenStack Development Mailing List (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-Infra] Stop supporting bindep-fallback.txt moving forward

[Andreas Jaeger]

On 2018-04-20 01:15, Paul Belanger wrote:
> Greetings,
> 
> I'd like to propose we hard freeze changes to bindep-fallback.txt[1] and push
> projects to start using a local bindep.txt file.
> 
> This would mean, moving forward with ubuntu-bionic, if a project was still
> depending on bindep-fallback.txt, their jobs may raise a syntax error.
> 
> In fact, today ubuntu-bionic does seem to pass properly with
> bindep-fallback.txt, but perhaps we prime it with a bad package on purpose to
> force the issue. As clarkb points out, the downside to this it does make it
> harder for projects to be flipped to ubuntu-bionic.  It is possible we could
> also prime gerrit patches for projects that are missing bindep.txt to help 
> push
> this effort along.
> 
> Thoughts?
> 
> [1] 
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/nodepool/elements/bindep-fallback.txt

This might break all stable branches as well. Pushing those changes in
is a huge effort ;( Is that worth it?


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-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [docs] When should we say 'run as root' in the docs?

[Andreas Jaeger]

On 2018-04-20 00:11, Matt Riedemann wrote:
> How loose are we with saying things like, "you should run this as root"
> in the docs?
> 
> I was triaging this nova bug [1] which is saying that the docs should
> tell you to run nova-status (which implies also nova-manage) as root,
> but isn't running admin-level CLIs implied that you need root, or
> something with access to those commands (sudo)?
> 
> I'm not sure how prescriptive we should be with stuff like this in the
> docs because if we did start saying this, I feel like we'd have to say
> it everywhere.
> 
> [1] https://bugs.launchpad.net/nova/+bug/1764530

We use in openstack-manuals "# root-command" and "$ non-root command", see:
https://docs.openstack.org/install-guide/common/conventions.html

so, just add the "#" for thse.

But looking at
https://git.openstack.org/cgit/openstack/nova/tree/doc/source/install/verify.rst#n103,
it is there - so, closed invalid IMHO,

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] [neutron][horizon][l2gw] Unable to create a floating IP

[Cory Hawkless]

I’m also seeing this issue, but with Routers and networks as well.
The apache server running horizon logs the following

ERROR horizon.tables.base Error while checking action permissions.
Traceback (most recent call last):
  File "/usr/share/openstack-dashboard/horizon/tables/base.py", line 1389, in 
_filter_action
return action._allowed(request, datum) and row_matched
  File "/usr/share/openstack-dashboard/horizon/tables/actions.py", line 139, in 
_allowed
self.allowed(request, datum))
  File 
"/usr/share/openstack-dashboard/openstack_dashboard/dashboards/project/networks/tables.py",
 line 85, in allowed
usages = quotas.tenant_quota_usages(request, targets=('network', ))
  File "/usr/share/openstack-dashboard/horizon/utils/memoized.py", line 95, in 
wrapped
value = cache[key] = func(*args, **kwargs)
  File "/usr/share/openstack-dashboard/openstack_dashboard/usage/quotas.py", 
line 419, in tenant_quota_usages
_get_tenant_network_usages(request, usages, disabled_quotas, tenant_id)
  File "/usr/share/openstack-dashboard/openstack_dashboard/usage/quotas.py", 
line 320, in _get_tenant_network_usages
details = neutron.tenant_quota_detail_get(request, tenant_id)
  File "/usr/share/openstack-dashboard/openstack_dashboard/api/neutron.py", 
line 1457, in tenant_quota_detail_get
response = neutronclient(request).get('/quotas/%s/details' % tenant_id)
  File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 
354, in get
headers=headers, params=params)
  File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 
331, in retry_request
headers=headers, params=params)
  File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 
294, in do_request
self._handle_fault_response(status_code, replybody, resp)
  File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 
269, in _handle_fault_response
exception_handler_v20(status_code, error_body)
 File "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 93, 
in exception_handler_v20
request_ids=request_ids)
Forbidden: User does not have admin privileges: Cannot GET resource for non 
admin tenant.
Neutron server returns request_ids: ['req-3db6924c-1937-4c34-b5fa-bd3ae52f0c10']

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Monday, 9 April 2018 10:03 PM
To: OpenStack List 
Subject: [openstack-dev] [neutron][horizon][l2gw] Unable to create a floating IP

Hi,
From Queens onwards we have a issue with horizon and L2GW. We are unable to 
create a floating IP. This does not occur when using the CLI only via horizon. 
The error received is
‘Error: User does not have admin privileges: Cannot GET resource for non admin 
tenant. Neutron server returns request_ids: 
['req-f07a3aac-0994-4d3a-8409-1e55b374af9d']’
This is due to: 
https://github.com/openstack/networking-l2gw/blob/master/networking_l2gw/db/l2gateway/l2gateway_db.py#L316
This worked in Ocata and not sure what has changed since then ☹. Maybe in the 
past the Ocata quota’s were not checking L2gw.
Any ideas?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev