date:20171010

Hello!TC Nomination is now over. The official candidate list is available
on the election website[0].We now enter the campaigning period where
candidates and electorate may debate their statements.The election will
start this Saturday.Thank you,Kendall Nelson (diablo_rojo)
[0]: http://governance.openstack.org/election/#pike-tc-candidates
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][election] TC non-candidacy

2017-10-10 Thread Amy Marrich

Monty,

Thank you for everything you've done on the TC and in and for the community
as well!

Glad you're not going anywhere!!!

Amy (spotz)

On Tue, Oct 10, 2017 at 6:40 PM, Monty Taylor  wrote:

> Hey everybody!
>
> I have decided not to seek reelection for the TC.
>
> I have had the honor and privilege of serving you on the TC and it's
> predecessor the PPB since the fall of 2011 (with one six month absence that
> I blame on Jay Pipes)
>
> There are a wealth of amazing people running for the TC this cycle, many
> of whom have a different genetic, cultural or geographic background than I
> do. I look forward to seeing how they shepherd our amazing community.
>
> I am not going anywhere. We're just getting Zuul v3 rolled out, there's a
> pile of work to do to merge and rationalize shade and openstacksdk and I
> managed to sign myself up to implement application credentials in Keystone.
> I still haven't even managed to convince all of you that Floating IPs are a
> bad idea...
>
> Thank you, from the bottom of my heart, for the trust you have placed in
> me. I look forward to seeing as many of you as I can in Sydney, Vancouver,
> Berlin and who knows where else.
>
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][election] TC non-candidacy

2017-10-10 Thread Monty Taylor


Hey everybody!

I have decided not to seek reelection for the TC.

I have had the honor and privilege of serving you on the TC and it's 
predecessor the PPB since the fall of 2011 (with one six month absence 
that I blame on Jay Pipes)


There are a wealth of amazing people running for the TC this cycle, many 
of whom have a different genetic, cultural or geographic background than 
I do. I look forward to seeing how they shepherd our amazing community.


I am not going anywhere. We're just getting Zuul v3 rolled out, there's 
a pile of work to do to merge and rationalize shade and openstacksdk and 
I managed to sign myself up to implement application credentials in 
Keystone. I still haven't even managed to convince all of you that 
Floating IPs are a bad idea...


Thank you, from the bottom of my heart, for the trust you have placed in 
me. I look forward to seeing as many of you as I can in Sydney, 
Vancouver, Berlin and who knows where else.


Monty

__
OpenStack Development Mailing 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-Infra] [zuul] Change publication interface to be directories on node, not executor

2017-10-10 Thread Monty Taylor


Hey everybody!

I'd like to make a proposal for changing how we do logs/artifacts/docs 
collection based on the last few weeks/months of writing things- and of 
having to explain to people how to structure build and publish jobs over 
the last couple of weeks.


tl;dr - I'd like to change the publication interface to be directories 
on the remote node, not directories on the executor


Rationale
=

If jobs have to copy files back to the executor as part of the 
publication interface, then the zuul admins can't change the mechanism 
of how artifacts, logs or docs are published without touching a ton of 
potentially in-tree job content.


Doing so should also allow us to stop having a second copy of build 
logic in the artifact release jobs.


Implementation
==

Define a root 'output' dir on the remote nodes. Different types of 
output can be collected by putting them into subdirectories of that dir 
on the remote nodes and expecting that base jobs will take care of them.


People using jobs defined in zuul-jobs should define a variable 
"zuul_output_dir", either in site-variables or in their base job. Jobs 
in zuul-jobs can and will depend on that variable existing - it will be 
considered part of the base job interface zuul-jobs expects.


Jobs in zuul-jobs will recognize three specific types of job output:
* logs
* artifacts
* docs

Jobs in zuul-jobs will put job outputs into "{{ zuul_output_dir 
}}/logs", "{{ zuul_ouptut_dir }}/artifacts" and "{{ zuul_output_dir 
}}/docs" as appropriate.


A role will be added to zuul-jobs that can be used in base jobs that 
will ensure those directories all exist.


Compression
---

Deployers may choose to have their base job compress items in {{ 
zuul_output_dir }} as part of processing them, or may prefer not to 
depending on whether CPU or network is more precious. Jobs in zuul-jobs 
should just move/copy things into {{ zuul_output_dir }} on the node and 
leave compression, transfer and publication as a base-job operation.


Easy Output Copying
---

A role will also be added to zuul-jobs to facilitate easy/declarative 
output copying.


It will take as input a dictionary of files/folders named 
'zuul_copy_output'. The role will copy contents into {{ zuul_output_dir 
}} on the remote node and is intended to be used before output fetching 
in a base job's post-playook.


The input will be a dictionary so that zuul variable merging can be used 
for accumulating.


Keys of the dictionary will be things to copy. Valid values will be the 
type of output to copy:


* logs
* artifacts
* docs
* null   # ansible null, not the string null

null will be used for 'a parent job said to copy this, but this job 
wants to not do so'


The simple content copying role will not be flexible or powerful. People 
wanting more expressive output copying have all of the normal tools for 
moving files around at their disposal. It will obey the following rules:


* All files/folders will be copied if they exist, or ignored if they don't
* Items will be copied as-if 'cp -a' had been used.
* Order of files is undefined
* Conflicts between declared files are an error.

Jobs defined in zuul-jobs should not depend on the {{ zuul_copy_output 
}} variable for content they need copied in place on a remote node. Jobs 
defined in zuul-jobs should instead copy their output to {{ 
zuul_output_dir }} This prevents zuul deployers from being required to 
put the easy output copying role into their base jobs. Jobs defined in 
zuul-jobs may use the role behind the scenes.


Filter Plugin
-

Since the pattern of using a dictionary in job variables to take 
advantage of variable merging is bound to come up more than once, we'll 
define a filter plugin in zuul called 'zuul_list_from_value' (or some 
better name) that will return the list of keys that match a given value. 
So that given the following in a job defintion:


vars:
  zuul_copy_output:
foo/bar.html: logs
other/logs/here.html: logs
foo/bar.tgz: artifacts

Corresponding Ansible could do:

- copy:
src: {{ item }}
dest: {{ zuul_log_dir }}
  with_items: {{ zuul_copy_output | zuul_list_from_value(logs) }}

For OpenStack Today
===

We will define zuul_output_dir to be "{{ ansible_user_dir 
}}/zuul-output" in our site-variables.yaml file.


Implement the following in OpenStack's base job:

We will have the base job will include the simple copying role.

Logs


Base job post playbook will always grab {{ zuul_output_dir }}/logs from 
nodes, same as today:
* If there are more than one node, grab it into {{ zuul.executor.log_dir 
}}/{{ inventory_hostname }}.

* If only one node, grab into  {{ zuul.executor.log_dir }} directly

This will mean moving things like 'fetch-tox-output' logic into the 
'tox' role itself, so after it's run the appropriate tox logs will be 
copied to {{ zuul_output_dir }}/logs


Artifacts and docs
--

Base job will always ...

*

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

Seems really well thought out. Super impressed by the level of detail here.
Consolidation of duplicated code is pretty much always a good idea in my
book. Thanks for getting this rolling.

I am happy to review as you push patches. Might also be good to get Kaitlin
Farr involved too since she knows a lot in this area.

-Kendall (diablo_rojo)

On Tue, Oct 10, 2017 at 9:40 AM Alan Bishop  wrote:

> There is an ongoing effort to deprecate the ConfKeyManager, but care
> must be taken when migrating existing ConfKeyManager deployments to
> Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican,
> but the process of switching from one key manager to another will need
> to be done smoothly to ensure encrypted volumes continue to function
> during the migration period.
>
> One thing that will help the migration process is consolidating the
> two ConfKeyManager implementations (one in Cinder and one in Nova).
> The two are functionally identical, as dictated by the need to derive
> the exact same secret from the fixed_key. While it may seem counter-
> intuitive, adding a ConfKeyManager implementation to Castellan will
> facilitate the process of deprecating them in Cinder and Nova.
>
> To that end, I identified a series of small steps to get us there:
>
> 1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova
> so they are identical (right now their help texts are slightly
> different). This step avoids triggering a DuplicateOptError exception
> in the next step.
>
> 2) Add a ConfKeyManager implementation to Castellan. This essentially
> involves copying in one of the existing implementations (either Cinder's
> or Nova's).
>
> 3) Replace Cinder's and Nova's implementations with references to the
> one in Castellan. This can be done in a way that retains compatibility
> with the key_manager "backend" (was "api_class") config options
> currently used by Cinder and Nova. The code in
> cinder/keymgr/conf_key_manager.py and nova/keymgr/conf_key_manager.py
> will collapse down to this:
>
>   from castellan.key_manager import conf_key_manager
>
>   class ConfKeyManager(conf_key_manager.ConfKeyManager):
>   pass
>
> Having a common ConfKeyManager implementation will make it much
> easier to support migrating things to Barbican, and that's an important
> step toward the goal of deprecating the ConfKeyManager entirely.
>
> Please let me know your thoughts, as I plan to begin proposing patches.
>
> Regards,
>
> Alan Bishop
>
> __
> OpenStack Development Mailing 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] [FEMDC] Wed. 11. IRC Meeting 15:00 UTC

2017-10-10 Thread Matthieu Simonin

Hi all,

The next meeting is planned tomorrow/today

Wed. 11 Oct. 15:00 UTC

A draft agenda is available in the etherpad :

https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017
(line 1317 - at the end)

You are very welcome to amend it.

Best,

Matt

- Mail original -
> De: "Paul-Andre Raymond" 
> À: "OpenStack Development Mailing List (not for usage questions)" 
> , "OpenStack
> Operators" , "Openstack Users" 
> 
> Envoyé: Mercredi 27 Septembre 2017 16:56:52
> Objet: Re: [openstack-dev] [FEMDC] IRC Meeting today 15:00 UTC
> 
> Below is the link to the etherpad for our meeting.
> 
> 
> 
> On 9/27/17, 10:01 AM, "Paul-Andre Raymond" 
> wrote:
> 
> Dear all,
> 
> A gentle reminder for our meeting today (an hour from now).
> I believe today will be a short meeting.
> Draft agenda was prepared by our friends from INRIA at
> 
> https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017
> (line 1237)
> 
> Please feel free to add items.
> 
> Best,
> 
>  
> Paul-André
> --
>  
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
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] [FEMDC] Wed. 11. IRC Meeting 15:00 UTC

2017-10-10 Thread Matthieu Simonin

Hi all,

The next meeting is planned tomorrow/today

Wed. 11 Oct. 15:00 UTC

A draft agenda is available in the etherpad :

https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017
(line 1317 - at the end)

You are very welcome to amend it.

Best,

Matt

- Mail original -
> De: "Paul-Andre Raymond" 
> À: "OpenStack Development Mailing List (not for usage questions)" 
> , "OpenStack
> Operators" , "Openstack Users" 
> 
> Envoyé: Mercredi 27 Septembre 2017 16:56:52
> Objet: Re: [openstack-dev] [FEMDC] IRC Meeting today 15:00 UTC
> 
> Below is the link to the etherpad for our meeting.
> 
> 
> 
> On 9/27/17, 10:01 AM, "Paul-Andre Raymond" 
> wrote:
> 
> Dear all,
> 
> A gentle reminder for our meeting today (an hour from now).
> I believe today will be a short meeting.
> Draft agenda was prepared by our friends from INRIA at
> 
> https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017
> (line 1237)
> 
> Please feel free to add items.
> 
> Best,
> 
>  
> Paul-André
> --
>  
> 
> 
> 
> 
> __
> OpenStack Development Mailing 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] [Zaqar] Nominating gecong for Zaqar core

2017-10-10 Thread feilong

Hi team,

I would like to propose adding Cong Ge(gecong) for the Zaqar core team.
He has been an awesome contributor since joining the Zaqar team. And now
he is currently the most active non-core reviewer on Zaqar projects for
the last 180 days[1]. Cong has great technical expertise and contributed
many high quality patches. I'm sure he would be an excellent addition to
the team. If no one objects, I'll proceed and add him in a week from
now. Thanks.

[1] http://stackalytics.com/report/contribution/zaqar-group/180

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


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

[openstack-dev] [all] IMPORTANT Information about Zuul v3 rollout, the sequel

2017-10-10 Thread Monty Taylor


Hey everybody,

As noted by fungi yesterday:


http://lists.openstack.org/pipermail/openstack-dev/2017-October/123337.html

We are planning to roll Zuul v3 out to take over the gate again tomorrow.

Since then it has become evident that what people should be doing about 
that right now is unclear. SOO 


Things to Do Today to Prepare
=

* Please triage failures: As of right now we are aware of no SYSTEMIC 
issues that should cause v3 jobs to fail. If you have a job failing in 
the v3 check pipeline, you should at the very least triage it.


* Check the fixed issues and open issues etherpad when you triage:

  https://etherpad.openstack.org/p/zuulv3-fixed-issues

* Restart coming - only recheck things you're concerned about - Things 
are backed up on v3 due to capacity management, being down a cloud and 
running double jobs. We're about to restart v3 to pick up some changes. 
That will reset the v3 queues allowing you to recheck things to verify 
if they have been fixed and get a response more quickly.


* Read migration guide if you haven't already:

  https://docs.openstack.org/infra/manual/zuulv3.html

A Few Notes About Tomorrow
==

* The performance issues from before have been sorted out, so responding 
to issues should no longer take hours.


* The status page should also behave normally - it is currently in an 
exceptional state due to nodepool capacity management.


* We have a temporary high-priority check pipeline for project-config 
changes, so fixes to that repo will be able to merge quickly without 
blocking work in other repos.


* We'll be tracking known issues at:

  https://etherpad.openstack.org/p/zuulv3-issues

* Shifting jobs to being in-repo jobs is totally in-game so that you can 
iterate on things without us:



https://docs.openstack.org/infra/manual/zuulv3.html#moving-legacy-jobs-to-projects

* Reach out at the first sign off issues - and roll up your sleeves. 
We're in #openstack-infra and we'll be primed to jump immediately on any 
issues you're seeing, but we can't do that if we don't know about the 
issues. The teams that  have been the most successful so far have been 
the ones who have been talking to us and who have had someone dive in 
and migrate jobs away from legacy jobs. We know not everyone has the 
bandwidth to have a person dive in on reworking jobs tomorrow, but at 
least let us know if you're having issues.


The most important thing is to communicate with us.

We cannot say thank you enough for your patience over the last week and 
a half. We expect tomorrow's 'rollout, the sequel' to be MUCH smoother, 
but there will surely still be issues. The fixes from the last week 
should allow us to respond to those issues much more quickly.


Thanks,
Monty

__
OpenStack Development Mailing 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] [tripleo] Reminder on bug triage

I think it's useful to share a little reminder about how do we create
and manage bugs in TripleO.

Bugs in TripleO are reported via launchpad.net/tripleo.
The steps are well documented in Launchpad (you have boxes that
explain exactly what a bug report should be like) but here are a few
reminders.

- Find a title related to the problem:

Good title:
"Mistral workflows tried to use Keystone v2.0 (removed upstream)"
"Duplication error when running Ceph OSD & Ceph Mon on same nodes"

Bad titles:
"Overcloud stack failed to deploy"
"gate-tripleo-ci-centos-7-nonha-multinode-oooq failed in periodic jobs"

If you're busy and can't spend time to investigate, find some help on
IRC or on this mailing-list.

- Put good descriptions, with details at how to reproduce the problem.
Just please don't throw a random Python Trace or a link to a CI job.
Make a little research so our team can easily help.

- Set status to Triaged as a first step, or In progress if you're
actively working on it.

- Set an Importance. Keep in mind Critical is only used when there is
no way you can deploy TripleO with this bug (use it wisely).

- Set a milestone, or when do you think we should fix the bug. High /
critical: queens-1. Medium / low: queens-2, etc.

- Set some tags and don't invent tags, there is auto-completion and
tags are documented here:
https://github.com/openstack/tripleo-specs/blob/master/specs/policy/bug-tagging.rst#tags

That's all. If you can make that, you'll help to solve the bugs more
quickly and everyone is happy.

Any question or feedback is welcome.
Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] [docs] Flagging deprecated releases

Excerpts from Jimmy McArthur's message of 2017-10-10 15:40:05 -0500:
> 
> > Doug Hellmann 
> > October 10, 2017 at 2:46 PM
> >
> >
> > When I was updating the landing pages and adding the old release series,
> > I identified 5 different statuses: obsolete, EOL, maintained, current, and
> > development. Those are encoded in the SERIES_INFO data in the template
> > generator
> > (http://git.openstack.org/cgit/openstack/openstack-manuals/tree/tools/www-generator.py#n43)
> >
> > Austin is an example of an obsolete series, and there's some text on
> > that landing page about "no longer supported by the community".
> > https://docs.openstack.org/austin/
> >
> > It looks like I used the same text for Icehouse, which is an EOL
> > release. https://docs.openstack.org/icehouse/
> >
> > The text for Ocata just says "this is not the latest release":
> > https://docs.openstack.org/ocata/
> >
> > The text for Pike, the "current" release, says "this is the latest
> > release": https://docs.openstack.org/pike/
> >
> > And Queens says "this release is currently under development":
> > https://docs.openstack.org/queens/
> >
> > I don't care especially much about the text, and we can make the badges
> > and landing pages match once we decide what we want, but I think we need
> > the 4 distinct statuses (where obsolete and EOL are the same).
> OK. No problem at all on the 4 distinct statuses. Makes sense :) In 
> fact, it might be nice to use these SERIES_INFO to do slight color 
> shifts. Like EOL = red, Latest release = Green, etc...  Then we could 
> put a little key on the main docs page and in an info icon on the banner 
> so people know what they're looking at. Thoughts?

I like the idea of using colors, as an addition to the text.

> >
> > On a technical note from someone who has poor web-fu, will we be
> > able to inject text into the overlay for old docs without rebuilding
> > them?
> > For example, we can update the pike docs now but when that
> > branch goes EOL we want the text to update to say that without us
> > having to rebuild the pike docs. Ideally we would be able to just update
> > the SERIES_INFO settings and the next time a pike page is loaded the
> > correct badge will appear.
> Right. We could grab the variable and populate the value using 
> javascript w/o having to go back and edit all the old docs. The more 
> automated we can make it the better :)

OK, great. We could spit out some JSON or something if that's easier to
consume. I'm happy to help with that side of it, so let me know what
you'd like to see.

> >
> > 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
> > Jimmy McArthur 
> > October 10, 2017 at 2:15 PM
> > Hi all -
> >
> > I'm following up on the PTG action item to add a CSS banner for older 
> > releases (e.g. https://releases.openstack.org/newton/index.html).  
> > Does anyone have specific language they'd like to see here or should I 
> > just riff it?
> >
> > I was considering a CSS overlay similar to what you see when you 
> > scroll down below the nav (e.g. 
> > https://www.openstack.org/software/security/).  Here's a quick comp: 
> > https://www.screencast.com/t/Kbz0Sh8uRb7
> >
> > If you like the direction this is going, I'll send along to people 
> > that are real designers (not me).
> >
> > Cheers,
> > Jimmy
> >
> > __ 
> >
> > OpenStack Development Mailing 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] [docs] Flagging deprecated releases

2017-10-10 Thread Jimmy McArthur

Doug Hellmann
October 10, 2017 at 2:46 PM

When I was updating the landing pages and adding the old release series,
I identified 5 different statuses: obsolete, EOL, maintained, current, and
development. Those are encoded in the SERIES_INFO data in the template
generator
(http://git.openstack.org/cgit/openstack/openstack-manuals/tree/tools/www-generator.py#n43)

Austin is an example of an obsolete series, and there's some text on
that landing page about "no longer supported by the community".
https://docs.openstack.org/austin/

It looks like I used the same text for Icehouse, which is an EOL
release. https://docs.openstack.org/icehouse/

The text for Ocata just says "this is not the latest release":
https://docs.openstack.org/ocata/

The text for Pike, the "current" release, says "this is the latest
release": https://docs.openstack.org/pike/

And Queens says "this release is currently under development":
https://docs.openstack.org/queens/

I don't care especially much about the text, and we can make the badges
and landing pages match once we decide what we want, but I think we need
the 4 distinct statuses (where obsolete and EOL are the same).
OK. No problem at all on the 4 distinct statuses. Makes sense :) In
fact, it might be nice to use these SERIES_INFO to do slight color
shifts. Like EOL = red, Latest release = Green, etc... Then we could
put a little key on the main docs page and in an info icon on the banner
so people know what they're looking at. Thoughts?

On a technical note from someone who has poor web-fu, will we be
able to inject text into the overlay for old docs without rebuilding
them?
For example, we can update the pike docs now but when that
branch goes EOL we want the text to update to say that without us
having to rebuild the pike docs. Ideally we would be able to just update
the SERIES_INFO settings and the next time a pike page is loaded the
correct badge will appear.
Right. We could grab the variable and populate the value using
javascript w/o having to go back and edit all the old docs. The more
automated we can make it the better :)

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
Jimmy McArthur
October 10, 2017 at 2:15 PM
Hi all -

I'm following up on the PTG action item to add a CSS banner for older
releases (e.g. https://releases.openstack.org/newton/index.html).
Does anyone have specific language they'd like to see here or should I
just riff it?

I was considering a CSS overlay similar to what you see when you
scroll down below the nav (e.g.
https://www.openstack.org/software/security/). Here's a quick comp:
https://www.screencast.com/t/Kbz0Sh8uRb7

If you like the direction this is going, I'll send along to people
that are real designers (not me).

Cheers,
Jimmy

OpenStack Development Mailing 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] [octavia] Proposing Nir Magnezi as Octavia core reviewer

2017-10-10 Thread Nir Magnezi

Thanks everyone for your votes :-)
I'm really happy to become a member of this great team!

Nir

On Tue, Oct 10, 2017 at 1:28 AM, Michael Johnson 
wrote:

> Ok, that is quorum.
>
> Congratulations Nir!
>
> Michael
>
>
> On Mon, Oct 9, 2017 at 3:18 PM, Adam Harwell  wrote:
> > +1
> >
> >
> > On Thu, Oct 5, 2017, 05:48 Daniel Mellado 
> > wrote:
> >>
> >> +1
> >>
> >> Go, Nir, Go!
> >>
> >> congrats!
> >>
> >> On 10/05/2017 03:51 AM, German Eichberger wrote:
> >> > +1
> >> >
> >> > Welcome Nir, well earned.
> >> >
> >> > German
> >> >
> >> > On 10/4/17, 4:28 PM, "Michael Johnson"  wrote:
> >> >
> >> > Hello OpenStack folks,
> >> >
> >> > I would like to propose Nir Magnezi as a core reviewer on the
> >> > Octavia project.
> >> >
> >> > He has been an active contributor to the Octavia projects for a
> few
> >> > releases and has been providing solid patch review comments. His
> >> > review stats are also in line with other core reviewers.
> >> >
> >> > Octavia cores, please reply to this e-mail with your
> >> > agreement/disagreement to this proposal.
> >> >
> >> > Michael
> >> >
> >> >
> >> > 
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> >
> >> >
> >> > 
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc] [all] TC Report 41

2017-10-10 Thread Chris Dent

( With brackets: https://anticdent.org/tc-report-41.html )

If there's a unifying theme in the mix of discussions that have
happended in `#openstack-tc` this past week, it is power: who has it,
what does it really mean, and how to exercise it.

This is probably because it is election season. After a slow start
there is now a [rather large number of
candidates](https://governance.openstack.org/election/#queens-tc-candidates),
a very diverse group. Is great to see.

On
[Wednesday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-04.log.html),
there were questions about the
[constellations](https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html#navigating-with-constellations)
idea mooted in the TC Vision Statement and the extent to which the TC has power
to enforce integration between projects. Especially those which are considered
_core_ and those that are not (in this particular case Zaqar). The precedent
here is that the TC has minimal direct power in such cases (each project is
fairly autonomous), whereas individuals, some of whom happen to be on the TC,
do have power, by virtue of making specific changes in code. The role of the TC
in these kinds of situations is in making ideas and approaches visible (like
constellations) and drawing attention to needs (like the [top 5
list](https://governance.openstack.org/tc/reference/top-5-help-wanted.html)).

[Thursday's](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-05.log.html#t2017-10-05T15:00:01)
discussion provides an interesting counterpoint. There some potential
candidates expressed concern about running because they were interested in
maintaining the good things that OpenStack has and had no specific agenda for
drastic or dramatic change while candidates often express what they'd like to
change. This desire for stability is probably a good fit, because in some ways
the main power of the TC is choosing which projects to let into the club and in
extreme cases kicking bad projects out. That latter is effectively the nuclear
option: since nobody wants to use it the autonomy of projects is enhanced.

Continuing the rolling segues: On the same day, ttx provided access
to [the answers to two
questions](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-05.log.html#t2017-10-05T15:46:43)
related to "developer satisfaction" that were added to the PTG survey.
These aren't the original questions, they were adjusted to be
considerably more open ended than the originals, which were
effectively yes or no questions. The questions:

* What is the most important thing we should do to improve the
OpenStack software over the next year?
* What is one change that would make you happier as an OpenStack
Upstream developer?

I intend to analyse and group these for themes when I have the time,
but just reading them en masse is interesting if you have some time. One
emerging theme is that some projects are perceived to have too much
power.

Which bring us to today's [office
hours](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-10.log.html#t2017-10-10T09:01:40)
where the power to say yes or no to a project was discussed again.

First up [Glare](https://review.openstack.org/#/c/479285/)
There are a few different (sometimes overlapping) camps:

* If we can't come up with reasons to _not_ include them, we should
include them.
* If we can't come up with reasons to include then, we should _not_
include them.
* If they are going to cause difficulties for Glance or the stability of
the images API, that's a risk.
* If the Glare use case is abstract storage of stuff, and that's
useful for everyone, why should Glare be an OpenStack project and
not a more global or general open source project?

This needs to be resolved soon. It would be easier to figure out if
there was already a small and clear use case being addressed by Glare
with a clear audience.

Then [Mogan](https://review.openstack.org/#/c/508400/), a bare metal
compute service. There the camps are:

* The overlaps with Nova and Ironic, especially at the API-level
are a significant _problem_.
* The overlaps with Nova and Ironic, especially at the API-level
are a significant _opportunity_.

Straight [into the
log](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-10.log.html#t2017-10-10T09:55:08)
for more.

Finally, we landed on the topic of whether there's anything the TC can
do to help with the [extraction of
placement](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-10.log.html#t2017-10-10T10:06:18)
from nova.

--
Chris Dent (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [qa][infra][devstack] Changes to devstack-core for zuul v3 migration

2017-10-10 Thread Sean Dague

On 10/10/2017 04:22 PM, Dean Troyer wrote:
> On Tue, Oct 10, 2017 at 1:15 PM, Andrea Frittoli
>  wrote:
>> - we will treat +1 from infra-core members on devstack changes in the
>> ansible bits as +2
>> - add clarkb to devstack-core, since he's quite aware of the the devstack
>> codebase
> 
> +2 on both of these proposals!

Agreed +2.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

Excerpts from Thomas Goirand's message of 2017-10-10 22:03:44 +0200:
> On 10/10/2017 01:16 PM, Jesse Pretorius wrote:
> > Regardless, given that this is not functionality currently> available for 
> > setuptools, distutils or pbr it would seem
> > that this functionality (or another applicable workaround)
> > would have to be carried by Debian packaging until such
> > time that such a facility exists in the python tooling.
> 
> We don't control setuptools/distutils directly. The only thing we
> control is PBR. So my proposal is:
> 
> 1/ Design a new config_files directive in setup.cfg and patch PBR so
> that it understands it.

We are doing other work to make pbr have *fewer* features. I'm not sure
this is the sort of direction we would want to go, although I'm not
voting -2 right now.

I still think we should just be looking at these files as sample
data and not active configuration files when we put them into the sdist
or wheel.

Doug

> 
> Considering the python module named foo, this could end up like this:
> 
> [files]
> config_files_dest = PYBASE/foo
> config_files = foo.cfg
> 
> then PYBASE would be expanded to /usr/lib/python2.7/dist-packages in the
> case of Debian + Python 2.7.
> 
> or, as another example:
> 
> [files]
> config_files_dest = foo
> config_files = foo.cfg
> 
> then foo.cfg would end up in /usr/share/foo/foo.cfg unless the env var
> OSLO_CONFIG_FILES_DEST is set (for example to /usr/share/foo-common, or
> to /etc/foo). I don't really mind whatever is decided for the
> non-packaging use case (ie: pip install ?).
> 
> 2/ Make PBR to read the destination path from something configurable at
> a packaging level, that would overwrite the default behavior, so that we
> could have whatever the package maintainer decides.
> 
> 3/ When the new PBR release has the new feature, let individual packages
> use the new config_files directive that would simply list the config
> files with the preselected destination.
> 
> Does this seem a good plan? Please comment on the above.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

__
OpenStack Development Mailing 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] Unbranched repositories and testing

On Fri, Oct 6, 2017 at 5:09 AM, Jiří Stránský  wrote:
> On 5.10.2017 22:40, Alex Schultz wrote:
>>
>> Hey folks,
>>
>> So I wandered across the policy spec[0] for how we should be handling
>> unbranched repository reviews and I would like to start a broader
>> discussion around this topic.  We've seen it several times over the
>> recent history where a change in oooqe or tripleo-ci ends up affecting
>> either a stable branch or an additional set of jobs that were not run
>> on the change.  I think it's unrealistic to run every possible job
>> combination on every submission and it's also a giant waste of CI
>> resources.  I also don't necessarily agree that we should be using
>> depends-on to prove things are fine for a given patch for the same
>> reasons. That being said, we do need to minimize our risk for patches
>> to these repositories.
>>
>> At the PTG retrospective I mentioned component design structure[1] as
>> something we need to be more aware of. I think this particular topic
>> is one of those types of things where we could benefit from evaluating
>> the structure and policy around these unbranched repositories to see
>> if we can improve it.  Is there a particular reason why we continue to
>> try and support deployment of (at least) 3 or 4 different versions
>> within a single repository?  Are we adding new features that really
>> shouldn't be consumed by these older versions such that perhaps it
>> makes sense to actually create stable branches?  Perhaps there are
>> some other ideas that might work?
>
>
> Other folks probably have a better view of the full context here, but i'll
> chime in with my 2 cents anyway..
>
> I think using stable branches for tripleo-quickstart-extras could be worth
> it. The content there is quite tightly coupled with the expected TripleO
> end-user workflows, which tend to evolve considerably between releases.
> Branching extras might be a good way to "match the reality" in that sense,
> and stop worrying about breaking older workflows. (Just recently it came up
> that the upgrade workflow in O is slightly updated to make it work in P, and
> will change quite a bit for Q. Minor updates also changed between O and P.)
>
> I'd say that tripleo-quickstart is a different story though. It seems fairly
> release-agnostic in its focus. We may want to keep it unbranched (?). That
> probably applies even more for tripleo-ci, where ability to make changes
> which affect how TripleO does CIing in general, across releases, is IMO a
> significant feature.
>
> Maybe branching quickstart-extras might require some code reshuffling
> between what belongs there and what belongs into quickstart itself.

I agree a lot with Jirka and I think branching oooq-extras would be a
good first start to see how it goes.
If we find it helpful and working correctly, we could go the next
steps and see if there is any other repo that could be branched
(tripleo-ci or oooq) but I guess for now the best candidate is
oooq-extras.

> (Just my 2 cents, i'm likely not among the most important stakeholders in
> this...)
>
> Jirka
>
>
>>
>> Thanks,
>> -Alex
>>
>> [0] https://review.openstack.org/#/c/478488/
>> [1] http://people.redhat.com/aschultz/denver-ptg/tripleo-ptg-retro.jpg
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

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

Re: [openstack-dev] [qa][infra][devstack] Changes to devstack-core for zuul v3 migration

2017-10-10 Thread Dean Troyer

On Tue, Oct 10, 2017 at 1:15 PM, Andrea Frittoli
 wrote:
> - we will treat +1 from infra-core members on devstack changes in the
> ansible bits as +2
> - add clarkb to devstack-core, since he's quite aware of the the devstack
> codebase

+2 on both of these proposals!

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

2017-10-10 Thread Sean McGinnis

> 
> To that end, I identified a series of small steps to get us there:
> 
> 1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova
> so they are identical (right now their help texts are slightly
> different). This step avoids triggering a DuplicateOptError exception
> in the next step.
> 
> 2) Add a ConfKeyManager implementation to Castellan. This essentially
> involves copying in one of the existing implementations (either Cinder's
> or Nova's).
> 
> 3) Replace Cinder's and Nova's implementations with references to the
> one in Castellan. This can be done in a way that retains compatibility
> with the key_manager "backend" (was "api_class") config options
> currently used by Cinder and Nova. The code in
> cinder/keymgr/conf_key_manager.py and nova/keymgr/conf_key_manager.py
> will collapse down to this:
> 
>   from castellan.key_manager import conf_key_manager
> 
>   class ConfKeyManager(conf_key_manager.ConfKeyManager):
>   pass
> 
> Having a common ConfKeyManager implementation will make it much
> easier to support migrating things to Barbican, and that's an important
> step toward the goal of deprecating the ConfKeyManager entirely.
> 
> Please let me know your thoughts, as I plan to begin proposing patches.
> 
> Regards,
> 
> Alan Bishop

Makes sense to me Alan. Thanks for looking into this.

__
OpenStack Development Mailing 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] [ptls] Sydney Forum Project Onboarding Rooms

Of course :) I added Designate.

-Kendall Nelson(diablo_rojo)


On Tue, Oct 10, 2017 at 1:01 PM Graham Hayes  wrote:

> Can I add designate? I will be there to look after the room.
>
> Thanks,
>
> Graham
>
>
> On Tue, 10 Oct 2017, at 20:20, Kendall Nelson wrote:
>
> Added :)
> -Kendall (diablo_rojo)
>
> On Tue, Oct 10, 2017 at 2:11 AM Spyros Trigazis 
> wrote:
>
> Magnum - Spyros Trigazis - 
>
> Thanks!
>
> On 9 October 2017 at 23:24, Kendall Nelson  wrote:
> > Wanted to keep this thread towards the top of inboxes for those I haven't
> > heard from yet.
> >
> > About a 1/4 of the way booked, so there are still slots available!
> >
> > -Kendall (diablo_rojo)
> >
> >
> > On Thu, Oct 5, 2017 at 8:50 AM Kendall Nelson 
> wrote:
> >>
> >> Hello :)
> >>
> >> We have a little over 40 slots available so we should be able to
> >> accommodate almost everyone, but it will be a first response first serve
> >> basis.
> >>
> >> Logistics: Slots are 40 min long and will have projection set up in
> them.
> >> The rooms have a capacity of about 40 people and will be set up
> classroom
> >> style.
> >>
> >> If you are interested in reserving a spot, just reply directly to me
> and I
> >> will put your project on the list. Please let me know if you want one
> and
> >> also include the names and emails anyone that will be speaking with you.
> >>
> >> When slots run out, they run out.
> >>
> >> Thanks!
> >>
> >> -Kendall Nelson (diablo_rojo)
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> *__*
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

On 10/10/2017 01:16 PM, Jesse Pretorius wrote:
> Regardless, given that this is not functionality currently> available for 
> setuptools, distutils or pbr it would seem
> that this functionality (or another applicable workaround)
> would have to be carried by Debian packaging until such
> time that such a facility exists in the python tooling.

We don't control setuptools/distutils directly. The only thing we
control is PBR. So my proposal is:

1/ Design a new config_files directive in setup.cfg and patch PBR so
that it understands it.

Considering the python module named foo, this could end up like this:

[files]
config_files_dest = PYBASE/foo
config_files = foo.cfg

then PYBASE would be expanded to /usr/lib/python2.7/dist-packages in the
case of Debian + Python 2.7.

or, as another example:

[files]
config_files_dest = foo
config_files = foo.cfg

then foo.cfg would end up in /usr/share/foo/foo.cfg unless the env var
OSLO_CONFIG_FILES_DEST is set (for example to /usr/share/foo-common, or
to /etc/foo). I don't really mind whatever is decided for the
non-packaging use case (ie: pip install ?).

2/ Make PBR to read the destination path from something configurable at
a packaging level, that would overwrite the default behavior, so that we
could have whatever the package maintainer decides.

3/ When the new PBR release has the new feature, let individual packages
use the new config_files directive that would simply list the config
files with the preselected destination.

Does this seem a good plan? Please comment on the above.

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing 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] [ptls] Sydney Forum Project Onboarding Rooms

Can I add designate? I will be there to look after the room.

Thanks,

Graham


On Tue, 10 Oct 2017, at 20:20, Kendall Nelson wrote:
> Added :) 
> -Kendall (diablo_rojo)
> 
> On Tue, Oct 10, 2017 at 2:11 AM Spyros Trigazis
>  wrote:>> Magnum - Spyros Trigazis - 
>> 
>>  Thanks!
>> 
>>  On 9 October 2017 at 23:24, Kendall Nelson 
>>  wrote:>>  > Wanted to keep this thread towards the top of inboxes for those 
>> I
>>  > haven't>>  > heard from yet.
>>  >
>>  > About a 1/4 of the way booked, so there are still slots available!>>  >
>>  > -Kendall (diablo_rojo)
>>  >
>>  >
>>  > On Thu, Oct 5, 2017 at 8:50 AM Kendall Nelson
>>  >  wrote:>>  >>
>>  >> Hello :)
>>  >>
>>  >> We have a little over 40 slots available so we should be able to>>  >> 
>> accommodate almost everyone, but it will be a first response
>>  >> first serve>>  >> basis.
>>  >>
>>  >> Logistics: Slots are 40 min long and will have projection set up
>>  >> in them.>>  >> The rooms have a capacity of about 40 people and will be 
>> set up
>>  >> classroom>>  >> style.
>>  >>
>>  >> If you are interested in reserving a spot, just reply directly to
>>  >> me and I>>  >> will put your project on the list. Please let me know if 
>> you want
>>  >> one and>>  >> also include the names and emails anyone that will be 
>> speaking
>>  >> with you.>>  >>
>>  >> When slots run out, they run out.
>>  >>
>>  >> Thanks!
>>  >>
>>  >> -Kendall Nelson (diablo_rojo)
>>  >
>>  >
>>  > _-
>>  > _>>  > OpenStack Development Mailing List (not for usage 
>> questions)
>>  > Unsubscribe: OpenStack-dev-
>>  > requ...@lists.openstack.org?subject:unsubscribe>>  > 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>  >
>> 
>>  ___-
>>  ___>>  OpenStack Development Mailing List (not for usage questions)
>>  Unsubscribe: OpenStack-dev-
>>  requ...@lists.openstack.org?subject:unsubscribe>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> -
> > OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

Excerpts from Thomas Goirand's message of 2017-10-10 21:28:35 +0200:
> On 10/10/2017 01:21 PM, Jesse Pretorius wrote:
> > 
> > 
> > On 10/10/17, 12:08 PM, "Jesse Pretorius"  
> > wrote:
> > 
> >>$ python setup.py install --skip-build --root /tmp/keystone 
> >> --install-data /
> > 
> > Apologies – I copied the wrong command, it should have been:
> > 
> > $ python setup.py install --root /tmp/keystone --install-data /
> 
> Isn't it that "--install-data" carries a different meaning than config
> files? To me, its semantic was data files, not config files. Which leads
> me to the idea that "data_files" in setup.cfg is probably the wrong way
> to describe config files. Typically, in distros, we'd have data files
> (for example, timezone data, pictures, docs, etc.) in /usr/share, while
> config files lives in /etc. Aren't we here mixing 2 concepts?
> 
> For example, if we take openstack-doc-tools's setup.cfg, it has under
> data_files:
> 
> data_files =
> share/openstack-doc-tools/sitemap = sitemap/*
> share/openstack-doc-tools/cleanup = cleanup/*
> 
> Typically, for openstackdocstheme, I'd prefer these files to end up under:
> 
> /usr/lib/python2.7/dist-packages/openstackdocstheme
> 
> (sed s/2.7/3/ if using Python 3)
> 
> With your method, wouldn't these files end up in the wrong location, ie
> outside of /usr? What if openstackdocstheme has both config files and
> "real" data files?
> 
> Probably, we need a method to handle both cases: config files and data
> files. In fact, don't think PBR's data_files is designed for handling
> config files at all. Which is the very reason why I think it's broken to
> use it the proposed way.

It seems to me that *sample* configuration files should be treated
as data files and not configuration files. A package might include
several sample configuration files, but only one of those should be
used (if any are).

Doug

> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

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

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

On 10/09/2017 12:36 PM, Jesse Pretorius wrote:
> There has been an objection from the OpenStack package maintainer for
> Debian, but that objection has been to the use of the relative path of
> /etc. Thomas Goirand, could you please indicate whether you support the
> use of the relative path of /share given the currently available
> functionality in setuptools and pbr?

See my other post, which is IMO the most important and that we may have
missed in this thread: I don't think data_files is there to handle
configuration files, but *only* data_file. Probably Monty will be able
to confirm that fact. If one day, we want to mix data files (ie, things
to push in /usr/share, typically) and config files, then everything will
fall apart.

So, maybe we should design a config_files statement in setup.cfg?

>> 2) Looking at the Ubuntu packaging for OpenStack projects, we have
> quite a few places where oslo-config-generator or oslo-policy-generator
> is used to generate sample configuration files as part of the package
> build;

Historically, I believe it's there because I started to do so in Debian,
and then Ubuntu people picked-up what I did for a few project, then
thought it wasn't a bad idea.

Also, there's an important bit too: we're patching keystonemiddleware so
that it includes the old type of keystone auth variables when generating
the config files. Here's the patch:

https://anonscm.debian.org/cgit/openstack/libs/python-keystonemiddleware.git/tree/debian/patches/re-add-missing-auth-options.patch

FYI, this is very important for Debian's CI, as it's still using the old
type of keystone auth and expecting correct configuration files. Even if
it was using the new type (ie: keystone v3), then something would need
to be patched in keystonemiddleware to generate that (as currently,
keystonemiddleware entry point produces ... no auth directive at all!).
BTW, the use of default config files in the CI is very intentional on my
side, as I do want to test them. Over the years, I realized Debian was
the *only* distro in the world that was gating on that. I did notice it
when I understood nobody else was reporting bugs about them. Other
distros are probably using config management scripts, I guess.

So anyway, the point was: we'd better regenerate all service's config
file by ourselves to make sure it's really taking into account our
patch. I also prefer to have config files wrapped with 140 columns
rather than the default 80. That's only my opinionated preference, and
just an example of why we may prefer to do things by ourselves.

> I might have missed it in my read through of this thread but it
> would be awesome if those could be integrated as part of this process as
> well as the originating project would then be able to provide some level
> for assurance to the content of generated files in downstream distributions.

Well, if OpenStack as an upstream was doing everything correctly, it'd
be a huge win. Though really, the correct way to do things is to give
package maintainers the freedom to do what they want. In this case,
giving a way to tell "please drop my config files THERE --->", so that
we can write nice automations is the correct thing to do.

> As mentioned in [4] these should be auto-generated. Some projects do
> this and submit samples into the repo from time to time, others have
> just left a stub with an explanation of how to generate it.

The correct thing to do is to *not* ship potentially wrong samples.
Indeed, the config files depend on the version of the underlying libs,
which can potentially change without prior notice. But let's not rehash
this again, it has been written *many* times over *multiple* years. :)

>> I'd also be +1 on a packaging SIG;

I might have missed it, but what is SIG?!?

> This
> e-mail message may contain confidential or privileged information
> intended for the recipient. Any dissemination, distribution or copying
> of the enclosed material is prohibited. If you receive this transmission
> in error, please notify us immediately by e-mail at ab...@rackspace.com
> and delete the original message. Your cooperation is appreciated.

Hum... Should I mention that this message footer is inappropriate for a
*public* mailing list? Will I be persecuted for quoting you? :)

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing 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] Flagging deprecated releases

Excerpts from Jimmy McArthur's message of 2017-10-10 14:15:52 -0500:
> Hi all -
> 
> I'm following up on the PTG action item to add a CSS banner for older 
> releases (e.g. https://releases.openstack.org/newton/index.html).  Does 
> anyone have specific language they'd like to see here or should I just 
> riff it?
> 
> I was considering a CSS overlay similar to what you see when you scroll 
> down below the nav (e.g. https://www.openstack.org/software/security/).  
> Here's a quick comp: https://www.screencast.com/t/Kbz0Sh8uRb7
> 
> If you like the direction this is going, I'll send along to people that 
> are real designers (not me).
> 
> Cheers,
> Jimmy
> 


When I was updating the landing pages and adding the old release series,
I identified 5 different statuses: obsolete, EOL, maintained, current, and
development. Those are encoded in the SERIES_INFO data in the template
generator
(http://git.openstack.org/cgit/openstack/openstack-manuals/tree/tools/www-generator.py#n43).

Austin is an example of an obsolete series, and there's some text on
that landing page about "no longer supported by the community".
https://docs.openstack.org/austin/

It looks like I used the same text for Icehouse, which is an EOL
release. https://docs.openstack.org/icehouse/

The text for Ocata just says "this is not the latest release":
https://docs.openstack.org/ocata/

The text for Pike, the "current" release, says "this is the latest
release": https://docs.openstack.org/pike/

And Queens says "this release is currently under development":
https://docs.openstack.org/queens/

I don't care especially much about the text, and we can make the badges
and landing pages match once we decide what we want, but I think we need
the 4 distinct statuses (where obsolete and EOL are the same).

On a technical note from someone who has poor web-fu, will we be
able to inject text into the overlay for old docs without rebuilding
them? For example, we can update the pike docs now but when that
branch goes EOL we want the text to update to say that without us
having to rebuild the pike docs. Ideally we would be able to just update
the SERIES_INFO settings and the next time a pike page is loaded the
correct badge will appear.

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] [keystone][nova] Persistent application credentials

2017-10-10 Thread Fox, Kevin M

Big +1 for reevaluating the bigger picture. We have a pile of api's that 
together don't always form the most useful of api's due to lack of big picture 
analysis.

+1 to thinking through the dev's/devops use case.

Another one to really think over is single user that != application developer. 
IE, Pure user type person deploying cloud app in their tenant written by dev 
not employees by user's company. User shouldn't have to go to Operator to 
provision service accounts and other things. App dev should be able to give 
everything needed to let OpenStack launch say a heat template that provisions 
the service accounts for the User, not making the user twiddle the api 
themselves. It should be a "here, launch this" kind of thing, and they fill out 
the heat form, and out pops a working app. If they have to go prevision a bunch 
of stuff themselves before passing stuff to the form, game over. Likewise, if 
they have to look at yaml, game over. How do app credentials fit into this?

Thanks,
Kevin

From: Zane Bitter [zbit...@redhat.com]
Sent: Monday, October 09, 2017 9:39 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 12/09/17 18:58, Colleen Murphy wrote:
> While it's fresh in our minds, I wanted to write up a short recap of
> where we landed in the Application Credentials discussion in the BM/VM
> room today. For convenience the (as of yet unrevised) spec is here:

Thanks so much for staying on this Colleen, it's tremendously helpful to
have someone from the core team keeping an eye on it :)

> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/application-credentials.html
>
> Attached are images of the whiteboarded notes.
>
> On the contentious question of the lifecycle of an application
> credential, we re-landed in the same place we found ourselves in when
> the spec originally landed, which is that the credential becomes invalid
> when its creating user is disabled or deleted. The risk involved in
> allowing a credential to continue to be valid after its creating user
> has been disabled is not really surmountable, and we are basically
> giving up on this feature. The benefits we still get from not having to
> embed user passwords in config files, especially for LDAP or federated
> users, is still a vast improvement over the situation today, as is the
> ability to rotate credentials.

OK, there were lots of smart people in the room so I trust that y'all
made the right decision.

I'd just like to step back for a moment though and ask: how exactly do
we expect users to make use of Keystone?

When I think about a typical OpenStack user of the near future, they
looks something like this: there's a team with a handful of developers,
with maybe one or two devops engineers. This team is responsible for a
bunch of applications, at various stages in their lifecycles. They work
in a department with several such teams, in an organisation with several
such departments. People regularly join or leave the team - whether
because they join or leave the organisation or just transfer between
different teams. The applications are deployed with Heat and are at
least partly self-managing (e.g. they use auto-scaling, or auto-healing,
or have automated backups, or all of the above), but also require
occasional manual intervention (beyond just a Heat stack-update). The
applications may be deployed to a private OpenStack cloud, a public
OpenStack cloud, or both, with minimal differences in how they work when
moving back and forth.

(Obviously the beauty of Open Source is that we don't think about only
one set of users. But I think if we can serve this set of users as a
baseline then we have built something pretty generically useful.)

So my question is: how do we recommend these users use Keystone? We
definitely _can_ support them. But the most workable way I can think of
would be to create a long-lived application user account for each
project in LDAP/ActiveDirectory/whatever and have that account manage
the application. Then things will work basically the same way in the
public cloud, where you also get a user per project. Hopefully some
auditability is maintained by having Jenkins/Zuul/Solum/whatever do the
pushing of changes to Heat, although realistically many users will not
be that sophisticated. Once we have application credentials, the folks
doing manual intervention would be able to do so in the same way on
public clouds as on private clouds, without being given the account
credentials.

Some observations about this scenario:
* The whole user/role infrastructure is completely unused - 'Users' are
1:1 with projects. We might as well not have built it.
* Having Keystone backed by LDAP/ActiveDirectory is arguably worse than
useless - it just means there are two different places to set things up
when creating a project and an extra layer of indirection. (I won't say
we might as well

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

On 10/10/2017 01:21 PM, Jesse Pretorius wrote:
> 
> 
> On 10/10/17, 12:08 PM, "Jesse Pretorius"  
> wrote:
> 
>>$ python setup.py install --skip-build --root /tmp/keystone 
>> --install-data /
> 
> Apologies – I copied the wrong command, it should have been:
> 
> $ python setup.py install --root /tmp/keystone --install-data /

Isn't it that "--install-data" carries a different meaning than config
files? To me, its semantic was data files, not config files. Which leads
me to the idea that "data_files" in setup.cfg is probably the wrong way
to describe config files. Typically, in distros, we'd have data files
(for example, timezone data, pictures, docs, etc.) in /usr/share, while
config files lives in /etc. Aren't we here mixing 2 concepts?

For example, if we take openstack-doc-tools's setup.cfg, it has under
data_files:

data_files =
share/openstack-doc-tools/sitemap = sitemap/*
share/openstack-doc-tools/cleanup = cleanup/*

Typically, for openstackdocstheme, I'd prefer these files to end up under:

/usr/lib/python2.7/dist-packages/openstackdocstheme

(sed s/2.7/3/ if using Python 3)

With your method, wouldn't these files end up in the wrong location, ie
outside of /usr? What if openstackdocstheme has both config files and
"real" data files?

Probably, we need a method to handle both cases: config files and data
files. In fact, don't think PBR's data_files is designed for handling
config files at all. Which is the very reason why I think it's broken to
use it the proposed way.

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing 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] [ptls] Sydney Forum Project Onboarding Rooms

Added :)

-Kendall (diablo_rojo)

On Tue, Oct 10, 2017 at 2:11 AM Spyros Trigazis  wrote:

> Magnum - Spyros Trigazis - 
>
> Thanks!
>
> On 9 October 2017 at 23:24, Kendall Nelson  wrote:
> > Wanted to keep this thread towards the top of inboxes for those I haven't
> > heard from yet.
> >
> > About a 1/4 of the way booked, so there are still slots available!
> >
> > -Kendall (diablo_rojo)
> >
> >
> > On Thu, Oct 5, 2017 at 8:50 AM Kendall Nelson 
> wrote:
> >>
> >> Hello :)
> >>
> >> We have a little over 40 slots available so we should be able to
> >> accommodate almost everyone, but it will be a first response first serve
> >> basis.
> >>
> >> Logistics: Slots are 40 min long and will have projection set up in
> them.
> >> The rooms have a capacity of about 40 people and will be set up
> classroom
> >> style.
> >>
> >> If you are interested in reserving a spot, just reply directly to me
> and I
> >> will put your project on the list. Please let me know if you want one
> and
> >> also include the names and emails anyone that will be speaking with you.
> >>
> >> When slots run out, they run out.
> >>
> >> Thanks!
> >>
> >> -Kendall Nelson (diablo_rojo)
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [docs] Flagging deprecated releases

2017-10-10 Thread Jimmy McArthur


Hi all -

I'm following up on the PTG action item to add a CSS banner for older 
releases (e.g. https://releases.openstack.org/newton/index.html).  Does 
anyone have specific language they'd like to see here or should I just 
riff it?


I was considering a CSS overlay similar to what you see when you scroll 
down below the nav (e.g. https://www.openstack.org/software/security/).  
Here's a quick comp: https://www.screencast.com/t/Kbz0Sh8uRb7


If you like the direction this is going, I'll send along to people that 
are real designers (not me).


Cheers,
Jimmy

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

Re: [openstack-dev] [keystone][nova] Persistent application credentials

2017-10-10 Thread Colleen Murphy

On Mon, Oct 9, 2017 at 6:39 PM, Zane Bitter  wrote:

> On 12/09/17 18:58, Colleen Murphy wrote:
>
>> While it's fresh in our minds, I wanted to write up a short recap of
>> where we landed in the Application Credentials discussion in the BM/VM room
>> today. For convenience the (as of yet unrevised) spec is here:
>>
>
> Thanks so much for staying on this Colleen, it's tremendously helpful to
> have someone from the core team keeping an eye on it :)

No problem :)

>
>
> http://specs.openstack.org/openstack/keystone-specs/specs/ke
>> ystone/backlog/application-credentials.html
>>
>> Attached are images of the whiteboarded notes.
>>
>> On the contentious question of the lifecycle of an application
>> credential, we re-landed in the same place we found ourselves in when the
>> spec originally landed, which is that the credential becomes invalid when
>> its creating user is disabled or deleted. The risk involved in allowing a
>> credential to continue to be valid after its creating user has been
>> disabled is not really surmountable, and we are basically giving up on this
>> feature. The benefits we still get from not having to embed user passwords
>> in config files, especially for LDAP or federated users, is still a vast
>> improvement over the situation today, as is the ability to rotate
>> credentials.
>>
>
> OK, there were lots of smart people in the room so I trust that y'all made
> the right decision.
>
> I'd just like to step back for a moment though and ask: how exactly do we
> expect users to make use of Keystone?
>
> When I think about a typical OpenStack user of the near future, they looks
> something like this: there's a team with a handful of developers, with
> maybe one or two devops engineers. This team is responsible for a bunch of
> applications, at various stages in their lifecycles. They work in a
> department with several such teams, in an organisation with several such
> departments. People regularly join or leave the team - whether because they
> join or leave the organisation or just transfer between different teams.
> The applications are deployed with Heat and are at least partly
> self-managing (e.g. they use auto-scaling, or auto-healing, or have
> automated backups, or all of the above), but also require occasional manual
> intervention (beyond just a Heat stack-update). The applications may be
> deployed to a private OpenStack cloud, a public OpenStack cloud, or both,
> with minimal differences in how they work when moving back and forth.
>
> (Obviously the beauty of Open Source is that we don't think about only one
> set of users. But I think if we can serve this set of users as a baseline
> then we have built something pretty generically useful.)
>
> So my question is: how do we recommend these users use Keystone? We
> definitely _can_ support them. But the most workable way I can think of
> would be to create a long-lived application user account for each project
> in LDAP/ActiveDirectory/whatever and have that account manage the
> application. Then things will work basically the same way in the public
> cloud, where you also get a user per project. Hopefully some auditability
> is maintained by having Jenkins/Zuul/Solum/whatever do the pushing of
> changes to Heat, although realistically many users will not be that
> sophisticated. Once we have application credentials, the folks doing manual
> intervention would be able to do so in the same way on public clouds as on
> private clouds, without being given the account credentials.
>
> Some observations about this scenario:
> * The whole user/role infrastructure is completely unused - 'Users' are
> 1:1 with projects. We might as well not have built it.
> * Having Keystone backed by LDAP/ActiveDirectory is arguably worse than
> useless - it just means there are two different places to set things up
> when creating a project and an extra layer of indirection. (I won't say we
> might as well not have built it, because many organisations have compliance
> rules that, ahem, well let's just say they were developed in a different
> context :)
> * We're missing an essential feature of cloud (or even of VPSs): you
> shouldn't need to raise a ticket with IT to be able to deploy a new
> application. Any involvement from them should be asynchronous (e.g. setting
> quotas - although even that is an OpenStack-specific thing: in public
> clouds excessive use is discouraged by _billing_ and in non-OpenStack
> clouds users set their _own_ quotas); we don't want humans in the loop.
> * AFAIK it's not documented anywhere that this is the way we expect you to
> use OpenStack. Anybody would think it's all about the Users and Roles.
>
Another observation - if all the members of the team know the application
user's username and password (which they must, in order to use it to create
application credentials), then the team members who leave the team would
continue to have access to everything the application user has access to,
and

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

On 10/09/2017 11:20 AM, Luigi Toscano wrote:
> On Saturday, 7 October 2017 12:30:54 CEST Thomas Goirand wrote:
>> Though people doing the packaging will suffer. Please don't throw the
>> baby over the wall, and let's fix the issue.
> 
> This is an overstatement.

Pardon me if I'm wrong, but if you think that's an overstatement, then
you are admitting at least partly that I'm right, no? :)

I'm here, like everyone, only trying to find a solution that works for
everyone. I don't think pushing config files in the correct location is
*THAT* hard, is it?

With PBR, we had a *very* long standing issue with the module version of
projects, until Monty had the brilliant idea to propose a patch to read
from the environment variable OSLO_PACKAGE_VERSION. Once this was done,
I hard-wired this env var reading debian/changelog (using
dpkg-parsechangelog and a bit of sed magic). These days, it's just
included in openstack-pkg-tools's pkgos.make, which everyone (in both
Debian and Ubuntu) is using, and we don't even have to think about it.
I'd love if we could have a similar answer: something fully automated
that works for everyone.

> For example, sahara have been installing those files for a long time under 
> data_files, When the patch changed the location from /usr, I just changed the 
> way those files are copied:
> https://review.rdoproject.org/r/#/c/9722/
> (this does not happen for Ubuntu and Debian packaging right now, so there are 
> duplicated files).

The very point is: it is happening for all distros, meaning at least 4
workaround have to be wrriten, which is silly.

> This means that:
> 1) if the files are not installed through data_files, you have to manually 
> copy them using the packaging script ;
> 2) if the files are installed using data_files, you either move them in the 
> right position or delete that copy and still copy the proper files in the 
> right place

So 2) is more work, you'd need to rm -rf /usr/etc. Instead, we could
have absolutely everything completely automated, once and for all in all
distros, with files copied in the right place. In Debian, I'd write
something that would parse debian/control, and look if the foo-common
package exist, and then do the right thing (tm) so config files are
pushed to the correct location. But instead, right now, we have to deal
with the issue. Repeat this 3 dozen times, multiply by 4 distros, and
consider how much time loss we're facing, just because config files are
dropped in /usr/etc.

I'm still convince we can do better, toward perfect automation, and that
the problem isn't that hard to solve!

>> Let's get there then. In the mean while, don't break stuff.
> 
> Nothing is broken, see above.

You'll have a hard time convincing me that config files written in
/usr/etc is not a broken feature. :)

Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

On 10/09/2017 08:44 AM, Jean-Philippe Evrard wrote:
> If you want to include the fix for PBR, or refresh it, don't hesitate
> to propose a follow-up patch.

That's the issue. I would very much like to propose a follow-up patch,
but Robert has disagreed on its very principle, so I don't see a route
to have a validated patch. That is, unless some key core contributors to
PBR agree with me first.

Also, I don't think it is a good idea to carry a Debian specific patch,
and I would very much prefer gathering a consensus. Such consensus could
be along the lines of: we've failed to have this issue tackled in a
timely manner at the setuptools level, therefore it is time to act and
adopt the pragmatic solution.

> In any case, I don't think it's a good idea to wait for things to
> happen, and expect that uniformity will happen naturally. This is a
> step in the right direction.
> 
> On top of that we are still early in the Queens cycle, so it leaves a
> chance to the packagers to react. I think it's good timing.

I very much agree that it is more than time to have this problem solved.
Let's be constructive and fix the situation! Starting this thread was
definitively a very good idea, especially considering different people
have different opinions.

Cheers,

Thomas Goirand (zigo)

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

[openstack-dev] [qa][infra][devstack] Changes to devstack-core for zuul v3 migration

2017-10-10 Thread Andrea Frittoli

Dear all,

with zuul v3, the common roles and playbooks that will be used for all
devstack jobs will be hosted in openstack-dev/devstack.
To speed up the implementation and stabilisation of the code I propose the
following changes:

- we will treat +1 from infra-core members on devstack changes in the
ansible bits as +2
- add clarkb to devstack-core, since he's quite aware of the the devstack
codebase

Please let me know if you have any objection, else the change we'll become
effective tomorrow.

Kind regards

Andrea Frittoli (andreaf)
__
OpenStack Development Mailing 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] [openstack-infra] [nova] build log REST access

2017-10-10 Thread Clark Boylan

On Tue, Oct 10, 2017, at 06:46 AM, Klérisson Paixão wrote:
> Hi everyone!
> 
> I'm looking for documentation on how to access the REST API of openstack
> logstash/elasticsearch to retrieve builds logs.
> Could you, please, point me out how to start?

The docs that describe how we use logstash and elasticsearch can be
found at https://docs.openstack.org/infra/system-config/logstash.html.
Some of that info is currently in flux as we work towards deploying
zuulv3 but I think at a high level it is largely correct.

As noted there the elasticsearch API can be hit at
http://logstash.openstack.org/elasticsearch. This exposes a read only
subset of the proper elasticsearch 1.7 API which is documented at
https://www.elastic.co/guide/en/elasticsearch/reference/1.7/index.html.
If you find there are queries you'd like to make not currently allowed
by our proxy let us know and we can see if it is possible to open that
up safely.

Finally keep in mind that we only index INFO and greater log lines and
we only keep 10 days worth of indexed logs. Logstash/elasticsearch
should be used for targeted look ups of specific log entries rather than
aggregate log viewing due to the sheer volume of the data. If you are
looking for an index into complete logs the openstack health dashboard
at http://status.openstack.org/openstack-health/ might be a better place
to start.

Hope this helps,
Clark

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

[openstack-dev] [TC][election] TC Candidacy

2017-10-10 Thread Andrea Frittoli

Dear all,

I’d like to announce my candidacy for a seat on the OpenStack Technical
Committee.

I started my journey on OpenStack in 2011 as a user and operator. I had
little experience contributing to open source at the time; the people and
the values in the OpenStack community soon convinced me I could not simply
sit on the "consumer" side of the fence, and I started contributing to
the QA program. I've been a core contributor for Tempest since 2014 and the
PTL for the QA Program since the Pike cycle.

I attended the 2nd Leadership Training in Ann Arbour; the ideas of servant
leadership and vision inspired me and I put them into use while serving as
a PTL and working with the community in general.

I'm a supporter of the OpenStack vision prepared by the TC and by this
community. Diversity and collaboration with other communities enrich us,
"constellations" give a clearer message to users and operators, and help
us focus our development and testing efforts in a consistent direction.

On the TC I would focus on a few ares:

- Inclusivity of the OpenStack community: reduce language and time
barriers for contribution. Everyone should feel welcome and have the
opportunity to be successful when working on OpenStack.

- Build our new leaders: it's not enough to welcome new contributors,
we need to help them grow into the community future leaders.

- Cross-project and cross-community testing: help companies bring their
downstream architecture, integration and testing efforts in upstream
so they can benefit from the contributions of others in the community
that want to solve similar problems via OpenStack.

Regardless of the results of this election I will work hard to see the
vision we set for ourselves realised.

Thank you for your consideration.

Andrea Frittoli (andreaf)

https://www.openstack.org/community/members/profile/1211/andrea-frittoli
https://review.openstack.org/#/c/510961/
__
OpenStack Development Mailing 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] CentOS upgrade killed my Liberty system

2017-10-10 Thread melanie witt


On Tue, 10 Oct 2017 09:59:03 -0700, Christopher Hull wrote:

Browser hangs for a while then shows "Internal Server Error"

/var/log/httpd/error shows this...

[Tue Oct 10 09:32:53.860393 2017] [core:error] [pid 27391] [client 
172.22.10.130:53239 ] End of script output 
before headers: django.wsgi


Hope this looks familiar to someone.


It sounded familiar to me and I found these bugs [1][2] which might be 
what you're seeing. The latest comments say "WSGIApplicationGroup 
%{GLOBAL}" needs to be added to openstack-dashboard.conf and httpd 
restarted.


Hope that helps.

-melanie

[1] https://bugs.launchpad.net/horizon/+bug/1573488
[2] https://bugs.launchpad.net/horizon/+bug/1708655


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

Re: [Openstack-operators] CentOS upgrade killed my Liberty system

2017-10-10 Thread Christopher Hull

Hello Yaguang;

Thanks very much for the assist.   Curiously, no errors in horizon.  But an
error upstream in httpd...

Browser hangs for a while then shows "Internal Server Error"

/var/log/httpd/error shows this...

[Tue Oct 10 09:32:53.860393 2017] [core:error] [pid 27391] [client
172.22.10.130:53239] End of script output before headers: django.wsgi

Hope this looks familiar to someone.

Thanks all;

-Chris




- Christopher T. Hull
My contract at NASA has ended and I am seeking new opportunities.
For updated resume and other info, please click this link.
http://faq.chrishull.com
Sunnyvale CA. 94085
(415) 385 4865
chrishul...@gmail.com
http://chrishull.com



On Tue, Oct 10, 2017 at 5:47 AM, Yaguang Tang  wrote:

> Can you paste out the horizon related error logs, may be caused by horizon
> dependency issue.
>
> On Tue, Oct 10, 2017 at 2:12 AM, Christopher Hull 
> wrote:
>
>> Hi all;
>>
>> About 18 months ago I did a piece by piece install of Liberty (following
>> instructions on the Openstack page) and had been using it until somewhat
>> recently when it broke after a CentOS 7 update ran.  I think Python/http is
>> what changed / broke (sessionless connections no longer supported?).
>> Basics like nova list still work, but Horizon won't run.
>>
>> How can I "downgrade" my CentOS box?
>> Or alternatively, how painful is it to update to the most current
>> Openstack?
>>
>> Also, I noticed that the CeotOS cloud SIG repo moved.
>>
>> Please help.  :-)
>>
>> BTW, for installs I wrote a tool to help with setting up the many
>> Openstack config files.   If interested, you can find it here.
>> http://chrishull.com/career/openstack/index.html
>> https://github.com/chrishull/github-openstack
>>
>> Several months ago I tried to check this into the Openstack Operators GIT
>> repo, but had difficulty.
>>
>> Anyway.  Please advise on how I can fix my Liberty system if you can.
>>
>> Thanks;
>> -Chris
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> - Christopher T. Hull
>> My contract at NASA has ended and I am seeking new opportunities.
>> For updated resume and other info, please click this link.
>> http://faq.chrishull.com
>> Sunnyvale CA. 94085
>> (415) 385 4865 <(415)%20385-4865>
>> chrishul...@gmail.com
>> http://chrishull.com
>>
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
>
> --
> Tang Yaguang
>
>
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Designate DNS service on Mitaka

We did not have a dedicated guide for Mitaka, but the Liberty guide
should install mitaka with no issues.

https://docs.openstack.org/designate/mitaka/install/ubuntu-liberty.html

Thanks,

Graham


On 09/10/17 15:52, Alexandra Kisin wrote:
> Hello.
> Is there any installation / configuration guide for Designate service in
> Mitaka release (Ubuntu 14.04) ?
> And also I didn't find any detailed instructions for designate upgrade
> from Liberty to Mitaka.
> 
> Thank you.
> 
> 
> Regards,
> 
> Alexandra Kisin
> Servers & Network group, IBM R Labs in Israel
> Unix & Virtualization Team
> 
> *Phone:* +972-48296172 | *Mobile:* +972-54-6976172 | *Fax:* +972-4-8296111
>   
> IBM
> 
> 
> 
> 
> 
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 



signature.asc
Description: OpenPGP digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [tc][election] TC Candidacy

I would like to submit my candidacy for the Technical Committee for the
upcoming election.

I have been contributing to OpenStack since the Havana cycle [1], mainly in
Designate. I have also sporadically gotten involved with the TC, and its
meetings since Designate applied for incubation all the way back in Atlanta.

I have been PTL for Designate for Mitaka, Newton, Ocata and the Queens
cycle,
and a core for a longer period. I was also PTL for the Global Load Balancing
before it was an unfortunate early casualty of the recent reshuffling within
sponsoring organizations in the community.

As part of previous projects, I was both a developer and a heavy user of
OpenStack. As part of contributing to the Kubernetes OpenStack integration
we ran into a lot of the problems that impact our users, and people who
try to integrate with us.

I believe that we all ready have a great base structure in place to help
OpenStack evolve, and part of that is too have a group of people from
different
companies, backgrounds, genders and cultures to drive the project in the
Technical Committee.

I believe my experience working in a younger, smaller project within
OpenStack is a benefit, along with the experience of working on software
as an
end user of OpenStack I can help us ensure the Technical Committee is
mindful
of the unique challenges these projects and users can face.

I have not traditionally been shy about broaching these topics in the
past [2]
[3][4], but I feel it is time I started follow through, and help guide the
resolution for these questions, and I now have an employeer who is
supportive
of me spending more time in the community.

I do really like this community, and I want us to grow, expand and
evolve the
software we write, without changing what we stand for.

Thank you for taking the time to read this,
Graham Hayes (mugsie)

1 - http://stackalytics.com/?release=all=commits_id=grahamhayes
2 - http://lists.openstack.org/pipermail/openstack-dev/2016-July/099285.html
3 - http://graham.hayes.ie/posts/openstack-designate-where-we-are/
4 - https://review.openstack.org/#/c/312267/ (and related discussion)


0x23BA8E2E.asc
Description: application/pgp-keys


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

[openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

2017-10-10 Thread Alan Bishop

There is an ongoing effort to deprecate the ConfKeyManager, but care
must be taken when migrating existing ConfKeyManager deployments to
Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican,
but the process of switching from one key manager to another will need
to be done smoothly to ensure encrypted volumes continue to function
during the migration period.

One thing that will help the migration process is consolidating the
two ConfKeyManager implementations (one in Cinder and one in Nova).
The two are functionally identical, as dictated by the need to derive
the exact same secret from the fixed_key. While it may seem counter-
intuitive, adding a ConfKeyManager implementation to Castellan will
facilitate the process of deprecating them in Cinder and Nova.

To that end, I identified a series of small steps to get us there:

1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova
so they are identical (right now their help texts are slightly
different). This step avoids triggering a DuplicateOptError exception
in the next step.

2) Add a ConfKeyManager implementation to Castellan. This essentially
involves copying in one of the existing implementations (either Cinder's
or Nova's).

3) Replace Cinder's and Nova's implementations with references to the
one in Castellan. This can be done in a way that retains compatibility
with the key_manager "backend" (was "api_class") config options
currently used by Cinder and Nova. The code in
cinder/keymgr/conf_key_manager.py and nova/keymgr/conf_key_manager.py
will collapse down to this:

  from castellan.key_manager import conf_key_manager

  class ConfKeyManager(conf_key_manager.ConfKeyManager):
  pass

Having a common ConfKeyManager implementation will make it much
easier to support migrating things to Barbican, and that's an important
step toward the goal of deprecating the ConfKeyManager entirely.

Please let me know your thoughts, as I plan to begin proposing patches.

Regards,

Alan Bishop
__
OpenStack Development Mailing 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] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

2017-10-10 Thread Alex Schultz

On Tue, Oct 10, 2017 at 5:24 AM, Flavio Percoco  wrote:
> On 09/10/17 12:41 -0700, Emilien Macchi wrote:
>>
>> On Mon, Oct 9, 2017 at 2:29 AM, Flavio Percoco  wrote:
>> [...]
>>>
>>> 1. A repo per role: Each role would have its own repo - this is the way
>>> I've
>>> been developing it on Github. This model is closer to the ansible way of
>>> doing
>>> things and it'll make it easier to bundle, ship, and collaborate on,
>>> individual
>>> roles. Going this way would produce something similar to what the
>>> openstack-ansible folks have.
>>
>>
>> +1 on #1 for the composability.
>>
>> [...]
>>
>> Have we considered renaming it to something without tripleo in the name?
>> Or is it too specific to TripleO that we want it in the name?
>
>
> The roles don't have tripleo in their names. The only role that mentions
> tripleo
> is tripleo specific. As for the APB, yeah, I had thought about renaming that
> repo to something without tripleo in there: Perhaps just `ansible-k8s-apbs`.
>
> I'm about to refactor this repo to remove all the code duplication. We
> should be
> able to generate most of the APB code that's in there from a python script.
> We
> could even have this script in tripleo_common, if it sounds sensible.
>

It should be it's own thing and not in tripleo_common.  When I was
proposing a cookiecutter repo it was because in Puppet we do the same
thing to bootstrap the modules[0].  It would be a good idea to
establish this upfront with the appropriate repo & zuul v3
configurations that could be used to test these modules. We have a
similar getting started with a new module doc[1] that we should
probably establish for these ansible-k8s-* roles.

Thanks,
-Alex

[0] https://github.com/openstack/puppet-openstack-cookiecutter
[1] 
https://docs.openstack.org/puppet-openstack-guide/latest/contributor/new-module.html

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

__
OpenStack Development Mailing 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] [openstack-dev] Sydney Forum Topic Submission

2017-10-10 Thread Mike Perez

On 16:15 Sep 21, Shamail Tahir wrote:
> Hi,
> 
> We have made it to the next stage of the topic selection process for the
> Forum in Sydney!
> 
> At the Forum the entire OpenStack community (users and developers) gathers
> to brainstorm the requirements for the next release, gather feedback on the
> past version and have strategic discussions that go beyond just one release
> cycle. The Sydney Forum is the start of the Rocky release cycle. Please
> prepare session ideas with feedback from the Pike release in mind.
> 
> Our submission tool is now open for you to submit abstracts for the most
> popular sessions that came out of your brainstorming.
> 
> Ask all session leaders to submit their abstracts at:
> http://forumtopics.openstack.org/
> 
> before *11:59PM UTC on Friday September 29th*!
> 
> We are looking for a good mix of project-specific, cross-project or
> strategic/whole-of-community discussions, and sessions that emphasize
> collaboration between users and developers are most welcome!
> 
> We assume that anything submitted to the Forum Topics Tool has achieved a
> good amount of discussion and consensus that it's a worthwhile topic. After
> submissions close, a team of representatives from the User Committee, the
> Technical Committee, and Foundation staff will take the sessions proposed
> by the community and fill out the schedule.
> 
> You can expect the draft schedule to be released on October 9th, 2017.
> 
> Further details about the Forum can be found at:
> https://wiki.openstack.org/wiki/Forum

Hi all!

We're a bit delayed in having that draft available for you all. The committee
has voted on the submitted forum topics and is currently waiting to hold
a discussion on Wednesday October 11th to finalize the selection.

You can now expect a draft available October 12th. Thank you.

-- 
Mike Perez


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

Re: [openstack-dev] Sydney Forum Topic Submission

2017-10-10 Thread Mike Perez

On 16:15 Sep 21, Shamail Tahir wrote:
> Hi,
> 
> We have made it to the next stage of the topic selection process for the
> Forum in Sydney!
> 
> At the Forum the entire OpenStack community (users and developers) gathers
> to brainstorm the requirements for the next release, gather feedback on the
> past version and have strategic discussions that go beyond just one release
> cycle. The Sydney Forum is the start of the Rocky release cycle. Please
> prepare session ideas with feedback from the Pike release in mind.
> 
> Our submission tool is now open for you to submit abstracts for the most
> popular sessions that came out of your brainstorming.
> 
> Ask all session leaders to submit their abstracts at:
> http://forumtopics.openstack.org/
> 
> before *11:59PM UTC on Friday September 29th*!
> 
> We are looking for a good mix of project-specific, cross-project or
> strategic/whole-of-community discussions, and sessions that emphasize
> collaboration between users and developers are most welcome!
> 
> We assume that anything submitted to the Forum Topics Tool has achieved a
> good amount of discussion and consensus that it's a worthwhile topic. After
> submissions close, a team of representatives from the User Committee, the
> Technical Committee, and Foundation staff will take the sessions proposed
> by the community and fill out the schedule.
> 
> You can expect the draft schedule to be released on October 9th, 2017.
> 
> Further details about the Forum can be found at:
> https://wiki.openstack.org/wiki/Forum

Hi all!

We're a bit delayed in having that draft available for you all. The committee
has voted on the submitted forum topics and is currently waiting to hold
a discussion on Wednesday October 11th to finalize the selection.

You can now expect a draft available October 12th. Thank you.

-- 
Mike Perez


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

[openstack-dev] [tc][election] TC candidacy

2017-10-10 Thread Julia Kreger

Greetings Stackers!

I would like to submit my candidacy for the Technical Committee.

I have been involved with the OpenStack community since the Juno cycle and
interested in OpenStack while I worked as an engineer supporting data center
hosting operations. My experience having bridged these worlds means that I
understand the life of an operator and the thought process of a developer.
I care deeply about the success of OpenStack and believe that it is vital
for the the marketplace and open innovation.

I believe we have been excellent at building social and process complexity
to our own detriment. I feel that we need to evaluate and reconsider why we
do the things we do. I feel that we need better stand-alone usage cases and
usage. A shorter feedback loop with those different use cases would also help
us iterate faster as our software could then be consumed more easily.

It is true containers have taken over the limelight with many companies,
as they have shifted their resources away from OpenStack. I feel that we
must not forget that infrastructure and the underlying building blocks have
a place as well. It is also upon us to advocate for that as community
building is our strongest avenue to spread the word of OpenStack.

Many may know me as TheJulia on IRC. I've largely worked on Ironic and to a
lesser extent TripleO far off in the past. I'm one of those people that keeps
odd hours and tries to help others, as I feel strongly about supporting our
community and its users. I feel that this in turn supports ourselves and
helps us in the long term. I believe strongly in developing contributors and
also plainly admitting when I just don't know the answer to a question.
At the same time, I'm happy to help investigate and try to understand.

While we have navigated to this point with the hype curve, we need to set
our future course with a variety of thoughts and experiences. Combined with
my strong feelings about our community and overall mission, I feel that I
would be a good addition to the TC.

Thank you for your consideration,
Julia

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

Re: [openstack-dev] [Oslo][Designate][Congress] Problem with from_dict overrides and new oslo.context release

2017-10-10 Thread Ben Nemec

On 10/10/2017 07:14 AM, Graham Hayes wrote:

On 09/10/17 18:03, Ben Nemec wrote:

Hi,

I brought up the fix[1] I proposed for [2] in the Oslo meeting today,
and it led to some good discussion that we wanted to take to a broader
audience. In particular, the projects that are affected by the bug.

The oslo.context change I proposed would essentially obsolete the
from_dict function in the Context object since it would obligate us to
support all the keys in to_dict in the constructor. This unfortunately
implies some rather rigid constraints on the Context object. We could
essentially never remove any parameters from the constructor (which at
some point we want to do for things like "tenant" that are deprecated
but still present) or risk breaking if someone passed in parameters from
an old to_dict call.

The other proposal was to rewrite the existing naive from_dict overrides
in the affected projects to function more like the from_dict in the base
class where it explicitly handles only the keys that the constructor
will recognize.[3] One benefit of this approach is that it would allow
the removal of some previous workarounds[4]. This is also cleaner from
an API perspective as it doesn't impose any new requirements on the
oslo.context API. The obvious drawback is that it requires
project-specific fixes in the affected projects. We would, of course,
be happy to help with those fixes though.

So those are the options we've discussed and my thoughts on them. Please
feel free to weigh in with any other input you may have. Thanks.

-Ben

1: https://review.openstack.org/509919
2: https://launchpad.net/bugs/1721432
3:
https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L371

4:
https://github.com/openstack/designate/blob/46de766e513cfb97cbfc50b001734e02711517e4/designate/context.py#L42

I am happy to do whatever work is needed on the Designate side for a
good generic solution. We keep running into issues with our custom
`from_dict` so anything I can do to help avoid it would be great.

Cool, I've proposed https://review.openstack.org/510917 which I believe
will help avoid such issues in the future. I think we can generalize it
to the point where projects don't even have to carry an override for
from_dict to get their custom keys respected, but in the meantime this
should unblock things.

I'm also working on something similar for Congress, but I wanted to get
this out there for comment ASAP. I'll do the generalization as a
follow-up since it will require changes across oslo.context and the
consuming projects.

I put up a change to block 2.19.1 until we can pass the gate [1] with
the new solution

- Graham

1 - https://review.openstack.org/510857

Re: [openstack-dev] [all][infra] Zuul v3 rollout, the sequel

2017-10-10 Thread James E. Blair

Gary Kotton  writes:

> Hi,
> At the moment the neutron, neutron-lib and many of the decomposed projects 
> are still failing with the v3. Does this mean that we are broken from the 
> 11th?
> For the decomposed projects we have a work around to help address this in the 
> short term – need to increase timeout and need a flag from Zuul3 that is not 
> part of Jenkins - 
> https://github.com/openstack/vmware-nsx/blob/master/tools/tox_install_project.sh#L37
>  (can we have ZUUL3_CLONER?)
> Thanks
> Gary

In that script $ZUUL_CLONER points to /usr/zuul-env/bin/zuul-cloner
which will exist for auto-converted legacy jobs in v3.  If such a job is
not working, let's take a look at a log and dig into it.

That will *not* be present for non-legacy jobs.  I think once the dust
settles, we can work on using some much nicer facilities that v3
provides for doing that sort of thing in new native v3 jobs.

-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-operators] [publiccloud-wg] Meetup OpenStack Days Nordic


Hi everyone,

The OpenStack Days Nordic is around the corner, October 18-19th at 
Tivoli Hotel & Congress Center in Copenhagen.


The PublicCloud WG piggybacking on that event and having a Working Group 
Meetup. Time for that will be set during tomorrows bi-weekly meeting 
(1400 UTC #openstack-meeting-3). Will of course be great to see as many 
as possible of you joining us, both for the meetup it self, but also 
socializing during these days and have a drink together!


If you are planning to go to Copenhagen and haven't yet got yourself a 
ticket, as interested int the Public Cloud WG, use "OSDNPCWG2017" as 
promotional code and that will give you 30% discount.


Hope to see you in Copenhagen!

Cheers,
Tobias Rydberg
Chair Public Cloud WG




smime.p7s
Description: S/MIME Cryptographic Signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [publiccloud-wg] Meetup OpenStack Days Nordic


Hi everyone,

The OpenStack Days Nordic is around the corner, October 18-19th at 
Tivoli Hotel & Congress Center in Copenhagen.


The PublicCloud WG piggybacking on that event and having a Working Group 
Meetup. Time for that will be set during tomorrows bi-weekly meeting 
(1400 UTC #openstack-meeting-3). Will of course be great to see as many 
as possible of you joining us, both for the meetup it self, but also 
socializing during these days and have a drink together!


If you are planning to go to Copenhagen and haven't yet got yourself a 
ticket, as interested int the Public Cloud WG, use "OSDNPCWG2017" as 
promotional code and that will give you 30% discount.


Hope to see you in Copenhagen!

Cheers,
Tobias Rydberg
Chair Public Cloud WG




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

[openstack-dev] [tc][election] TC candidacy

2017-10-10 Thread Jeremy Stanley

As my first year on the OpenStack Technical Committee draws to a
close, I'm standing for reelection to a second term. I hold
consistent, strong views in favor of free software and
open/transparent community process, and vote my conscience on any
matters brought before the TC. I have experience as a user, an
operator and a developer, and do my best to accurately represent
concerns from all these perspectives. I feel honored to have
participated in the drafting of a TC vision, the decision to
encourage more strategic investment from contributors through
creation of a community-wide "help wanted" list, restructuring the
TC meeting/discussion model to improve accessibility across
time zones and cultures, and closer collaboration with the User
Committee and adjacent communities through the emergence of
role-neutral Special Interest Groups.

My personal vision for OpenStack is that of a vibrant and diverse
community packed with part-time and volunteer user-contributors
working in harmony (but also occasional creative cacophony) toward
well-defined common goals, and I intend to continue my efforts to
achieve this regardless of whatever elected positions I may hold. In
the past year I led the work to eliminate what I saw as a major
source of pain and confusion for new contributor on-boarding: the
technical requirement to join the OpenStack Foundation in order to
be able to submit patches to official projects. Following in that
theme, my primary goal for the coming year is to finally put an end
to Contributor License Agreement enforcement for patch submissions
(our long-awaited switch to Developer Certificate of Origin
"Signed-off-by" footers in commit messages).

Besides serving on the TC, I've been a core reviewer and root
sysadmin on OpenStack's community-maintained project infrastructure
for five years. I served the past two years as the Infrastructure
Project Team Lead but recently stepped down so as to free up
additional time to focus on broader community-wide governance. I've
also been doing vulnerability management in OpenStack for over four
years, regularly help with elections, chaired conference tracks
several times, and given talks to other communities on a variety of
OpenStack-related topics. I'm in regular attendance at two of the
three weekly TC office hours, but am also happy to entertain
concerns from anyone (publicly or in private) at any time; I love
hearing from members of our community and attempting to find answers
for you.
-- 
Jeremy Stanley


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

[Openstack-operators] [publiccloud-wg] Reminder meeting PublicCloudWorkingGroup


Hi everyone,

Don't forget tomorrows meeting for the PublicCloudWorkingGroup.
1400 UTC  in IRC channel #openstack-meeting-3

Etherpad and agenda: https://etherpad.openstack.org/p/publiccloud-wg

Regards,
Tobias Rydberg


smime.p7s
Description: S/MIME Cryptographic Signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [all][infra] Zuul v3 rollout, the sequel

2017-10-10 Thread Sean McGinnis

> 
> The common jobs have been fixed whenever bugs got reported. So, if you
> have current failures, tell us. Let me readd a quote from Jeremy:
> 
> >> In
> >> the meantime, if you've been digging into recent legacy job failures
> >> for your projects you should consider trying to bring them to our
> >> attention as soon as possible (in #openstack-infra on the Freenode
> >> IRC network, or replying on-list to this announcement) and work on
> >> fixing them if you're familiar enough with the failures to do so
> >> yourself.
> 

Well, there's a difference between "digging into recent legacy job failures"
and just waiting for all the red to go away. I have not dug into any failures
since it seemed like things were in a state of flux and therefore not worth
spending the time yet. But I guess now is the time.

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

Re: [openstack-dev] [oslo][mistral] Mistral expressions package

Excerpts from HADDLETON, Robert W (Bob)'s message of 2017-10-09 19:41:58 -0500:
> On 10/9/2017 2:35 PM, Doug Hellmann wrote:
> > Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:
> >> Hello Oslo team:
> >>
> >> The Mistral project has an expressions package [0] that is used to
> >> evaluate inline expressions using a context.  It has a pluggable
> >> architecture that presently supports Jinja and YAQL expression
> >> evaluation.  It also allows custom functions[1] to provide Python
> >> implementations of functionality that is then made available to the
> >> expression evaluation engines.
> >>
> >> This functionality was originally developed to support dynamic
> >> processing within Mistral workflows, but is also very useful in other
> >> applications that use templates which require runtime evaluation of
> >> expressions.
> >>
> >> I'd like to explore extracting this functionality from mistral to make
> >> it more widely available with minimal dependencies.
> >>
> >> The expressions dependencies are pretty limited:
> >>
> >> Jinja2
> >> oslo.utils
> >> oslo.log
> >> stevedore
> >> yaql
> >>
> >> and since 60% are already oslo-maintained packages, it seemed like a
> >> logical place to start.
> >>
> >> I'd appreciate feedback on the topic.  There is no real OpenStack
> >> dependency in the functionality, so maybe a standalone package on pypi
> >> makes sense.
> >>
> >> Thanks for your help,
> >>
> >> Bob Haddleton
> >>
> >>
> >> [0] https://github.com/openstack/mistral/tree/master/mistral/expressions
> >> [1]
> >> https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63
> >>
> > Oslo is a good place for things like this that have no other obvious
> > home, but if the Mistral team is already managing the code is there any
> > reason they couldn't also manage the library after you pull it out of
> > the service? It's much easier for any project team to manage a library
> > now, and we have several other examples of that pattern already.
> >
> > 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
> Hi Doug:
> 
> That's probably fine, we're just not sure what the process should be and 
> where the library would land?  Do you have an example that we could use 
> as a pattern?
> 
> Thanks
> 
> Bob

The first step is to create the repository with the library code. Then
you would add that repository to the list managed by the mistral team by
modifying the project list file in the governance repository.

Any of the project client libraries would work as an example of how to
set up the CI, governance, and release configuration. I think most of
the steps are covered in
https://docs.openstack.org/infra/manual/creators.html as well.

If the code is already isolated well within the mistral repo and you
want to preserve its history, you may also want to take a look at
http://git.openstack.org/cgit/openstack/oslo.tools/tree/filter_git_history.sh
as a tool for making the new repository.

I'm happy to help you work out a more detailed plan. Let me know if that
would be useful.

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-dev] [publiccloud-wg] Reminder meeting PublicCloudWorkingGroup


Hi everyone,

Don't forget tomorrows meeting for the PublicCloudWorkingGroup.
1400 UTC  in IRC channel #openstack-meeting-3

Etherpad and agenda: https://etherpad.openstack.org/p/publiccloud-wg

Regards,
Tobias Rydberg


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

[Openstack-operators] ops meetups team meeting minutes 2017-10-10

2017-10-10 Thread Chris Morgan

Fairly productive meeting today on IRC, minutes etc here:

Meeting ended Tue Oct 10 14:58:17 2017 UTC. Information about MeetBot at
http://wiki.debian.org/MeetBot . (v 0.1.4)
10:58 AM Minutes:
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-10-14.01.html
10:58 AM Minutes (text):
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-10-14.01.txt
10:58 AM Log:
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-10-14.01.log.html

Next week we will attempt to decide the geographic region for the 2nd meet
up of 2018 (the one between Vancouver and Berlin Summits). Meeting to be
held (as always) at 14:00 UTC on #openstack-operators

Chris

-- 
Chris Morgan 
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [stable] Preping for the stable/newton EOL

On Thu, Oct 5, 2017 at 4:01 PM, Tony Breeds  wrote:
[...]

> I'm happy to exclude tripleo from the initial EOL cycle (and had added
> tripleo's repos to my list of 'opt-out' repos based on previous emails).
> It'd be good if we could setup a one-off time with tripleo, stable (me)
> and infra to look at what CI you have an which parts are generally
> impacted by repo's EOLing.  For example it's probable that
> openstack/requiremnets (and that implies openstack-dev/devstack) need to
> be the last projects to retire.
>
> That isn't terrible but I'd still like to make sure we're on the same
> page so we can level set everyone's expectations.
>
> So who from tripleo needs to be there and what TZ are they in?

It would be me (PST but flexible enough to work on your morning with you).

These are the jobs we currently have for newton:

puppet-tripleo:
OpenStack Infra:
gate-puppet-tripleo-puppet-lint in 11m 51s
gate-puppet-tripleo-puppet-syntax-3-legacy-centos-7 in 3m 52s
gate-puppet-tripleo-puppet-syntax-4-centos-7 in 3m 11s
gate-tripleo-ci-centos-7-nonha-multinode-oooq in 1h 36m 42s
gate-tripleo-ci-centos-7-undercloud-oooq in 49m 23s
gate-puppet-tripleo-puppet-unit-4.8-centos-7 in 7m 26s

RH1:
gate-tripleo-ci-centos-7-ovb-ha-oooq in 2h 29m 44s
gate-tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024 in 2h 24m 02s


tripleo-heat-templates and others:

OpenStack Infra:
gate-tripleo-ci-centos-7-nonha-multinode-oooq in 1h 45m 38s
gate-tripleo-heat-templates-pep8-ubuntu-xenial in 1m 36s

RH1:
gate-tripleo-ci-centos-7-ovb-ha-oooq in 2h 29m 44s
gate-tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024 in 2h 24m 02s

We don't have upgrade jobs on stable/newton, so the amount of consumed
resources is reasonable I guess.

Ping me anytime for further discussion,
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] Use of CUSTOM Traits

2017-10-10 Thread Ramu, MohanX

Thank you Chris.

CUSTOM_PHYSNET1 - custom Traits name , but the value should be something like 
ens160 for NIC.

How that NIC value is assigned to CUSTOM_PHYSNET1.

-Original Message-
From: Chris Dent [mailto:cdent...@anticdent.org] 
Sent: Tuesday, October 10, 2017 7:32 PM
To: openstack@lists.openstack.org
Subject: Re: [Openstack] Use of CUSTOM Traits

On Tue, 10 Oct 2017, Ramu, MohanX wrote:

> Please let me know, what is the main purpose of Custom Traits, can we use for 
> assigning some value to traits. If yes, how?

You can't assign a value to a trait. The trait is the value. You're assigning 
the trait to a resource provider. If it is a custom trait, you may need to 
create it first.

You can think of traits like a tag: it describes a qualitative aspect of the 
resource provider it is associated with. So while a disk can have 2000 GB, it 
either is or is not an SSD.

If you haven't had a chance to read
http://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/resource-provider-traits.html
that may be of some help.

Also: https://developer.openstack.org/api-ref/placement/#traits

So, with custom traits, the idea is that there is some qualitative "trait" that 
is specific ("custom") to your environment. One of the ways this been discussed 
as being useful is associating a NIC to a physical network: CUSTOM_PHYSNET1

For more on that see this spec that is under consideration:

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

it plans to make extensive use of custom traits.

-- 
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent
___
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] [Neutron][ovn] networking-ovn-core updates

2017-10-10 Thread Numan Siddique

Awesome.

Welcome   Miguel and Yamamoto!

Thanks
Numan


On Tue, Oct 10, 2017 at 7:46 PM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

> Thank you very much :-)
>
> On Tue, Oct 10, 2017 at 4:09 PM, Lucas Alvares Gomes Martins <
> lmart...@redhat.com> wrote:
>
>> Hi,
>>
>> On Tue, Oct 10, 2017 at 2:25 PM, Russell Bryant 
>> wrote:
>> > Hello, everyone.  I'd like to welcome two new members to the
>> > networking-ovn-core team: Miguel Angel Ajo and Yamamoto Takashi.
>> >
>>
>> Great additions, welcome on board Miguel and Yamamoto!
>>
>> Cheers,
>> Lucas
>>
>
>
__
OpenStack Development Mailing 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][ovn] networking-ovn-core updates

2017-10-10 Thread Miguel Angel Ajo Pelayo

Thank you very much :-)

On Tue, Oct 10, 2017 at 4:09 PM, Lucas Alvares Gomes Martins <
lmart...@redhat.com> wrote:

> Hi,
>
> On Tue, Oct 10, 2017 at 2:25 PM, Russell Bryant 
> wrote:
> > Hello, everyone.  I'd like to welcome two new members to the
> > networking-ovn-core team: Miguel Angel Ajo and Yamamoto Takashi.
> >
>
> Great additions, welcome on board Miguel and Yamamoto!
>
> Cheers,
> Lucas
>
__
OpenStack Development Mailing 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] [ocata] nova-api error 404 instance not found

2017-10-10 Thread Matt Riedemann


On 10/10/2017 3:53 AM, Kim-Norman Sahm wrote:

Hi,

i've upgraded from newton to ocata and i my last problem (i hope so) is
in the nova-api.
if i try to create a new instance (horizon or cli) i get an "404
instance no found" error but is instance is created and started as
well.

nova-api.log:

2017-10-10 08:16:31.682 6 DEBUG nova.compute.api [req-4d354485-cfe9-
40f2-8507-a48e02db0af0 db88dca6f68c4ab2b82dbad7476bb122
7c1dd7d33037481e81f55d2f5d45bb90 - default default] [instance:
e564c631-896c-458c-93ab-b1c88f444fff] Fetching instance by UUID get
/usr/lib/python2.7/dist-packages/nova/compute/api.py:2360
2017-10-10 08:16:31.785 6 INFO nova.api.openstack.wsgi [req-4d354485-
cfe9-40f2-8507-a48e02db0af0 db88dca6f68c4ab2b82dbad7476bb122
7c1dd7d33037481e81f55d2f5d45bb90 - default default] HTTP exception
thrown: Instance e564c631-896c-458c-93ab-b1c88f444fff could not be
found.
2017-10-10 08:16:31.787 6 DEBUG nova.api.openstack.wsgi [req-4d354485-
cfe9-40f2-8507-a48e02db0af0 db88dca6f68c4ab2b82dbad7476bb122
7c1dd7d33037481e81f55d2f5d45bb90 - default default] Returning 404 to
user: Instance e564c631-896c-458c-93ab-b1c88f444fff could not be found.
__call__ /usr/lib/python2.7/dist-
packages/nova/api/openstack/wsgi.py:1039

Does anybody know whats the problem?

Best regards
Kim


Kim-Norman Sahm
Cloud & Infrastructure(OCI)
noris network AG
Thomas-Mann-Straße 16-20
90471 Nürnberg
Deutschland
Tel +49 911 9352 1433
Fax +49 911 9352 100

kim-norman.s...@noris.de
https://www.noris.de - Mehr Leistung als Standard
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689






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



Do you have all of the latest fixes for Ocata? You should be at version 
15.0.7 if you're on the latest Ocata fix release.


Is the instance properly mapped to a cell? Try querying the nova_api 
database:


select * from nova_api.instance_mappings where instance_uuid = 
"e564c631-896c-458c-93ab-b1c88f444fff";


Did the instance go to ACTIVE state or did it fail to schedule? If it 
failed to schedule, it would be in the nova_cell0 database and should be 
in ERROR state. You could query the cell0 database with:


select * from nova_cell0.instances where uuid = 
"e564c631-896c-458c-93ab-b1c88f444fff";


Otherwise see #3 in the Cells FAQs page here:

https://docs.openstack.org/nova/latest/user/cells#faqs

--

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] Use of CUSTOM Traits

2017-10-10 Thread Chris Dent


On Tue, 10 Oct 2017, Ramu, MohanX wrote:


Please let me know, what is the main purpose of Custom Traits, can we use for 
assigning some value to traits. If yes, how?


You can't assign a value to a trait. The trait is the value. You're
assigning the trait to a resource provider. If it is a custom trait,
you may need to create it first.

You can think of traits like a tag: it describes a qualitative
aspect of the resource provider it is associated with. So while a
disk can have 2000 GB, it either is or is not an SSD.

If you haven't had a chance to read
http://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/resource-provider-traits.html
that may be of some help.

Also: https://developer.openstack.org/api-ref/placement/#traits

So, with custom traits, the idea is that there is some qualitative
"trait" that is specific ("custom") to your environment. One of the
ways this been discussed as being useful is associating a NIC to a
physical network: CUSTOM_PHYSNET1

For more on that see this spec that is under consideration:

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

it plans to make extensive use of custom traits.

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent___
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] Use of CUSTOM Traits

2017-10-10 Thread Ramu, MohanX

Hi All,

Please let me know, what is the main purpose of Custom Traits, can we use for 
assigning some value to traits. If yes, how?

Thanks & Regards,

Mohan Ramu

___
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] Pike - Unable to retrieve project list

2017-10-10 Thread Ramu, MohanX


Hi All,

When I use CLI command for listing project list I got below o/p.

openstack project list
+--+-+
| ID   | Name|
+--+-+
| 298899cb52df41a08996f51f8c880ac2 | demo|
| d76b06088ae145df9b4b63ed459880e4 | admin   |
| f8dd55e1bac44eb1b6341883f3a8910c | service |
+--+-+

But when I try from UI/Dashboard page , I get the following error.

Can anyone help me to resolve this error.

Error: Unable to retrieve project list.


Thanks & Regards,
Mohan Ramu
___
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] Sydney Forum Topic Submission

2017-10-10 Thread Matt Riedemann


On 9/21/2017 3:15 PM, Shamail Tahir wrote:

You can expect the draft schedule to be released on October 9th, 2017.


I still see a lot of unreviewed forum topic submissions:

http://forumtopics.openstack.org/

Is there a plan to have that list narrowed down by end of week or early 
next week?


--

Thanks,

Matt

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

Re: [openstack-dev] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

On Tue, Oct 10, 2017 at 4:24 AM, Flavio Percoco  wrote:
[...]
> The roles don't have tripleo in their names. The only role that mentions
> tripleo
> is tripleo specific. As for the APB, yeah, I had thought about renaming that
> repo to something without tripleo in there: Perhaps just `ansible-k8s-apbs`.

This proposal works for me.

> I'm about to refactor this repo to remove all the code duplication. We
> should be
> able to generate most of the APB code that's in there from a python script.
> We
> could even have this script in tripleo_common, if it sounds sensible.
>
> Thoughts?

++ for removing duplication and using common roles / libraries when possible.
roles should only have service specific bits at the end.

I also see an opportunity to welcome contributors from outside of
TripleO if some are interested by deploying OpenStack with Ansible
apbs.

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

[OpenStack-Infra] [openstack-infra] [nova] build log REST access

2017-10-10 Thread Klérisson Paixão

Hi everyone!

I'm looking for documentation on how to access the REST API of openstack
logstash/elasticsearch to retrieve builds logs.
Could you, please, point me out how to start?

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

[openstack-dev] [Neutron][ovn] networking-ovn-core updates

2017-10-10 Thread Russell Bryant

Hello, everyone.  I'd like to welcome two new members to the
networking-ovn-core team: Miguel Angel Ajo and Yamamoto Takashi.

Miguel has been contributing to Neutron for a long time and was a past
member of the neutron-core team.  He has been focusing on OVN and its
integration with Neutron for the past 6 months or so and has made a great
impact to the project, both networking-ovn and OVN itself.  He helped build
L3 gateway HA support among other things.  He has also been contributing to
reviews for networking-ovn patches.

Yamamoto Takashi is a long time contributor across several projects,
including both Neutron and OVS.  He's a member of neutron-core and more
recently, neutron-drivers.  He's also one of the Open vSwitch project
committers.  Yamamoto has been contributing some reviews to the
networking-ovn repository.  We are thankful for his time and expertise on
the networking-ovn reviews and have added him to the core team.

They join the existing core team of: Russell Bryant, Dong Jun, Han Zhou,
Numan Siddique, and Lucas Alvares Gomes Martins.

Thanks,

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

[openstack-dev] [tripleo][networking] Organizing the networking squad

2017-10-10 Thread Brent Eagles

Hi all,

The list of TripleO squads includes a "networking squad". In previous
cycles, coordinating outside of IRC and email conversations seemed
unnecessary as there were only a few contributors and a small number of
initiatives. However, with future container related work, increased usage
of ansible, ongoing efforts like routed networks and NFV, os-net-config
related issues, and the increasing number of backends and networking
related services being added to TripleO, the world of TripleO networking
seems increasingly busy. I propose that we start organizing properly with
periodic sync-ups and coordinating efforts via etherpad (or similar) as
well as reporting into the weekly tripleo meeting.

Cheers,

Brent
__
OpenStack Development Mailing 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] l2gw

2017-10-10 Thread Ricardo Noriega De Soto

I've been taking a look at the implementation and thinking about which
cases update should be allowed.

At a first glance, I would say that we should allow updates:


   - Add a new interface (neutron l2-gateway-update gw1 --device
   name=hwvtep,interface_names=eth0,*eth1*) being eth1 the new interface.
   - Delete interface (neutron l2-gateway-update gw1 --device
   name=hwvtep,interface_names=eth0) removing eth1. In this case, we should
   check that the port has not any active connection.

However, in both cases there is a big issue, which is the granularity of
the segmentation-ids per port, right?? You cannot add or remove an l2gw
connection per port, which bring us to a dead end.

Let's say I add eth1 to an existing l2gw. How can I get a vlan tag to that
interface?? There is not l2gw-connection-update command... and trying to
create the same one will fail. Even if you try to update the l2gw instance
specifying the seg-id per port, it won't be active until a new connection
is created.

Folks, based on your experience, what's your take on this??

IMHO, there is no easy way of solving this but with a big re-architecture.

On Fri, Sep 29, 2017 at 1:46 PM, Lajos Katona 
wrote:

> Hi Ricardo,
>
> That is the exception which gives us the trouble.
>
> If you have ideas as you mentioned in which case a gw should be updated,
> and in what not, that would be really nice.
> Actually now we have a kind of development environment with devstack and
> vtep emulator (http://docs.openvswitch.org/en/latest/howto/vtep/) on the
> same host, what do you think is that enough to go on with this problem?
> I am not so sure if with vtep emulator we can cover all the good and bad
> (I mean when we mustn't do the update for example) scenarios.
>
> Regards
> Lajos
>
>
> On 2017-09-28 14:12, Ricardo Noriega De Soto wrote:
>
> I see the exception now Lajos:
>
> class L2GatewayInUse(exceptions.InUse):
> message = _("L2 Gateway '%(gateway_id)s' still has active mappings "
> "with one or more neutron networks.")
>
> :-)
>
> On Wed, Sep 27, 2017 at 6:40 PM, Ricardo Noriega De Soto <
> rnori...@redhat.com> wrote:
>
>> Hey Lajos,
>>
>> Is this the exception you are encountering?
>>
>> (neutron) l2-gateway-update --device name=hwvtep,interface_names=eth0,eth1
>> gw1
>> L2 Gateway 'b8ef7f98-e901-4ef5-b159-df53364ca996' still has active
>> mappings with one or more neutron networks.
>> Neutron server returns request_ids: ['req-f231dc53-cb7d-4221-ab74-
>> fa8715f85869']
>>
>> I don't see the L2GatewayInUse exception you're talking about, but I
>> guess it's the same situation.
>>
>> We should discuss in which case the l2gw instance could be updated, and
>> in which cases it shouldn't.
>>
>> Please, let me know!
>>
>>
>>
>> On Wed, Aug 16, 2017 at 11:14 AM, Lajos Katona > > wrote:
>>
>>> Hi,
>>>
>>> We faced an issue with l2-gw-update, which means that actually if there
>>> are connections for a gw the update will throw an exception
>>> (L2GatewayInUse), and the update is only possible after deleting first the
>>> connections, do the update and add the connections back.
>>>
>>> It is not exactly clear why this restriction is there in the code (at
>>> least I can't find it in docs or comments in the code, or review).
>>> As I see the check for network connections was introduced in this patch:
>>> https://review.openstack.org/#/c/144097 (https://review.openstack.org/
>>> #/c/144097/21..22/networking_l2gw/db/l2gateway/l2gateway_db.py)
>>>
>>> Could you please give me a little background why the update operation is
>>> not allowed on an l2gw with network connections?
>>>
>>> Thanks in advance for the help.
>>>
>>> Regards
>>> Lajos
>>>
>>> 
>>> __
>>> 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
>>>
>>
>>
>>
>> --
>> Ricardo Noriega
>>
>> Senior Software Engineer - NFV Partner Engineer | Office of Technology
>>  | Red Hat
>> irc: rnoriega @freenode
>>
>>
>
>
> --
> Ricardo Noriega
>
> Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
> Red Hat
> irc: rnoriega @freenode
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner

Re: [openstack-dev] [tripleo] Tripleo CI Community meeting tomorrow

2017-10-10 Thread Arx Cruz

Hello,

Sorry for the mistake, the bluejeans meeting is in
https://bluejeans.com/u/whayutin/

Kind regards,
Arx Cruz

On Mon, Oct 9, 2017 at 6:29 PM, Arx Cruz  wrote:

> Hello
>
> We are going to have a TripleO CI Community meeting tomorrow 10/10/2017 at
> 1 pm UTC time.
> The meeting is going to happen on BlueJeans [1] and also on IRC on
> #tripleo channel.
>
> After that, we will hold Office Hours starting at 4PM UTC in case someone
> from community have any questions related to CI.
>
> Hope to see you there.
>
> 1 - https://bluejeans.com/287352206?src=calendarLink
> 
>
>
> Kind regards,
> Arx Cruz
>
__
OpenStack Development Mailing 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] CentOS upgrade killed my Liberty system

2017-10-10 Thread Yaguang Tang

Can you paste out the horizon related error logs, may be caused by horizon
dependency issue.

On Tue, Oct 10, 2017 at 2:12 AM, Christopher Hull 
wrote:

> Hi all;
>
> About 18 months ago I did a piece by piece install of Liberty (following
> instructions on the Openstack page) and had been using it until somewhat
> recently when it broke after a CentOS 7 update ran.  I think Python/http is
> what changed / broke (sessionless connections no longer supported?).
> Basics like nova list still work, but Horizon won't run.
>
> How can I "downgrade" my CentOS box?
> Or alternatively, how painful is it to update to the most current
> Openstack?
>
> Also, I noticed that the CeotOS cloud SIG repo moved.
>
> Please help.  :-)
>
> BTW, for installs I wrote a tool to help with setting up the many
> Openstack config files.   If interested, you can find it here.
> http://chrishull.com/career/openstack/index.html
> https://github.com/chrishull/github-openstack
>
> Several months ago I tried to check this into the Openstack Operators GIT
> repo, but had difficulty.
>
> Anyway.  Please advise on how I can fix my Liberty system if you can.
>
> Thanks;
> -Chris
>
>
>
>
>
>
>
>
>
>
>
>
> - Christopher T. Hull
> My contract at NASA has ended and I am seeking new opportunities.
> For updated resume and other info, please click this link.
> http://faq.chrishull.com
> Sunnyvale CA. 94085
> (415) 385 4865 <(415)%20385-4865>
> chrishul...@gmail.com
> http://chrishull.com
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
Tang Yaguang
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [Designate] Meeting time

Hi All,

With a change of contributors, we now have a meeting at a time that is
inconvenient for most people.

I have a new survey for us to try and find a more suitable time here:

https://docs.google.com/forms/d/e/1FAIpQLSeF3P4545zBIxL_PnQnm8GshG2kjgRUylNTNjJCxLUhlDKCDA/viewform

If you are interested in attending the meetings, please fill in the
survey!

Thanks,

Graham



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-operators] COMING SOON! NEW COMMUNITY PORTAL!

2017-10-10 Thread ijaz ahmad

I think there should be some ghraphic/flash simulations that one can
configure ( from simple to more complex ) , run and see the openstack
components interactions. That ll be cool.

thanks

On 10 October 2017 at 13:00, <
openstack-operators-requ...@lists.openstack.org> wrote:

> Send OpenStack-operators mailing list submissions to
> openstack-operators@lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-operators
>
> or, via email, send a message with subject or body 'help' to
> openstack-operators-requ...@lists.openstack.org
>
> You can reach the person managing the list at
> openstack-operators-ow...@lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenStack-operators digest..."
>
>
> Today's Topics:
>
>1. COMING SOON! NEW COMMUNITY PORTAL! (Melvin Hillsman)
>2. Designate DNS service on Mitaka (Alexandra Kisin)
>3. CentOS upgrade killed my Liberty system (Christopher Hull)
>
>
> --
>
> Message: 1
> Date: Mon, 9 Oct 2017 05:04:42 -0700
> From: Melvin Hillsman 
> To: user-committee ,  OpenStack
> Operators ,  OpenStack
> Mailing List 
> Subject: [Openstack-operators] COMING SOON! NEW COMMUNITY PORTAL!
> Message-ID:
>  gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi everyone,
>
> We are planning to update openstack.org/community with a new fancy
> contributor portal.
>
> We would love to get your feedback. As a new user:
>
>- What is the first thing you should do try OpenStack?
>- How can you build a proof of concept?
>- Reading documentation or watching relevant summit videos
>- Reporting bugs
>- Grabbing tools from osops
>- Participating in the Forum and SIGs
>- etc...
>
>
>
> *Please respond to this thread or add feedback to the etherpad by Monday,
> October 16th, 2017.*
>
> https://etherpad.openstack.org/p/contributor-portal-user-section
>
> Mockups for reference:
>
> *PNG* - https://www.dropbox.com/sh/h7c2as0ko33e64y/AAANLpcFHQo
> 1fsIcZBNivtrma?dl=0
> *Invision* - https://invis.io/CSDEZTBDJ#/252645774_Landing
> -- next part --
> An HTML attachment was scrubbed...
> URL:  attachments/20171009/9af08ad4/attachment-0001.html>
>
> --
>
> Message: 2
> Date: Mon, 9 Oct 2017 17:52:59 +0300
> From: "Alexandra Kisin" 
> To: openstack-operators@lists.openstack.org
> Subject: [Openstack-operators] Designate DNS service on Mitaka
> Message-ID:
>  0051c...@notes.na.collabserv.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hello.
> Is there any installation / configuration guide for Designate service in
> Mitaka release (Ubuntu 14.04) ?
> And also I didn't find any detailed instructions for designate upgrade
> from Liberty to Mitaka.
>
> Thank you.
>
>
> Regards,
>
> Alexandra Kisin
> Servers & Network group, IBM R Labs in Israel
> Unix & Virtualization Team
>
>
> Phone: +972-48296172 | Mobile: +972-54-6976172 | Fax: +972-4-8296111
>
>
>
>
>
>
>
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL:  attachments/20171009/cfe3a6cc/attachment-0001.html>
> -- next part --
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/jpeg
> Size: 4292 bytes
> Desc: not available
> URL:  attachments/20171009/cfe3a6cc/attachment-0001.jpe>
> -- next part --
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/gif
> Size: 360 bytes
> Desc: not available
> URL:  attachments/20171009/cfe3a6cc/attachment-0001.gif>
>
> --
>
> Message: 3
> Date: Mon, 9 Oct 2017 11:12:18 -0700
> From: Christopher Hull 
> To: openstack-operators 
> Subject: [Openstack-operators] CentOS upgrade killed my Liberty system
> Message-ID:
>  gosbf2cg...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all;
>
> About 18 months ago I did a piece by piece install of Liberty (following
> instructions on the Openstack page) and had been using it until somewhat
> recently when it broke after a CentOS 7 update ran.  I think Python/http is
> what changed / broke (sessionless connections no longer supported?).
> Basics like nova list still work,

[Openstack] openstack heat multi tenant scenario

2017-10-10 Thread Charls D. Chap

Scenario:
-DomainA (TenantA, TenantB)
-TenantA(userA)
-TenantB(userB)
- A template which start OS:NOVA:SERVERS

1. Is it possible two run simultaneously the same openstack stack
create command?
2.
a. how can i specify that i want, in the first case, the VMs of the
stack, beloging to TenantA
and in the second case to TenantB
b. for the OS::NOVA::SERVER as fas as i can see there is no such
property to Distinguish project names

c. I want to achieve something like this
openstack stack create "mystack" for TenantA
openstack stack create "mystack" for TenantB
 openstack server list for TenantA
VM1 RUNNING
VM2 RUNNING

openstack server list for TenantB
VM1 RUNNING
VM2 RUNNING


So THE SAME VMs for both Tenants!

3. In the end, how is multi-tenancy achieved?
So far, I have achieved it, by having two different stack names,
tenantA and tenantB correspondingly, which take as input the same template,
with the same parameters.

___
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-operators] Libvirt CPU map (host-model)

2017-10-10 Thread Belmiro Moreira

Hi Paul,
yes, this is exactly what we are observing.
Thanks for the bugzilla pointer.

We now also opened a ticket through the RedHat support.

thanks,
Belmiro

On Mon, Oct 9, 2017 at 12:37 PM, Paul Browne  wrote:

> Hello Belmiro,
>
> We ran into this issue recently, similarly upgrading a RHEL7.3 OpenStack
> Platform Overcloud to RHEL7.4 and in the process upgrading libvirtd.
>
> For instances that were spawned prior to this upgrade, we see the CPU
> flags [1] , but for new instance workload the CPU flags [2]. Notably the
> CMT=disabled flag is present in [1] but absent in [2]
>
> This similarly prevents live migration of the older spawned instances, as
> the CMT=disabled flag is rejected.
>
> A RH bugzilla [3] was opened on the issue which attracted a lot of really
> good contributions from libvirt maintainers. The one sure-fire workaround
> we'd found is just to cold-boot the instance again, starting it under the
> new libvirtd. But from that BZ there is also a slightly more hack-ish
> workaround to hand-edit the running domain XML and clear the offending CMT
> flag (comment 12 on that BZ).
>
> Hope this helps some,
>
> Thanks,
> Paul Browne
>
> [1] https://pastebin.com/JshWi6i3
> [2] https://pastebin.com/5b8cAanP
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1495171
>
> On 9 October 2017 at 04:59, Belmiro Moreira  gmail.com> wrote:
>
>> Hi,
>> the CPU model that we expose to the guest VMs varies considering the
>> compute node use case.
>> We use "cpu_mode=host-passthrough" for the compute nodes that run batch
>> processing VMs and "cpu_mode=host-model" for the compute nodes for service
>> VMs. The reason to have "cpu_mode=host-model" is because we assumed that
>> new CPUs (in the libvirt map) will continue to support previous features
>> allowing for live migration when we need to move the VMs to a new CPU
>> generation.
>>
>> We recently upgraded from CentOS7.3 (libvirt 2.0.0) to CentOS7.4 (libvirt
>> 3.2.0) and noticed that now libvirt maps a slightly different CPU for the
>> guests. For example, still "Haswell no-TSX" but no mention to the feature
>> "cmt". This blocks suspended VMs to restore and live migrate.
>>
>> Has anyone experienced this same problem?
>>
>> We are thinking in few solutions but none of them are nice (downgrade
>> libvirt? hard reboot instances? ...)
>>
>> thanks,
>> Belmiro
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
>
> --
> ***
> Paul Browne
> Research Computing Platforms
> University Information Services
> Roger Needham Building
> JJ Thompson Avenue
> University of Cambridge
> Cambridge
> United Kingdom
> E-Mail: pf...@cam.ac.uk
> Tel: 0044-1223-746548
> ***
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Oslo][Designate][Congress] Problem with from_dict overrides and new oslo.context release