[openstack-dev] [gnocchi] gnocchi-keystone verification failed.

[__ mango.]

hi,
I have a question about the validation of gnocchi keystone.
I run the following command, but it is not successful.(api.auth_mode :basic, 
basic mode can be successful)

# gnocchi status --debug
REQ: curl -g -i -X GET http://localhost:8041/v1/status?details=False -H 
"Authorization: {SHA1}d4daf1cf567f14f32dbc762154b3a281b4ea4c62" -H "Accept: 
application/json, */*" -H "User-Agent: gnocchi keystoneauth1/3.1.0 
python-requests/2.18.1 CPython/2.7.12"
Starting new HTTP connection (1): localhost
http://localhost:8041 "GET /v1/status?details=False HTTP/1.1" 401 114
RESP: [401] Content-Type: application/json Content-Length: 114 
WWW-Authenticate: Keystone uri='http://192.168.12.244:5000/v3' Connection: 
Keep-Alive 
RESP BODY: {"error": {"message": "The request you have made requires 
authentication.", "code": 401, "title": "Unauthorized"}}

The request you have made requires authentication. (HTTP 401)
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cliff/app.py", line 400, in 
run_subcommand
result = cmd.run(parsed_args)
  File "/usr/lib/python2.7/dist-packages/cliff/display.py", line 113, in run
column_names, data = self.take_action(parsed_args)
  File "/usr/local/lib/python2.7/dist-packages/gnocchiclient/v1/status_cli.py", 
line 23, in take_action
status = utils.get_client(self).status.get()
  File "/usr/local/lib/python2.7/dist-packages/gnocchiclient/v1/status.py", 
line 21, in get
return self._get(self.url + '?details=%s' % details).json()
  File "/usr/local/lib/python2.7/dist-packages/gnocchiclient/v1/base.py", line 
37, in _get
return self.client.api.get(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 288, 
in get
return self.request(url, 'GET', **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/gnocchiclient/client.py", line 
52, in request
raise exceptions.from_response(resp, method)
Unauthorized: The request you have made requires authentication. (HTTP 401)
Traceback (most recent call last):
  File "/usr/local/bin/gnocchi", line 11, in 
sys.exit(main())
  File "/usr/local/lib/python2.7/dist-packages/gnocchiclient/shell.py", line 
251, in main
return GnocchiShell().run(args)
  File "/usr/lib/python2.7/dist-packages/cliff/app.py", line 279, in run
result = self.run_subcommand(remainder)
  File "/usr/lib/python2.7/dist-packages/cliff/app.py", line 400, in 
run_subcommand
result = cmd.run(parsed_args)
  File "/usr/lib/python2.7/dist-packages/cliff/display.py", line 113, in run
column_names, data = self.take_action(parsed_args)
  File "/usr/local/lib/python2.7/dist-packages/gnocchiclient/v1/status_cli.py", 
line 23, in take_action
status = utils.get_client(self).status.get()
  File "/usr/local/lib/python2.7/dist-packages/gnocchiclient/v1/status.py", 
line 21, in get
return self._get(self.url + '?details=%s' % details).json()
  File "/usr/local/lib/python2.7/dist-packages/gnocchiclient/v1/base.py", line 
37, in _get
return self.client.api.get(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 288, 
in get
return self.request(url, 'GET', **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/gnocchiclient/client.py", line 
52, in request
raise exceptions.from_response(resp, method)
gnocchiclient.exceptions.Unauthorized: The request you have made requires 
authentication. (HTTP 401)__
OpenStack Development Mailing 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] [reno] moved to storyboard

[Doug Hellmann]

I was remiss in not thanking fungi for his help with the move, and
diablo_rojo for preparing the docs explaining the rest of the steps I
needed to take afterwards. Thank you both!

Excerpts from Kendall Nelson's message of 2018-03-14 22:55:15 +:
> Woot woot!
> 
> -Kendall (diablo_rojo)
> 
> On Wed, Mar 14, 2018 at 7:51 AM Doug Hellmann  wrote:
> 
> > The bug tracker for reno has moved to storyboard:
> > https://storyboard.openstack.org/#!/project/933
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

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

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-03-15 11:59:00 +1100:
> On Thu, Mar 15, 2018 at 07:16:11AM +0900, Akihiro Motoki wrote:
> > The current version of proposed patches which drops tox_install.sh
> > works in our CI. Even if we have neutron>=12.0.0 (queens) or
> > horizon>=13.0.0 (queens), if we have "required-projects" in zuul v3
> > config, tox-sibling role ensures to install the latest master of
> > neutron/horizon. It is okay in our CI.
> > 
> > On the other hand, this change brings a couple of problems. I think it
> > is worth discussed broadly here.
> > 
> > (1) it makes difficult to run tests in local environment
> > We have only released version of neutron/horizon on PyPI. It means
> > PyPI version (i.e. queens) is installed when we run tox in our local
> > development. Most neutron stadium projects and horizon plugins depends
> > on the latest master. Test run in local environment will be broken. We
> > need to install the latest neutron/horizon manually. This confuses
> > most developers. We need to ensure that tox can run successfully in a
> > same manner in our CI and local environments.
> 
> This is an issue I agree and one we need to think about but it will be
> somewhat mitigated for local development by pbr siblings[1]
> 
> In the short term, developers can do something like:
> 
> for env in pep8,py35,py27 ; do
>tox -e $env --notest
>.tox/$env/bin/pip install -e /path/to/{horizon,neutron}
>tox -e $env
> done
> 
> Which is far from ideal but gives as a little breathing room to decide
> if we need to revert and try again in a while or persist with the plan
> as it stands.
> 
> pbr siblings wont fix all the issues we have and still makes consumption of
> neutron and horizon (and plugins / stadium projects) difficult outside
> of test.
>  
> > (2) neutron/horizon version in requirements.txt is confusing
> > In the cycle-with-milestone model, a new version of neutron/horizon
> > will be released only when a release is shipped.
> > The code depends on the latest master, but requirements.txt says it
> > depends on queens or later. It sounds confusing.
> 
> Yes we either need to create a new release-model or switch
> neutron/horizon to the cycle-with-intermediary model and encourage
> appropriate releases.  I'd really like to avoid publishing daily to pypi.

We keep doing lots of infra-related work to make it "easy" to do
things we shouldn't be doing in the first place when it comes to
managing dependencies.  There are three ways to address the issue
with horizon and neutron, and none of them involve adding features
to pbr.

1. Things that are being used like libraries need to release like
   libraries. Real releases. With appropriate version numbers. So
   that other things that depend on them can express valid dependencies.

2. Extract the relevant code into libraries and release *those*.

3. Things that are not stable enough to be treated as a library
   shouldn't be used that way. Move the things that use the application
   code as library code back into the repo with the thing that they
   are tied to but that we don't want to (or can't) treat like a
   library.

Let's stop making things hard on ourselves and start managing this
code properly.

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] [nova] Rocky PTG summary - cells

[melanie witt]

On Thu, 15 Mar 2018 09:54:59 +0800, Zhenyu Zheng wrote:

Thanks for the recap, got one question for the "block creation":

* An attempt to create an instance should be blocked if the project
has instances in a "down" cell (the instance_mappings table has a
"project_id" column) because we cannot count instances in "down"
cells for the quota check.


Since users are not aware of any cell information, and the cells are 
mostly randomly selected, there could be high possibility that 
users(projects) instances are equally spreaded across cells. The 
proposed behavior seems can
easily cause a lot of users couldn't create instances because one of the 
cells is down, isn't it too rude?


To be honest, I share your concern. I had planned to change quota checks 
to use placement instead of reading cell databases ASAP but hit a snag 
where we won't be able to count instances from placement because we 
can't determine the "type" of an allocation. Allocations can be 
instances, or network-related resources, or volume-related resources, 
etc. Adding the concept of an allocation "type" in placement has been a 
controversial discussion so far.


BUT ... we also said we would add a column like "queued_for_delete" to 
the instance_mappings table. If we do that, we could count instances 
from the instance_mappings table in the API database and count cores/ram 
from placement and no longer rely on reading cell databases for quota 
checks. Although, there is one more wrinkle: instance_mappings has a 
project_id column but does not have a user_id column, so we wouldn't be 
able to get a count by project + user needed for the quota check against 
user quota. So, if people would not be opposed, we could also add a 
"user_id" column to instance_mappings to handle that case.


I would prefer not to block instance creations because of "down" cells, 
so maybe there is some possibility to avoid it if we can get 
"queued_for_delete" and "user_id" columns added to the instance_mappings 
table.


-melanie




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

[openstack-dev] Fwd: 2.7 EOL = 2020 January 1

[Ed Leafe]

Just FYI to all the people who don't prioritize moving our code to Python3:

> Begin forwarded message:
> 
> From: Terry Reedy 
> Subject: 2.7 EOL = 2020 January 1
> Date: March 13, 2018 at 9:58:42 AM CDT
> To: python-l...@python.org
> 
> On March 10, on thread "Python 2.7 -- bugfix or security before EOL?", Guido 
> van Russum wrote
> 
> "The way I see the situation for 2.7 is that EOL is January 1st, 2020, and 
> there will be no updates, not even source-only security patches, after that 
> date. Support (from the core devs, the PSF, and python.org) stops completely 
> on that date. If you want support for 2.7 beyond that day you will have to 
> pay a commercial vendor. Of course it's open source so people are also 
> welcome to fork it. But the core devs have toiled long enough, and the 2020 
> EOL date (an extension from the originally annouced 2015 EOL!) was announced 
> with sufficient lead time and fanfare that I don't feel bad about stopping to 
> support it at all."
> 
> Two days later, Benjamin Peterson, the 2.7 release manager, replied "Sounds 
> good to me. I've updated the PEP to say 2.7 is completely dead on Jan 1 
> 2020." adding "The final release may not literally be on January 1st".
> 
> https://www.python.org/dev/peps/pep-0373/ now says
> "2.7 will receive bugfix support until January 1, 2020."
> 
> -- 
> Terry Jan Reedy
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 


-- Ed Leafe





__
OpenStack Development Mailing 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] Rocky PTG summary - cells

[Zhenyu Zheng]

Thanks for the recap, got one question for the "block creation":

  * An attempt to create an instance should be blocked if the project has
> instances in a "down" cell (the instance_mappings table has a "project_id"
> column) because we cannot count instances in "down" cells for the quota
> check.


Since users are not aware of any cell information, and the cells are mostly
randomly selected, there could be high possibility that users(projects)
instances are equally spreaded across cells. The proposed behavior seems can
easily cause a lot of users couldn't create instances because one of the
cells is down, isn't it too rude?

BR,

Kevin Zheng


On Thu, Mar 15, 2018 at 2:26 AM, Chris Dent  wrote:

> On Wed, 14 Mar 2018, melanie witt wrote:
>
> I’ve created a summary etherpad [0] for the nova cells session from the
>> PTG and included a plain text export of it on this email.
>>
>
> Nice summary. Apparently I wasn't there or paying attention when
> something was decided:
>
>  * An attempt to delete an instance in a "down" cell should result in a
>> 500 or 503 error.
>>
>
> Depending on how we look at it, this doesn't really align with what
> 500 or 503 are supposed to be used. They are supposed to indicate
> that the web server is broken in some fashion: 500 being an
> unexpected and uncaught exception in the web server, 503 that the
> web server is either overloaded or down for maintenance.
>
> So, you could argue that 409 is the right thing here (as seems to
> always happen when we discuss these things). You send a DELETE to
> kill the instance, but the current state of the instance is "on a
> cell that can't be reached" which is in "conflict" with the state
> required to do a DELETE.
>
> If a 5xx is really necessary, for whatever reason, then 503 is a
> better choice than 500 because it at least signals that the broken
> thing is sort of "over there somewhere" rather than the web server
> having an error (which is what 500 is supposed to mean).
>
> --
> Chris Dent   ٩◔̯◔۶   https://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions

[Ghanshyam Mann]

Thanks Zhipeng that helps and good idea. If new contributors find that they
will have enough information to start.

>From FirstContact SIG, we also maintain the Projects Liaisons to have
contact person for that project we can redirect the new contributors. idea
is to have multiple people from single project to cover all different
timezone. I think you already have your name there (+1).

..1 https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons

-gmann

On Thu, Mar 15, 2018 at 9:37 AM, Zhipeng Huang 
wrote:

> Hi folks,
>
> Sorry was not be able to make it to the First Contact SIG discussions in
> Dublin. The only suggestion I have is to have as many project as possible
> to have a dedicated FC SIG wiki page for localize onboarding support.
>
> For example like what we do in Cyborg: https://wiki.
> openstack.org/wiki/Cyborg/FirstContact I've captured all the discussions
> of the China Dev Group via a Chinese streaming site and also put the wiki
> link in the wechat group description, so that new developer know where to
> go to for a localize support.
>
> For communciation tools, per irc  I agree converge to #openstack-dev is
> better than maintaining some independent channels. But also from my
> experience video conf in native lang is more effective.
>
> On Thu, Mar 15, 2018 at 8:28 AM, Kendall Nelson 
> wrote:
>
>> We talked about this more during the meeting last night. Most people were
>> pretty neutral on the topic.
>>
>> I personally feel like #openstack-dev is the ideal place to direct people
>> once they get set up on irc and are interested in contributing, but maybe
>> that is because my perception of the chats in #openstack isn't correct.
>> Looking at the definition in the IRC channel list[1] and the channel
>> topic[2] I feel like it more for support questions on running openstack? I
>> dunno. I honestly didn't spend time in the channel really until I joined
>> last night so maybe my perception just needs an update. I am all ears for
>> your reasoning behind #openstack instead of #openstack-dev though too.
>> Please enlighten me :)
>>
>> -Kendall (diablo_rojo)
>>
>> [1] https://wiki.openstack.org/wiki/IRC
>> [2] Openstack Support Channel, Development in #openstack-dev | Wiki:
>> http://wiki.openstack.org/ | Docs: http://docs.openstack.org/ | Answers:
>> https://ask.openstack.org | Logs: http://eavesdrop.openstack.org/irclogs/
>> | Paste: http://paste.openstack.org/
>>
>>
>> On Tue, Mar 13, 2018 at 3:30 PM Amy Marrich  wrote:
>>
>>> Just one comment on this section before I forget again:
>>> #IRC Channels#
>>> We want to get rid of #openstack-101 and begin using #openstack-dev
>>> instead. The 101 channel isn't watched closely enough anymore and it makes
>>> more sense to move onboarding activities (like in OpenStack Upstream
>>> Institute) to a channel where there are people that can answer questions
>>> rather than asking those to move to a new channel. For those concerned
>>> about noise, OUI is run the weekend before the summit when most people are
>>> traveling to the Summit anyway.
>>>
>>> I would recommend sending folks to #openstack vs #openstack-dev by
>>> default.
>>>
>>> Amy (spotz)
>>>
>>> On Mon, Mar 5, 2018 at 2:00 PM, Kendall Nelson 
>>> wrote:
>>>
 Hello Everyone :)

 It was wonderful to see and talk with so many of you last week! For
 those that couldn't attend our whole day of chats or those that couldn't
 attend at all, I thought I would put forth a summary of our discussions
 which were mostly noted in the etherpad[1]

 #Contributor Guide#

 - Walkthrough: We walked through every section of what exists and came
 up with a variety of improvements on what is there. Most of these items
 have been added to our StoryBoard project[2]. This came up again Tuesday in
 docs sessions and I have added those items to StoryBoard as well.

 - Google Analytics: It was discussed we should do something about
 getting the contributor portal[3] to appear higher in Google searches about
 onboarding. Not sure what all this entails. NEEDS AN OWNER IF ANYONE WANTS
 TO VOLUNTEER.

 #Mission Statement#

 We updated our mission statement[4]! It now states:

 To provide a place for new contributors to come for information and
 advice. This group will also analyze and document successful contribution
 models while seeking out and providing information to new members of the
 community.

 #Weekly Meeting#

 We discussed beginning a weekly meeting- optimized for APAC/Europe and
 settled on 800 UTC in #openstack-meeting on Wednesdays. Proposed here[5].
 For now I added a section to our wiki for agenda organization[6]. The two
 main items we want to cover on a weekly basis are new contributor patches
 in gerrit and if anything has come up on ask.openstack.org about
 

Re: [openstack-dev] [OpenStackAnsible] Tag repos as newton-eol

[Tony Breeds]

On Wed, Mar 14, 2018 at 09:40:33PM +, Jean-Philippe Evrard wrote:
> Hello folks,
> 
> The list is almost perfect: you can do all of those except
> openstack/openstack-ansible-tests.
> I'd like to phase out openstack/openstack-ansible-tests and
> openstack/openstack-ansible later.

Okay excluding the 2 repos above and filtering out projects that don't
have newton branches we came down to:

# EOL repos belonging to OpenStackAnsible
eol_branch.sh -- stable/newton newton-eol \
 openstack/ansible-hardening \
 openstack/openstack-ansible-apt_package_pinning \
 openstack/openstack-ansible-ceph_client \
 openstack/openstack-ansible-galera_client \
 openstack/openstack-ansible-galera_server \
 openstack/openstack-ansible-haproxy_server \
 openstack/openstack-ansible-lxc_container_create \
 openstack/openstack-ansible-lxc_hosts \
 openstack/openstack-ansible-memcached_server \
 openstack/openstack-ansible-openstack_hosts \
 openstack/openstack-ansible-openstack_openrc \
 openstack/openstack-ansible-ops \
 openstack/openstack-ansible-os_aodh \
 openstack/openstack-ansible-os_ceilometer \
 openstack/openstack-ansible-os_cinder \
 openstack/openstack-ansible-os_glance \
 openstack/openstack-ansible-os_gnocchi \
 openstack/openstack-ansible-os_heat \
 openstack/openstack-ansible-os_horizon \
 openstack/openstack-ansible-os_ironic \
 openstack/openstack-ansible-os_keystone \
 openstack/openstack-ansible-os_magnum \
 openstack/openstack-ansible-os_neutron \
 openstack/openstack-ansible-os_nova \
 openstack/openstack-ansible-os_rally \
 openstack/openstack-ansible-os_sahara \
 openstack/openstack-ansible-os_swift \
 openstack/openstack-ansible-os_tempest \
 openstack/openstack-ansible-pip_install \
 openstack/openstack-ansible-plugins \
 openstack/openstack-ansible-rabbitmq_server \
 openstack/openstack-ansible-repo_build \
 openstack/openstack-ansible-repo_server \
 openstack/openstack-ansible-rsyslog_client \
 openstack/openstack-ansible-rsyslog_server \
 openstack/openstack-ansible-security

If you confirm I have the list right this time I'll work on this tomorrow

Yours Tony.


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

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Tony Breeds]

On Thu, Mar 15, 2018 at 07:16:11AM +0900, Akihiro Motoki wrote:
> The current version of proposed patches which drops tox_install.sh
> works in our CI. Even if we have neutron>=12.0.0 (queens) or
> horizon>=13.0.0 (queens), if we have "required-projects" in zuul v3
> config, tox-sibling role ensures to install the latest master of
> neutron/horizon. It is okay in our CI.
> 
> On the other hand, this change brings a couple of problems. I think it
> is worth discussed broadly here.
> 
> (1) it makes difficult to run tests in local environment
> We have only released version of neutron/horizon on PyPI. It means
> PyPI version (i.e. queens) is installed when we run tox in our local
> development. Most neutron stadium projects and horizon plugins depends
> on the latest master. Test run in local environment will be broken. We
> need to install the latest neutron/horizon manually. This confuses
> most developers. We need to ensure that tox can run successfully in a
> same manner in our CI and local environments.

This is an issue I agree and one we need to think about but it will be
somewhat mitigated for local development by pbr siblings[1]

In the short term, developers can do something like:

for env in pep8,py35,py27 ; do
   tox -e $env --notest
   .tox/$env/bin/pip install -e /path/to/{horizon,neutron}
   tox -e $env
done

Which is far from ideal but gives as a little breathing room to decide
if we need to revert and try again in a while or persist with the plan
as it stands.

pbr siblings wont fix all the issues we have and still makes consumption of
neutron and horizon (and plugins / stadium projects) difficult outside
of test.
 
> (2) neutron/horizon version in requirements.txt is confusing
> In the cycle-with-milestone model, a new version of neutron/horizon
> will be released only when a release is shipped.
> The code depends on the latest master, but requirements.txt says it
> depends on queens or later. It sounds confusing.

Yes we either need to create a new release-model or switch
neutron/horizon to the cycle-with-intermediary model and encourage
appropriate releases.  I'd really like to avoid publishing daily to pypi.

Yours Tony.

[1]
https://review.openstack.org/#/q/status:open+project:openstack-dev/pbr+branch:master+topic:fix-siblings-entrypoints


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

Re: [openstack-dev] [TripleO][CI][QA][HA][Eris][LCOO] Validating HA on upstream

[Ghanshyam Mann]

Thanks all for starting the collaboration on this which is long pending
things and we all want to have some start on this.

Myself and SamP talked about it during OPS meetup in Tokyo and we talked
about below draft plan-

- Update the Spec - https://review.openstack.org/#/c/443504/. which is
almost ready as per SamP and his team is working on that.
- Start the technical debate on tooling we can use/reuse like Yardstick
etc, which is more this mailing thread.
- Accept the new repo for Eris under QA and start at least something in
Rocky cycle.

I am in for having meeting on this which is really good idea. non-IRC
meeting is totally fine here. Do we have meeting place and time setup ?

-gmann

On Fri, Mar 9, 2018 at 8:16 PM, Bogdan Dobrelya  wrote:

> On 3/8/18 6:44 PM, Raoul Scarazzini wrote:
>
>> On 08/03/2018 17:03, Adam Spiers wrote:
>> [...]
>>
>>> Yes agreed again, this is a strong case for collaboration between the
>>> self-healing and QA SIGs.  In Dublin we also discussed the idea of the
>>> self-healing and API SIGs collaborating on the related topic of health
>>> check APIs.
>>>
>>
>> Guys, thanks a ton for your involvement in the topic, I am +1 to any
>> kind of meeting we can have to discuss this (like it was proposed by
>>
>
> Please count me in as well. I can't stop dreaming of Jepsen's Nemesis [0]
> hammering openstack to make it stronger :D
> Jokes off, let's do the best to consolidate on frameworks and tools and
> ditching NIH syndrome!
>
> [0] https://github.com/jepsen-io/jepsen/blob/master/jepsen/src/j
> epsen/nemesis.clj
>
> Adam) so I'll offer my bluejeans channel for whatever kind of meeting we
>> want to organize.
>> About the best practices part Georg was mentioning I'm 100% in
>> agreement, the testing methodologies are the first thing we need to care
>> about, starting from what we want to achieve.
>> That said, I'll keep studying Yardstick.
>>
>> Hope to hear from you soon, and thanks again!
>>
>>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing 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] [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions

[Zhipeng Huang]

Hi folks,

Sorry was not be able to make it to the First Contact SIG discussions in
Dublin. The only suggestion I have is to have as many project as possible
to have a dedicated FC SIG wiki page for localize onboarding support.

For example like what we do in Cyborg:
https://wiki.openstack.org/wiki/Cyborg/FirstContact I've captured all the
discussions of the China Dev Group via a Chinese streaming site and also
put the wiki link in the wechat group description, so that new developer
know where to go to for a localize support.

For communciation tools, per irc  I agree converge to #openstack-dev is
better than maintaining some independent channels. But also from my
experience video conf in native lang is more effective.

On Thu, Mar 15, 2018 at 8:28 AM, Kendall Nelson 
wrote:

> We talked about this more during the meeting last night. Most people were
> pretty neutral on the topic.
>
> I personally feel like #openstack-dev is the ideal place to direct people
> once they get set up on irc and are interested in contributing, but maybe
> that is because my perception of the chats in #openstack isn't correct.
> Looking at the definition in the IRC channel list[1] and the channel
> topic[2] I feel like it more for support questions on running openstack? I
> dunno. I honestly didn't spend time in the channel really until I joined
> last night so maybe my perception just needs an update. I am all ears for
> your reasoning behind #openstack instead of #openstack-dev though too.
> Please enlighten me :)
>
> -Kendall (diablo_rojo)
>
> [1] https://wiki.openstack.org/wiki/IRC
> [2] Openstack Support Channel, Development in #openstack-dev | Wiki:
> http://wiki.openstack.org/ | Docs: http://docs.openstack.org/ | Answers:
> https://ask.openstack.org | Logs: http://eavesdrop.openstack.org/irclogs/
> | Paste: http://paste.openstack.org/
>
>
> On Tue, Mar 13, 2018 at 3:30 PM Amy Marrich  wrote:
>
>> Just one comment on this section before I forget again:
>> #IRC Channels#
>> We want to get rid of #openstack-101 and begin using #openstack-dev
>> instead. The 101 channel isn't watched closely enough anymore and it makes
>> more sense to move onboarding activities (like in OpenStack Upstream
>> Institute) to a channel where there are people that can answer questions
>> rather than asking those to move to a new channel. For those concerned
>> about noise, OUI is run the weekend before the summit when most people are
>> traveling to the Summit anyway.
>>
>> I would recommend sending folks to #openstack vs #openstack-dev by
>> default.
>>
>> Amy (spotz)
>>
>> On Mon, Mar 5, 2018 at 2:00 PM, Kendall Nelson 
>> wrote:
>>
>>> Hello Everyone :)
>>>
>>> It was wonderful to see and talk with so many of you last week! For
>>> those that couldn't attend our whole day of chats or those that couldn't
>>> attend at all, I thought I would put forth a summary of our discussions
>>> which were mostly noted in the etherpad[1]
>>>
>>> #Contributor Guide#
>>>
>>> - Walkthrough: We walked through every section of what exists and came
>>> up with a variety of improvements on what is there. Most of these items
>>> have been added to our StoryBoard project[2]. This came up again Tuesday in
>>> docs sessions and I have added those items to StoryBoard as well.
>>>
>>> - Google Analytics: It was discussed we should do something about
>>> getting the contributor portal[3] to appear higher in Google searches about
>>> onboarding. Not sure what all this entails. NEEDS AN OWNER IF ANYONE WANTS
>>> TO VOLUNTEER.
>>>
>>> #Mission Statement#
>>>
>>> We updated our mission statement[4]! It now states:
>>>
>>> To provide a place for new contributors to come for information and
>>> advice. This group will also analyze and document successful contribution
>>> models while seeking out and providing information to new members of the
>>> community.
>>>
>>> #Weekly Meeting#
>>>
>>> We discussed beginning a weekly meeting- optimized for APAC/Europe and
>>> settled on 800 UTC in #openstack-meeting on Wednesdays. Proposed here[5].
>>> For now I added a section to our wiki for agenda organization[6]. The two
>>> main items we want to cover on a weekly basis are new contributor patches
>>> in gerrit and if anything has come up on ask.openstack.org about
>>> contributors so those will be standing agenda items.
>>>
>>> #Forum Session#
>>>
>>> We discussed proposing some forum sessions in order to get more
>>> involvement from operators. Currently, our activities focus on development
>>> activities and we would like to diversify. When this SIG was first proposed
>>> we wanted to have two chairs- one to represent developers and one to
>>> represent operators. We will propose a session or two when the call for
>>> forum proposals go out (should be today).
>>>
>>> #IRC Channels#
>>> We want to get rid of #openstack-101 and begin using #openstack-dev
>>> instead. The 101 channel isn't watched closely enough anymore 

Re: [openstack-dev] [Openstack-sigs] [First Contact][SIG] [PTG] Summary of Discussions

[Kendall Nelson]

We talked about this more during the meeting last night. Most people were
pretty neutral on the topic.

I personally feel like #openstack-dev is the ideal place to direct people
once they get set up on irc and are interested in contributing, but maybe
that is because my perception of the chats in #openstack isn't correct.
Looking at the definition in the IRC channel list[1] and the channel
topic[2] I feel like it more for support questions on running openstack? I
dunno. I honestly didn't spend time in the channel really until I joined
last night so maybe my perception just needs an update. I am all ears for
your reasoning behind #openstack instead of #openstack-dev though too.
Please enlighten me :)

-Kendall (diablo_rojo)

[1] https://wiki.openstack.org/wiki/IRC
[2] Openstack Support Channel, Development in #openstack-dev | Wiki:
http://wiki.openstack.org/ | Docs: http://docs.openstack.org/ | Answers:
https://ask.openstack.org | Logs: http://eavesdrop.openstack.org/irclogs/ |
Paste: http://paste.openstack.org/

On Tue, Mar 13, 2018 at 3:30 PM Amy Marrich  wrote:

> Just one comment on this section before I forget again:
> #IRC Channels#
> We want to get rid of #openstack-101 and begin using #openstack-dev
> instead. The 101 channel isn't watched closely enough anymore and it makes
> more sense to move onboarding activities (like in OpenStack Upstream
> Institute) to a channel where there are people that can answer questions
> rather than asking those to move to a new channel. For those concerned
> about noise, OUI is run the weekend before the summit when most people are
> traveling to the Summit anyway.
>
> I would recommend sending folks to #openstack vs #openstack-dev by default.
>
> Amy (spotz)
>
> On Mon, Mar 5, 2018 at 2:00 PM, Kendall Nelson 
> wrote:
>
>> Hello Everyone :)
>>
>> It was wonderful to see and talk with so many of you last week! For those
>> that couldn't attend our whole day of chats or those that couldn't attend
>> at all, I thought I would put forth a summary of our discussions which were
>> mostly noted in the etherpad[1]
>>
>> #Contributor Guide#
>>
>> - Walkthrough: We walked through every section of what exists and came up
>> with a variety of improvements on what is there. Most of these items have
>> been added to our StoryBoard project[2]. This came up again Tuesday in docs
>> sessions and I have added those items to StoryBoard as well.
>>
>> - Google Analytics: It was discussed we should do something about getting
>> the contributor portal[3] to appear higher in Google searches about
>> onboarding. Not sure what all this entails. NEEDS AN OWNER IF ANYONE WANTS
>> TO VOLUNTEER.
>>
>> #Mission Statement#
>>
>> We updated our mission statement[4]! It now states:
>>
>> To provide a place for new contributors to come for information and
>> advice. This group will also analyze and document successful contribution
>> models while seeking out and providing information to new members of the
>> community.
>>
>> #Weekly Meeting#
>>
>> We discussed beginning a weekly meeting- optimized for APAC/Europe and
>> settled on 800 UTC in #openstack-meeting on Wednesdays. Proposed here[5].
>> For now I added a section to our wiki for agenda organization[6]. The two
>> main items we want to cover on a weekly basis are new contributor patches
>> in gerrit and if anything has come up on ask.openstack.org about
>> contributors so those will be standing agenda items.
>>
>> #Forum Session#
>>
>> We discussed proposing some forum sessions in order to get more
>> involvement from operators. Currently, our activities focus on development
>> activities and we would like to diversify. When this SIG was first proposed
>> we wanted to have two chairs- one to represent developers and one to
>> represent operators. We will propose a session or two when the call for
>> forum proposals go out (should be today).
>>
>> #IRC Channels#
>> We want to get rid of #openstack-101 and begin using #openstack-dev
>> instead. The 101 channel isn't watched closely enough anymore and it makes
>> more sense to move onboarding activities (like in OpenStack Upstream
>> Institute) to a channel where there are people that can answer questions
>> rather than asking those to move to a new channel. For those concerned
>> about noise, OUI is run the weekend before the summit when most people are
>> traveling to the Summit anyway.
>>
>> #Ongoing Onboarding Efforts#
>>
>> - GSOC: Unfortunately we didn't get accepted this year. We will try again
>> next year.
>>
>> - Outreachy: Applications for the next round of interns are due March
>> 22nd, 2018 [7]. Decisions will be made by April and then internships run
>> May to August.
>>
>> - WoO Mentoring: The format of mentoring is changing from 1x1 to cohorts
>> focused on a single goal. If you are interested in helping out, please
>> contact me! I NEED HELP :)
>>
>> - Contributor guide: Please see the above section.
>>
>> - OpenStack Upstream 

Re: [openstack-dev] [tripleo] TLS by default

[Julia Kreger]

On Wed, Mar 14, 2018 at 4:52 AM, Dmitry Tantsur  wrote:
> Just to clarify: only for public endpoints, right? I don't think e.g.
> ironic-python-agent can talk to self-signed certificates yet.
>
>

For what it is worth, it is possible for IPA to speak to a self signed
certificate, although it requires injecting the signing private CA
certificate into the ramdisk or iso image that is being used. There
are a few other options that can be implemented, but those may also
lower overall security posture.

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

[openstack-dev] [nova] Rocky PTG summary - nova/cinder

[melanie witt]

Hello all,

Here’s the PTG summary etherpad [0] for the nova/cinder session from the PTG, 
also included as a plain text export on this email.

Cheers,
-melanie

[0] https://etherpad.openstack.org/p/nova-ptg-rocky-cinder-summary

*Nova/Cinder: Rocky PTG Summary

https://etherpad.openstack.org/p/nova-ptg-rocky L63

*Key topics

  * New attach flow fixes and multi-attach
* Attach mode
* Swap volume with two read/write attachments
* SHELVED_OFFLOADED and 'in-use' state in old attach flow
* Server multi-create with attaching to the same volume fails
  * Data migration for old-style attachments
  * Volume replication for in-use volumes
  * Object-ifying os-brick connection_info
  * Formatting blank encrypted volumes during creation on the cinder side
  * Volume detail show reveals the attached compute hostname for non-admins
  * Bulk volume create/attach

*Agreements and decisions

  * To handle attach mode for a multi-attach volume to several instances, we 
will change the compute API to allow the user to pass the attach mode so we can 
pass it through to cinder
* The second attachment is going to be read/write by default and if the 
user wants read-only, they have to specify it
* Spec: https://review.openstack.org/#/c/552078/
  * Swap volume with two read/write attachments could definitely corrupt data. 
However, the cinder API doesn't allow retype/migration of in-use multi-attach 
volumes, so this isn't a problem right now
  * It would be reasonable to fix SHELVED_OFFLOADED to leave the volume in 
'reserved' state instead of 'in-use', but it's low priority
  * The bug with server multi-create and multi-attach will be fixed on the 
cinder side and we'll add a new compute API microversion to leverage the cinder 
fix
* Spec: https://review.openstack.org/#/c/552078/
  * We'll migrate old-style attachments on-the-fly when a change is made to a 
volume, such as a migration. For the rest, we'll migrate old-style attachments 
on compute startup to new-style attachments
* Compute startup data migration patch: 
https://review.openstack.org/#/c/549130/
  * For volume replication of in-use volumes, on the cinder side, we'll need a 
prototype and spec, and drivers will need to indicate the type of replication 
and what recovery on the nova side needs to be. On the nova side, we'll need a 
new API microversion for the os-server-external-events change (like extended 
volume)
* Owner: jgriffith
  * On the possibility of object-ifying connection_info in os-brick, it would 
be best to defer it until nova/neutron have worked out vif negotiation using 
os-vif
* lyarwood asked to restore https://review.openstack.org/#/c/269867/
  * On formatting blank encrypted volumes during creation, it sounded like we 
had agreement to fix it on the cinder side as they already have code for it. 
Need to double-check with the cinder team to make sure
  * For volume detail show revealing the attached compute hostname for 
non-admins, cinder will make a change to add a policy to not display the 
compute hostname for non-admins
* Note: this doesn't impact nova, but it might impact glance.
  * On bulk volume create/attach, it will be up to cinder to decide whether 
they will want to implement bulk create. In nova, we are not going to support 
bulk attach as that's a job better done by an orchestration system like Heat
* Note: Cinder team agreed to not support bulk create: 
https://wiki.openstack.org/wiki/CinderRockyPTGSummary#Bulk_Volume_Create.2FAttach


__
OpenStack Development Mailing 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] [reno] moved to storyboard

[Kendall Nelson]

Woot woot!

-Kendall (diablo_rojo)

On Wed, Mar 14, 2018 at 7:51 AM Doug Hellmann  wrote:

> The bug tracker for reno has moved to storyboard:
> https://storyboard.openstack.org/#!/project/933
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [infra][all] Anyone using our ubuntu-mariadb mirror?

[Ian Wienand]

Hello,

We discovered an issue with our mariadb package mirroring that
suggests it hasn't been updating for some time.

This would be packages from

 http://mirror.X.Y.openstack.org/ubuntu-mariadb/10.<1|2>

This was originally added in [1].  AFAICT from codesearch, it is
currently unused.  We export the top-level directory in the mirror
config scripts as NODEPOOL_MARIADB_MIRROR, which is not referenced in
any jobs [2], and I couldn't find anything setting up apt repos
pointing to it.

Thus since it's not updating and nothing seems to reference it, I am
going to assume it is unused and remove it next week.  If not, please
respond and we can organise a fix.

-i

[1] https://review.openstack.org/#/c/307831/
[2] 
http://codesearch.openstack.org/?q=NODEPOOL_MARIADB_MIRROR=nope==

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

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Paul Belanger]

On Wed, Mar 14, 2018 at 10:25:49PM +, Chris Dent wrote:
> On Thu, 15 Mar 2018, Akihiro Motoki wrote:
> 
> > (1) it makes difficult to run tests in local environment
> > We have only released version of neutron/horizon on PyPI. It means
> > PyPI version (i.e. queens) is installed when we run tox in our local
> > development. Most neutron stadium projects and horizon plugins depends
> > on the latest master. Test run in local environment will be broken. We
> > need to install the latest neutron/horizon manually. This confuses
> > most developers. We need to ensure that tox can run successfully in a
> > same manner in our CI and local environments.
> 
> Assuming that ^ is actually the case then:
> 
> This sounds like a really critical issue. We need to be really
> careful about automating the human out of the equation to the point
> where people are submitting broken code just so they can get a good
> test run. That's not great if we'd like to encourage various forms
> of TDD and the like and we also happen to have a limited supply of
> CI resources.
> 
> (Which is not to say that tox-siblings isn't an awesome feature. I
> hadn't really known about it until today and it's a great thing.)
> 
If ansible is our interface for developers to use, it shouldn't be difficult to
reproduce the environments locally to get master. This does mean changing the
developer workflow to use ansible, which I can understand might not be what
people want to do.

The main reason for removing install_tox.sh, is to remove zuul-cloner from our
DIB images, as zuulv3 no longer includes this command. Even running that
locally, would no longer work against git.o.o.

I agree, we should see how to make the migration for local developer
environments better.

Paul

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

Re: [openstack-dev] [bifrost][helm][OSA][barbican] Switching from fedora-26 to fedora-27

[Paul Belanger]

On Wed, Mar 14, 2018 at 04:44:07PM -0400, Paul Belanger wrote:
> On Wed, Mar 14, 2018 at 03:20:40PM -0400, Paul Belanger wrote:
> > On Wed, Mar 14, 2018 at 03:53:59AM +, na...@vn.fujitsu.com wrote:
> > > Hello Paul,
> > > 
> > > I am Nam from Barbican team. I would like to notify a problem when using 
> > > fedora-27. 
> > > 
> > > Currently, fedora-27 is using mariadb at 10.2.12. But there is a bug in 
> > > this version and it is the main reason for failure Barbican database 
> > > upgrading [1], the bug was fixed at 10.2.13 [2]. Would you mind updating 
> > > the version of mariadb before removing fedora-26.
> > > 
> > > [1] https://bugs.launchpad.net/barbican/+bug/1734329 
> > > [2] https://jira.mariadb.org/browse/MDEV-13508 
> > > 
> > Looking at https://apps.fedoraproject.org/packages/mariadb seems 10.2.13 has
> > already been updated. Let me recheck the patch and see if it will use the 
> > newer
> > version.
> > 
> Okay, it looks like our AFS mirrors for fedora our out of sync, I've proposed 
> a
> patch to fix that[3]. Once landed, I'll recheck the job.
> 
Okay, database looks to be fixed, but there are tests failing[4]. I'll defer
back to you to continue work on the migration.

[4] 
http://logs.openstack.org/20/547120/2/check/barbican-dogtag-devstack-functional-fedora-27/4cd64e0/job-output.txt.gz#_2018-03-14_22_29_49_400822

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

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Chris Dent]

On Thu, 15 Mar 2018, Akihiro Motoki wrote:


(1) it makes difficult to run tests in local environment
We have only released version of neutron/horizon on PyPI. It means
PyPI version (i.e. queens) is installed when we run tox in our local
development. Most neutron stadium projects and horizon plugins depends
on the latest master. Test run in local environment will be broken. We
need to install the latest neutron/horizon manually. This confuses
most developers. We need to ensure that tox can run successfully in a
same manner in our CI and local environments.


Assuming that ^ is actually the case then:

This sounds like a really critical issue. We need to be really
careful about automating the human out of the equation to the point
where people are submitting broken code just so they can get a good
test run. That's not great if we'd like to encourage various forms
of TDD and the like and we also happen to have a limited supply of
CI resources.

(Which is not to say that tox-siblings isn't an awesome feature. I
hadn't really known about it until today and it's a great thing.)

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Akihiro Motoki]

The current version of proposed patches which drops tox_install.sh
works in our CI. Even if we have neutron>=12.0.0 (queens) or
horizon>=13.0.0 (queens), if we have "required-projects" in zuul v3
config, tox-sibling role ensures to install the latest master of
neutron/horizon. It is okay in our CI.

On the other hand, this change brings a couple of problems. I think it
is worth discussed broadly here.

(1) it makes difficult to run tests in local environment
We have only released version of neutron/horizon on PyPI. It means
PyPI version (i.e. queens) is installed when we run tox in our local
development. Most neutron stadium projects and horizon plugins depends
on the latest master. Test run in local environment will be broken. We
need to install the latest neutron/horizon manually. This confuses
most developers. We need to ensure that tox can run successfully in a
same manner in our CI and local environments.

(2) neutron/horizon version in requirements.txt is confusing
In the cycle-with-milestone model, a new version of neutron/horizon
will be released only when a release is shipped.
The code depends on the latest master, but requirements.txt says it
depends on queens or later. It sounds confusing.

Thanks,
Akihiro


2018-03-15 6:56 GMT+09:00 Andreas Jaeger :
> On 2018-03-14 20:46, Andreas Jaeger wrote:
>> On 2018-03-14 20:39, Andreas Jaeger wrote:
>>> We now have neutron and horizon in global-requirements and do not need
>>> to install them anymore with tools/tox_install.sh.
>>>
>>> This allows to simplify our jobs and testing.
>>>
>>> Unfortunately, the merging caused now the projects that install neutron
>>> and horizon via tools/tox_install to break with constraints.
>>>
>>> I'm currently pushing up changes for these using topic tox-siblings [1].
>>>
>>> Please merge those - and if you're pushing up changes yourself, let's
>>> use the same topic.
>>>
>>> Sorry for the breakage ;(
>>> Andreas
>>>
>>> [1] Links
>>> https://review.openstack.org/#/q/topic:tox-siblings+(status:open+OR+status:merged)
>>>
>>
>> Note that thanks to the tox-siblings feature, we really continue to
>> install neutron and horizon from git - and not use the versions in the
>> global-requirements constraints file,
>
> Btw. this work is part of what Monty proposed in
> http://lists.openstack.org/pipermail/openstack-dev/2017-November/124676.html
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Andreas Jaeger]

On 2018-03-14 20:46, Andreas Jaeger wrote:
> On 2018-03-14 20:39, Andreas Jaeger wrote:
>> We now have neutron and horizon in global-requirements and do not need
>> to install them anymore with tools/tox_install.sh.
>>
>> This allows to simplify our jobs and testing.
>>
>> Unfortunately, the merging caused now the projects that install neutron
>> and horizon via tools/tox_install to break with constraints.
>>
>> I'm currently pushing up changes for these using topic tox-siblings [1].
>>
>> Please merge those - and if you're pushing up changes yourself, let's
>> use the same topic.
>>
>> Sorry for the breakage ;(
>> Andreas
>>
>> [1] Links
>> https://review.openstack.org/#/q/topic:tox-siblings+(status:open+OR+status:merged)
>>
> 
> Note that thanks to the tox-siblings feature, we really continue to
> install neutron and horizon from git - and not use the versions in the
> global-requirements constraints file,

Btw. this work is part of what Monty proposed in
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124676.html

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


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

Re: [openstack-dev] [security] Tomorrow's meeting and LCOO

[Luke Hinds]

Sounds great, thanks Gage!

I will try to catch up with you on Friday!

On Wed, Mar 14, 2018 at 6:51 PM, Gage Hugo  wrote:

> Hey Luke,
>
> I can chair the meeting tomorrow if that works.
>
> I will also ping eeiden about getting some LCOO discussion going as well.
>
> On Wed, Mar 14, 2018 at 1:35 PM, Luke Hinds  wrote:
>
>> Hello,
>>
>> Something has come up that determines I won't be able to attend the
>> meeting tomorrow and more importantly chair it.
>>
>> However I would not want to be a bottleneck to good progress underway.
>>
>> If someone would like to step up and chair for just this meeting, the
>> agenda is below:
>>
>> https://etherpad.openstack.org/p/security-agenda
>>
>> Also keep in mind, we now meet in #openstack-meeting at 15:00, instead of
>> 17:00.
>>
>> If not, we will defer and meet the week after.
>>
>> Last point, someone called eeiden pinged me on IRC, but have since logged
>> out. They LCOO has an interest in working with the security SIG, which is
>> most welcome. If anyone knows eeiden, can you ask him / her to contact us
>> on this list and we can get initial discussions going and hopefully bring
>> them into the meeting too.
>>
>> Cheers,
>>
>> Luke
>>
>
>


-- 
Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483
__
OpenStack Development Mailing 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] [OpenStackAnsible] Tag repos as newton-eol

[Jean-Philippe Evrard]

Hello folks,

The list is almost perfect: you can do all of those except
openstack/openstack-ansible-tests.
I'd like to phase out openstack/openstack-ansible-tests and
openstack/openstack-ansible later.

JP

On 14 March 2018 at 21:20, Tony Breeds  wrote:
> Hi all,
> JP has asked me to to work with infra to tag the newton branches of
> the following repos as EOL:
>
>
> openstack/ansible-hardening
> openstack/openstack-ansible-apt_package_pinning
> openstack/openstack-ansible-ceph_client
> openstack/openstack-ansible-galera_client
> openstack/openstack-ansible-galera_server
> openstack/openstack-ansible-haproxy_server
> openstack/openstack-ansible-lxc_container_create
> openstack/openstack-ansible-lxc_hosts
> openstack/openstack-ansible-memcached_server
> openstack/openstack-ansible-nspawn_container_create
> openstack/openstack-ansible-nspawn_hosts
> openstack/openstack-ansible-openstack_hosts
> openstack/openstack-ansible-openstack_openrc
> openstack/openstack-ansible-os_aodh
> openstack/openstack-ansible-os_barbican
> openstack/openstack-ansible-os_ceilometer
> openstack/openstack-ansible-os_cinder
> openstack/openstack-ansible-os_designate
> openstack/openstack-ansible-os_glance
> openstack/openstack-ansible-os_gnocchi
> openstack/openstack-ansible-os_heat
> openstack/openstack-ansible-os_horizon
> openstack/openstack-ansible-os_ironic
> openstack/openstack-ansible-os_keystone
> openstack/openstack-ansible-os_magnum
> openstack/openstack-ansible-os_molteniron
> openstack/openstack-ansible-os_neutron
> openstack/openstack-ansible-os_nova
> openstack/openstack-ansible-os_octavia
> openstack/openstack-ansible-os_panko
> openstack/openstack-ansible-os_rally
> openstack/openstack-ansible-os_sahara
> openstack/openstack-ansible-os_swift
> openstack/openstack-ansible-os_tacker
> openstack/openstack-ansible-os_tempest
> openstack/openstack-ansible-os_trove
> openstack/openstack-ansible-pip_install
> openstack/openstack-ansible-pip_lock_down
> openstack/openstack-ansible-plugins
> openstack/openstack-ansible-rabbitmq_server
> openstack/openstack-ansible-repo_build
> openstack/openstack-ansible-repo_server
> openstack/openstack-ansible-rsyslog_client
> openstack/openstack-ansible-rsyslog_server
> openstack/openstack-ansible-security
> openstack/openstack-ansible-ops
> openstack/openstack-ansible-os_almanach
> openstack/openstack-ansible-os_cloudkitty
> openstack/openstack-ansible-os_congress
> openstack/openstack-ansible-os_freezer
> openstack/openstack-ansible-os_karbor
> openstack/openstack-ansible-os_monasca
> openstack/openstack-ansible-os_monasca-agent
> openstack/openstack-ansible-os_monasca-ui
> openstack/openstack-ansible-os_searchlight
> openstack/openstack-ansible-os_watcher
> openstack/openstack-ansible-os_zaqar
> openstack/openstack-ansible-specs
> openstack/openstack-ansible-tests
>
> I'll process that this week after getting an ACK from JP
>
>
> Yours Tony.
>
> __
> OpenStack Development Mailing 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] Zuul flaw in json logging

[James E. Blair]

Hi,

If your project is using secrets in Zuul v3, please see the attached
message to determine whether they may have been disclosed.

OpenStack's Zuul is now running with the referenced fix in place, and we
have verified that the secrets used in the project-config repo (eg, to
upload logs and artifacts) were not subject to disclosure.

-Jim

--- Begin Message ---
Dear zuul operators

Simon Westphahl discovered a flaw within json logging of zuul where no_log is 
ignored for ansible loops. Tasks within a loop may be able to print decrypted 
secrets in job-output.json, despite setting no_log.

This is fixed in https://review.openstack.org/552799 by Simon.

All operators are encouraged to take following actions:

* Update your zuul
* Check if any jobs dealing with secrets also deal with them in loops using 
no_log. If not, you're safe
* If yes, check job-output.json if secrets are contained
* If yes, change your secret

Sorry for any inconveniences

Tobias


--
BMW Car IT GmbH
Tobias Henkel
Spezialist Entwicklung
Moosacher Straße 86
80809 München

Tel.:  ­+49 89 189311-48
Fax:  +49 89 189311-20
Mail: tobias.hen...@bmw.de
Web: http://www.bmw-carit.de
-
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit
und Christian Salzmann
Sitz und Registergericht: München HRB 134810
-


___
Zuul-announce mailing list
zuul-annou...@lists.zuul-ci.org
http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-announce
--- End Message ---
__
OpenStack Development Mailing 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] [OpenStackAnsible] Tag repos as newton-eol

[Tony Breeds]

Hi all,
JP has asked me to to work with infra to tag the newton branches of
the following repos as EOL:


openstack/ansible-hardening
openstack/openstack-ansible-apt_package_pinning
openstack/openstack-ansible-ceph_client
openstack/openstack-ansible-galera_client
openstack/openstack-ansible-galera_server
openstack/openstack-ansible-haproxy_server
openstack/openstack-ansible-lxc_container_create
openstack/openstack-ansible-lxc_hosts
openstack/openstack-ansible-memcached_server
openstack/openstack-ansible-nspawn_container_create
openstack/openstack-ansible-nspawn_hosts
openstack/openstack-ansible-openstack_hosts
openstack/openstack-ansible-openstack_openrc
openstack/openstack-ansible-os_aodh
openstack/openstack-ansible-os_barbican
openstack/openstack-ansible-os_ceilometer
openstack/openstack-ansible-os_cinder
openstack/openstack-ansible-os_designate
openstack/openstack-ansible-os_glance
openstack/openstack-ansible-os_gnocchi
openstack/openstack-ansible-os_heat
openstack/openstack-ansible-os_horizon
openstack/openstack-ansible-os_ironic
openstack/openstack-ansible-os_keystone
openstack/openstack-ansible-os_magnum
openstack/openstack-ansible-os_molteniron
openstack/openstack-ansible-os_neutron
openstack/openstack-ansible-os_nova
openstack/openstack-ansible-os_octavia
openstack/openstack-ansible-os_panko
openstack/openstack-ansible-os_rally
openstack/openstack-ansible-os_sahara
openstack/openstack-ansible-os_swift
openstack/openstack-ansible-os_tacker
openstack/openstack-ansible-os_tempest
openstack/openstack-ansible-os_trove
openstack/openstack-ansible-pip_install
openstack/openstack-ansible-pip_lock_down
openstack/openstack-ansible-plugins
openstack/openstack-ansible-rabbitmq_server
openstack/openstack-ansible-repo_build
openstack/openstack-ansible-repo_server
openstack/openstack-ansible-rsyslog_client
openstack/openstack-ansible-rsyslog_server
openstack/openstack-ansible-security
openstack/openstack-ansible-ops
openstack/openstack-ansible-os_almanach
openstack/openstack-ansible-os_cloudkitty
openstack/openstack-ansible-os_congress
openstack/openstack-ansible-os_freezer
openstack/openstack-ansible-os_karbor
openstack/openstack-ansible-os_monasca
openstack/openstack-ansible-os_monasca-agent
openstack/openstack-ansible-os_monasca-ui
openstack/openstack-ansible-os_searchlight
openstack/openstack-ansible-os_watcher
openstack/openstack-ansible-os_zaqar
openstack/openstack-ansible-specs
openstack/openstack-ansible-tests

I'll process that this week after getting an ACK from JP


Yours Tony.


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

Re: [openstack-dev] [bifrost][helm][OSA][barbican] Switching from fedora-26 to fedora-27

[Paul Belanger]

On Wed, Mar 14, 2018 at 03:20:40PM -0400, Paul Belanger wrote:
> On Wed, Mar 14, 2018 at 03:53:59AM +, na...@vn.fujitsu.com wrote:
> > Hello Paul,
> > 
> > I am Nam from Barbican team. I would like to notify a problem when using 
> > fedora-27. 
> > 
> > Currently, fedora-27 is using mariadb at 10.2.12. But there is a bug in 
> > this version and it is the main reason for failure Barbican database 
> > upgrading [1], the bug was fixed at 10.2.13 [2]. Would you mind updating 
> > the version of mariadb before removing fedora-26.
> > 
> > [1] https://bugs.launchpad.net/barbican/+bug/1734329 
> > [2] https://jira.mariadb.org/browse/MDEV-13508 
> > 
> Looking at https://apps.fedoraproject.org/packages/mariadb seems 10.2.13 has
> already been updated. Let me recheck the patch and see if it will use the 
> newer
> version.
> 
Okay, it looks like our AFS mirrors for fedora our out of sync, I've proposed a
patch to fix that[3]. Once landed, I'll recheck the job.

[3] https://review.openstack.org/553052
> > Thanks,
> > Nam
> > 
> > > -Original Message-
> > > From: Paul Belanger [mailto:pabelan...@redhat.com]
> > > Sent: Tuesday, March 13, 2018 9:54 PM
> > > To: openstack-dev@lists.openstack.org
> > > Subject: Re: [openstack-dev] [bifrost][helm][OSA][barbican] Switching from
> > > fedora-26 to fedora-27
> > > 
> > > On Mon, Mar 05, 2018 at 06:45:13PM -0500, Paul Belanger wrote:
> > > > Greetings,
> > > >
> > > > A quick search of git shows your projects are using fedora-26 nodes for
> > > testing.
> > > > Please take a moment to look at gerrit[1] and help land patches.  We'd
> > > > like to remove fedora-26 nodes in the next week and to avoid broken
> > > > jobs you'll need to approve these patches.
> > > >
> > > > If you jobs are failing under fedora-27, please take the time to fix
> > > > any issue or update said patches to make them non-voting.
> > > >
> > > > We (openstack-infra) aim to only keep the latest fedora image online,
> > > > which changes aprox every 6 months.
> > > >
> > > > Thanks for your help and understanding, Paul
> > > >
> > > > [1] https://review.openstack.org/#/q/topic:fedora-27+status:open
> > > >
> > > Greetings,
> > > 
> > > This is a friendly reminder, about moving jobs to fedora-27. I'd like to 
> > > remove
> > > our fedora-26 images next week and if jobs haven't been migrated you may
> > > start to see NODE_FAILURE messages while running jobs.  Please take a
> > > moment to merge the open changes or update them to be non-voting while
> > > you work on fixes.
> > > 
> > > Thanks again,
> > > Paul
> > > 
> > > __
> > > 
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-
> > > requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Andreas Jaeger]

On 2018-03-14 20:39, Andreas Jaeger wrote:
> We now have neutron and horizon in global-requirements and do not need
> to install them anymore with tools/tox_install.sh.
> 
> This allows to simplify our jobs and testing.
> 
> Unfortunately, the merging caused now the projects that install neutron
> and horizon via tools/tox_install to break with constraints.
> 
> I'm currently pushing up changes for these using topic tox-siblings [1].
> 
> Please merge those - and if you're pushing up changes yourself, let's
> use the same topic.
> 
> Sorry for the breakage ;(
> Andreas
> 
> [1] Links
> https://review.openstack.org/#/q/topic:tox-siblings+(status:open+OR+status:merged)
> 

Note that thanks to the tox-siblings feature, we really continue to
install neutron and horizon from git - and not use the versions in the
global-requirements constraints file,

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


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

[openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Andreas Jaeger]

We now have neutron and horizon in global-requirements and do not need
to install them anymore with tools/tox_install.sh.

This allows to simplify our jobs and testing.

Unfortunately, the merging caused now the projects that install neutron
and horizon via tools/tox_install to break with constraints.

I'm currently pushing up changes for these using topic tox-siblings [1].

Please merge those - and if you're pushing up changes yourself, let's
use the same topic.

Sorry for the breakage ;(
Andreas

[1] Links
https://review.openstack.org/#/q/topic:tox-siblings+(status:open+OR+status:merged)

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


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

Re: [openstack-dev] [bifrost][helm][OSA][barbican] Switching from fedora-26 to fedora-27

[Paul Belanger]

On Wed, Mar 14, 2018 at 03:53:59AM +, na...@vn.fujitsu.com wrote:
> Hello Paul,
> 
> I am Nam from Barbican team. I would like to notify a problem when using 
> fedora-27. 
> 
> Currently, fedora-27 is using mariadb at 10.2.12. But there is a bug in this 
> version and it is the main reason for failure Barbican database upgrading 
> [1], the bug was fixed at 10.2.13 [2]. Would you mind updating the version of 
> mariadb before removing fedora-26.
> 
> [1] https://bugs.launchpad.net/barbican/+bug/1734329 
> [2] https://jira.mariadb.org/browse/MDEV-13508 
> 
Looking at https://apps.fedoraproject.org/packages/mariadb seems 10.2.13 has
already been updated. Let me recheck the patch and see if it will use the newer
version.

> Thanks,
> Nam
> 
> > -Original Message-
> > From: Paul Belanger [mailto:pabelan...@redhat.com]
> > Sent: Tuesday, March 13, 2018 9:54 PM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [bifrost][helm][OSA][barbican] Switching from
> > fedora-26 to fedora-27
> > 
> > On Mon, Mar 05, 2018 at 06:45:13PM -0500, Paul Belanger wrote:
> > > Greetings,
> > >
> > > A quick search of git shows your projects are using fedora-26 nodes for
> > testing.
> > > Please take a moment to look at gerrit[1] and help land patches.  We'd
> > > like to remove fedora-26 nodes in the next week and to avoid broken
> > > jobs you'll need to approve these patches.
> > >
> > > If you jobs are failing under fedora-27, please take the time to fix
> > > any issue or update said patches to make them non-voting.
> > >
> > > We (openstack-infra) aim to only keep the latest fedora image online,
> > > which changes aprox every 6 months.
> > >
> > > Thanks for your help and understanding, Paul
> > >
> > > [1] https://review.openstack.org/#/q/topic:fedora-27+status:open
> > >
> > Greetings,
> > 
> > This is a friendly reminder, about moving jobs to fedora-27. I'd like to 
> > remove
> > our fedora-26 images next week and if jobs haven't been migrated you may
> > start to see NODE_FAILURE messages while running jobs.  Please take a
> > moment to merge the open changes or update them to be non-voting while
> > you work on fixes.
> > 
> > Thanks again,
> > Paul
> > 
> > __
> > 
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [self-healing] Dublin PTG summary, and request for feedback

[Adam Spiers]

Hi all,

I just posted a summary of the Self-healing SIG session at the Dublin
PTG:

  http://lists.openstack.org/pipermail/openstack-sigs/2018-March/000317.html

If you are interested in the topic of self-healing within OpenStack,
you are warmly invited to subscribe to the openstack-sigs mailing
list:

  http://lists.openstack.org/pipermail/openstack-sigs/

and/or join the #openstack-self-healing channel on Freenode IRC.

We are actively gathering feedback to help steer the SIG's focus in
the right direction, so all thoughts are very welcome, especially from
operators, since the primary goal of the SIG is to make life easier
for operators.

I have also just created an etherpad for brainstorming topics for the
Forum in Vancouver:

  https://etherpad.openstack.org/p/YVR-self-healing-brainstorming

Feel free to put braindumps in there :-)

Thanks!
Adam

__
OpenStack Development Mailing 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] [security] Tomorrow's meeting and LCOO

[Gage Hugo]

Hey Luke,

I can chair the meeting tomorrow if that works.

I will also ping eeiden about getting some LCOO discussion going as well.

On Wed, Mar 14, 2018 at 1:35 PM, Luke Hinds  wrote:

> Hello,
>
> Something has come up that determines I won't be able to attend the
> meeting tomorrow and more importantly chair it.
>
> However I would not want to be a bottleneck to good progress underway.
>
> If someone would like to step up and chair for just this meeting, the
> agenda is below:
>
> https://etherpad.openstack.org/p/security-agenda
>
> Also keep in mind, we now meet in #openstack-meeting at 15:00, instead of
> 17:00.
>
> If not, we will defer and meet the week after.
>
> Last point, someone called eeiden pinged me on IRC, but have since logged
> out. They LCOO has an interest in working with the security SIG, which is
> most welcome. If anyone knows eeiden, can you ask him / her to contact us
> on this list and we can get initial discussions going and hopefully bring
> them into the meeting too.
>
> Cheers,
>
> Luke
>
__
OpenStack Development Mailing 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] [security] Tomorrow's meeting and LCOO

[Luke Hinds]

Hello,

Something has come up that determines I won't be able to attend the meeting
tomorrow and more importantly chair it.

However I would not want to be a bottleneck to good progress underway.

If someone would like to step up and chair for just this meeting, the
agenda is below:

https://etherpad.openstack.org/p/security-agenda

Also keep in mind, we now meet in #openstack-meeting at 15:00, instead of
17:00.

If not, we will defer and meet the week after.

Last point, someone called eeiden pinged me on IRC, but have since logged
out. They LCOO has an interest in working with the security SIG, which is
most welcome. If anyone knows eeiden, can you ask him / her to contact us
on this list and we can get initial discussions going and hopefully bring
them into the meeting too.

Cheers,

Luke
__
OpenStack Development Mailing 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] Rocky PTG summary - cells

[Chris Dent]

On Wed, 14 Mar 2018, melanie witt wrote:


I’ve created a summary etherpad [0] for the nova cells session from the PTG and 
included a plain text export of it on this email.


Nice summary. Apparently I wasn't there or paying attention when
something was decided:


 * An attempt to delete an instance in a "down" cell should result in a 500 or 
503 error.


Depending on how we look at it, this doesn't really align with what
500 or 503 are supposed to be used. They are supposed to indicate
that the web server is broken in some fashion: 500 being an
unexpected and uncaught exception in the web server, 503 that the
web server is either overloaded or down for maintenance.

So, you could argue that 409 is the right thing here (as seems to
always happen when we discuss these things). You send a DELETE to
kill the instance, but the current state of the instance is "on a
cell that can't be reached" which is in "conflict" with the state
required to do a DELETE.

If a 5xx is really necessary, for whatever reason, then 503 is a
better choice than 500 because it at least signals that the broken
thing is sort of "over there somewhere" rather than the web server
having an error (which is what 500 is supposed to mean).

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Rocky PTG summary - cells

[melanie witt]

Hi everyone,

I’ve created a summary etherpad [0] for the nova cells session from the PTG and 
included a plain text export of it on this email.

Thanks,
-melanie

[0] https://etherpad.openstack.org/p/nova-ptg-rocky-cells-summary

*Cells: Rocky PTG Summary

https://etherpad.openstack.org/p/nova-ptg-rocky L11

*Key topics

  * How to handle a "down" cell
  * How to handle each cell having a separate ceph cluster
  * How do we plan to progress on removing "upcalls"

*Agreements and decisions

  * In order to list instances even when we can't connect to a cell database, 
we'll construct something minimal from the API database and we'll add a column 
to the instance_mappings table such as "queued_for_delete" to determine which 
are the non-deleted instances and then list them.
* tssurya will write a spec for the new column.
  * We're not going to pursue the approach of having backup URLs for cell 
databases to fall back on when a cell is "down".
  * An attempt to delete an instance in a "down" cell should result in a 500 or 
503 error.
  * An attempt to create an instance should be blocked if the project has 
instances in a "down" cell (the instance_mappings table has a "project_id" 
column) because we cannot count instances in "down" cells for the quota check.
* At this time, we won't pursue the idea of adding an allocation "type" 
concept to placement (which could be leveraged for counting cores/ram resource 
usage for quotas).
  * The topic of each cell having a separate ceph cluster and having each cell 
cache images in the imagebackend led to the topic of the "cinder imagebackend" 
again.
* Implementing a cinder imagebackend in nova would be an enormous 
undertaking that realistically isn't going to happen.
* A pragmatic solution was suggested to make boot-from-volume a first class 
citizen and make automatic boot-from-volume work well, so that we let cinder 
handle the caching of images in this scenario (and of course handle all of the 
other use cases for cinder imagebackend). This would eventually lead to the 
deprecation of the ceph imagebackend. Further discussion is required on this.
  * On removing upcalls, progress in placement will help address the remaining 
upcalls.
* dansmith will work on filtering compute hosts using the volume 
availability zone to address the cinder/cross_az_attach issue. mriedem and 
bauzas will review.
* For the xenapi host aggregate upcall, the xenapi subteam will remove it 
as a patch on top of their live-migration support patch series.
* For the server group late affinity check up-call for server create and 
evacuate, the plan is to handle it race-free with placement/scheduler. However, 
affinity modeling in placement isn't slated for work in Rocky, so the late 
affinity check upcall will have to be removed in S, at the earliest.

__
OpenStack Development Mailing 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] [First Contact][SIG] [PTG] Summary of Discussions

[Jay S Bryant]

On 3/14/2018 10:57 AM, Doug Hellmann wrote:

Excerpts from Jay S Bryant's message of 2018-03-14 10:38:37 -0500:

On 3/14/2018 10:04 AM, Petr Kovar wrote:

On Tue, 13 Mar 2018 18:57:24 -0500
Jay S Bryant  wrote:


Amy,

The top level page for projects is referenced under documentation from
here:  https://docs.openstack.org/queens/projects.html

So, I think we have that one covered for people who are just looking for
the top level documentation.

Yes, we have that covered. Just to clarify this a bit further, we also have
project lists like https://docs.openstack.org/queens/install/,
https://docs.openstack.org/queens/admin/ and
https://docs.openstack.org/queens/configuration/, what's missing is
https://docs.openstack.org/queens/contributor/.

Cheers,
pk


Petr,

Do we need a contributor link per-release?  I thought in past
discussions that the contributor info should always go to latest and
that was why this is slightly different.

Jay

We can have a per-series page that lists all projects and links to their
"latest" contributor doc page.


Agreed.  That would make the most sense.


Doug

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



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

[openstack-dev] Replacing Keystone Admin Accounts

[Adam Young]

As we attempt to close the gap on Bug 968696, we have to make sure we are
headed forward in a path that won't get us stuck.

It seems that many people use Admin-every accounts for many things that
they are not really meant for.  Such as performing Operations that should
be scoped to a project, like creating networks in Neutron or Block devices
in Cinder.

With the service scoping of role assignments, we have both the opportunity
and responsibility to rework how these operations are authorized.

Back in the time when we were discussing and engineering Hierarchical
Multi-tenancy (HMT) the operators told us that they did not want to have to
rescope tokens in order to provide help for their users.  I remember
getting this both verbally and in writing, although I cannot find the
message now.

If we created basic policy rules that allowed a Nova service account to
list all servers (for example) but not to change those servers without
getting a token scoped to that specific project, would it break a lot of
tooling?

The other use case we've found is the need to clean up project-scoped
resources.  Once a project has been deleted in Keystone, it is impossible
to get a project scoped token to delete the resources in cinder, glance,
and so on.  It seems like these operations need to be on a per-system
(service? endpoint) basis for the foreseeable future.  Is this acceptable?
Are there any alterntives that people would rather see implemented?
__
OpenStack Development Mailing 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][ThirdParty-CI] Nova s390x CI currently broken

[Andreas Scheuring]

A brief update: The root cause is that Neutron patch [1] broke Neutron DHCP and 
L3 agent on s390x (both use pyroute2 for network namespace management now). The 
issue needs to get fixed in pyroute2 itself. I opened a PR [2]. Ideally a new 
version gets released soon.


[1] https://github.com/openstack/neutron/commit/c4d4336
[2] https://github.com/svinota/pyroute2/pull/469

---
Andreas Scheuring (andreas_s)



On 13. Mar 2018, at 17:14, Andreas Scheuring  
wrote:

Hello, the s390x CI for nova is currently broken again. The reason seems to be 
a recent change that merged in neutron. I’m looking into it...

---
Andreas Scheuring (andreas_s)



__
OpenStack Development Mailing 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] [oslo.db] upcoming warnings in MySQL 5.6, 5.7 for BLOB columns

[Jay Pipes]

Neither nova nor placement use any BLOB columns.

Best,
-jay

On 03/14/2018 11:53 AM, Michael Bayer wrote:

hey all -

Just looking to see if we think this will impact openstack.  MySQL 5.6
and 5.7, but not yet MariaDB, now emits an erroneous warning when you
try to send a binary value to the database, because it sees the client
connection is supposed to use the utf8 or utf8mb4 charsets, assumes
all data must be in that charset, then warns because the binary data
does not necessarily conform to utf8 (which it has no need to, it's
binary).

Sounds weird, right, to make it easier the demo looks just like this:

import pymysql
import uuid

conn = pymysql.connect(
 user="scott", passwd="tiger", host="mysql56",
 db="test", charset="utf8mb4")
cursor = conn.cursor()
cursor.execute("""
 CREATE TABLE IF NOT EXISTS `profiles` (
   `id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL,
   `city` blob NOT NULL
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
""")
cursor.execute(
 "INSERT INTO profiles (id, city) VALUES (%(id)s, %(city)s)",
 {
 'id': uuid.uuid4().hex,
 'city': pymysql.Binary(
 
b'z\xf9\x87jS?\xd4i\xa5\xa3\r\xa7\x1e\xed\x16\xe0\xb5\x05R\xa4\xec\x16\x8f\x06\xb5\xea+\xaf<\x00\\\x94I9A\xe0\x82\xa7\x13\x0c\x8c'
 )
 }
)

when using PyMySQL 0.8.0 (not 0.7.1) you then get a warning

Warning: (1300, "Invalid utf8mb4 character string: 'F9876A'").


So, Oracle upstream clearly is never going to fix this if you look at
the typically dismal discussion at [1].   I poked the PyMySQL project
at [2] to see what we can do.   Long term is that SQLAlchemy will add
the special "_binary" prefix to binary-bound parameter tokens to avoid
the warning, however right now PyMySQL supports a flag "binary_prefix"
that will do it for us on the driver side.

For Openstack, i need to know if we are in fact passing binary data to
databases in some project or another.   What we can do is add the
supply of this flag to oslo.db so that it is present automatically for
the PyMySQL driver, as well as checking the PyMySQL version for
compatibility.

If folks are seeing this warning already or are using BLOB / binary
columns in their project please ping me and we will get this added to
oslo.db.

__
OpenStack Development Mailing 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] [oslo.db] upcoming warnings in MySQL 5.6, 5.7 for BLOB columns

[Michael Bayer]

Forgot the links:

[1] https://bugs.mysql.com/bug.php?id=79317
[2] https://github.com/PyMySQL/PyMySQL/issues/644

On Wed, Mar 14, 2018 at 11:53 AM, Michael Bayer  wrote:
> hey all -
>
> Just looking to see if we think this will impact openstack.  MySQL 5.6
> and 5.7, but not yet MariaDB, now emits an erroneous warning when you
> try to send a binary value to the database, because it sees the client
> connection is supposed to use the utf8 or utf8mb4 charsets, assumes
> all data must be in that charset, then warns because the binary data
> does not necessarily conform to utf8 (which it has no need to, it's
> binary).
>
> Sounds weird, right, to make it easier the demo looks just like this:
>
> import pymysql
> import uuid
>
> conn = pymysql.connect(
> user="scott", passwd="tiger", host="mysql56",
> db="test", charset="utf8mb4")
> cursor = conn.cursor()
> cursor.execute("""
> CREATE TABLE IF NOT EXISTS `profiles` (
>   `id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL,
>   `city` blob NOT NULL
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
> """)
> cursor.execute(
> "INSERT INTO profiles (id, city) VALUES (%(id)s, %(city)s)",
> {
> 'id': uuid.uuid4().hex,
> 'city': pymysql.Binary(
> 
> b'z\xf9\x87jS?\xd4i\xa5\xa3\r\xa7\x1e\xed\x16\xe0\xb5\x05R\xa4\xec\x16\x8f\x06\xb5\xea+\xaf<\x00\\\x94I9A\xe0\x82\xa7\x13\x0c\x8c'
> )
> }
> )
>
> when using PyMySQL 0.8.0 (not 0.7.1) you then get a warning
>
> Warning: (1300, "Invalid utf8mb4 character string: 'F9876A'").
>
>
> So, Oracle upstream clearly is never going to fix this if you look at
> the typically dismal discussion at [1].   I poked the PyMySQL project
> at [2] to see what we can do.   Long term is that SQLAlchemy will add
> the special "_binary" prefix to binary-bound parameter tokens to avoid
> the warning, however right now PyMySQL supports a flag "binary_prefix"
> that will do it for us on the driver side.
>
> For Openstack, i need to know if we are in fact passing binary data to
> databases in some project or another.   What we can do is add the
> supply of this flag to oslo.db so that it is present automatically for
> the PyMySQL driver, as well as checking the PyMySQL version for
> compatibility.
>
> If folks are seeing this warning already or are using BLOB / binary
> columns in their project please ping me and we will get this added to
> oslo.db.

__
OpenStack Development Mailing 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] [First Contact][SIG] [PTG] Summary of Discussions

[Petr Kovar]

On Wed, 14 Mar 2018 10:38:37 -0500
Jay S Bryant  wrote:

> 
> 
> On 3/14/2018 10:04 AM, Petr Kovar wrote:
> > On Tue, 13 Mar 2018 18:57:24 -0500
> > Jay S Bryant  wrote:
> >
> >> Amy,
> >>
> >> The top level page for projects is referenced under documentation from
> >> here:  https://docs.openstack.org/queens/projects.html
> >>
> >> So, I think we have that one covered for people who are just looking for
> >> the top level documentation.
> > Yes, we have that covered. Just to clarify this a bit further, we also have
> > project lists like https://docs.openstack.org/queens/install/,
> > https://docs.openstack.org/queens/admin/ and
> > https://docs.openstack.org/queens/configuration/, what's missing is
> > https://docs.openstack.org/queens/contributor/.
> >
> > Cheers,
> > pk
> >
> Petr,
> 
> Do we need a contributor link per-release?  I thought in past 
> discussions that the contributor info should always go to latest and 
> that was why this is slightly different.

Right, that's a good point! I guess we should really just have
https://docs.openstack.org/latest/contributor/ then, perhaps
https://docs.openstack.org/contributor/ would be even better (with a
redirect). This means we need to treat templates for contributor project
docs as a special case and just point to /latest/contributor from all
release-specific docs.o.o landing pages.

Cheers,
pk


> >> On 3/13/2018 3:02 PM, Amy Marrich wrote:
> >>> I think if we're going to have that go to the development contributors
> >>> section (which makes sense) maybe we should also have ways of getting
> >>> to the deployment and admin docs as well?
> >>>
> >>> Amy (spotz)
> >>>
> >>> On Tue, Mar 13, 2018 at 2:55 PM, Jay S Bryant  >>> > wrote:
> >>>
> >>>
> >>>
> >>>  On 3/13/2018 1:38 PM, Petr Kovar wrote:
> >>>
> >>>  On Thu, 8 Mar 2018 12:54:06 -0600
> >>>  Jay S Bryant  >>>  > wrote:
> >>>
> >>>  Good overview.  Thank you!
> >>>
> >>>  One additional goal I want to mention on the list, for
> >>>  awareness, is the
> >>>  fact that we would like to eventually get some consistency
> >>>  to the pages
> >>>  that the 'Contributor Guide' lands on for each of the
> >>>  projects.  Needs
> >>>  to be a page that is friendly to new contributors, makes
> >>>  it easy to
> >>>  learn about the project and is not overwhelming.
> >>>
> >>>  What exactly that looks like isn't defined yet but I have
> >>>  talked to
> >>>  Manila about this.  They were interested in working
> >>>  together on this.
> >>>  Cinder and Manila will work together to get something
> >>>  consistent put
> >>>  together and then we can work on spreading that to other
> >>>  projects once
> >>>  we have agreement from the SIG that the approach is 
> >>> agreeable.
> >>>
> >>>  This is a good cross-project goal, I think. We discussed a
> >>>  similar approach
> >>>  in the docs room wrt providing templates to project teams that
> >>>  they can
> >>>  use to design their landing pages for admin, user,
> >>>  configuration docs; that
> >>>  would also include the main index page for project docs.
> >>>
> >>>  As for the project-specific contributor guides,
> >>>  https://docs.openstack.org/doc-contrib-guide/project-guides.html
> >>>  
> >>> 
> >>>  specifies
> >>>  that any contributor content should go to
> >>>  doc/source/contributor/. This will
> >>>  allow us to use templates to generate lists of links,
> >>>  similarly to what
> >>>  we do for other content areas.
> >>>
> >>>  Cheers,
> >>>  pk
> >>>
> >>>
> >>>  
> >>> __
> >>>  OpenStack Development Mailing List (not for usage questions)
> >>>  Unsubscribe:
> >>>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>>  
> >>> 
> >>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>  
> >>> 
> >>>
> >>>  Petr,
> >>>
> >>>  Good point.  I was trying to think of how to make a better landing
> >>>  page for new contributors and you may have hit on the answer.
> >>>  RIght now when you click through from  here:
> >>>  https://www.openstack.org/community
> >>>   You land at the top level
> 

Re: [openstack-dev] [First Contact][SIG] [PTG] Summary of Discussions

[Doug Hellmann]

Excerpts from Jay S Bryant's message of 2018-03-14 10:38:37 -0500:
> 
> On 3/14/2018 10:04 AM, Petr Kovar wrote:
> > On Tue, 13 Mar 2018 18:57:24 -0500
> > Jay S Bryant  wrote:
> >
> >> Amy,
> >>
> >> The top level page for projects is referenced under documentation from
> >> here:  https://docs.openstack.org/queens/projects.html
> >>
> >> So, I think we have that one covered for people who are just looking for
> >> the top level documentation.
> > Yes, we have that covered. Just to clarify this a bit further, we also have
> > project lists like https://docs.openstack.org/queens/install/,
> > https://docs.openstack.org/queens/admin/ and
> > https://docs.openstack.org/queens/configuration/, what's missing is
> > https://docs.openstack.org/queens/contributor/.
> >
> > Cheers,
> > pk
> >
> Petr,
> 
> Do we need a contributor link per-release?  I thought in past 
> discussions that the contributor info should always go to latest and 
> that was why this is slightly different.
> 
> Jay

We can have a per-series page that lists all projects and links to their
"latest" contributor doc page.

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] [oslo.db] upcoming warnings in MySQL 5.6, 5.7 for BLOB columns

[Michael Bayer]

hey all -

Just looking to see if we think this will impact openstack.  MySQL 5.6
and 5.7, but not yet MariaDB, now emits an erroneous warning when you
try to send a binary value to the database, because it sees the client
connection is supposed to use the utf8 or utf8mb4 charsets, assumes
all data must be in that charset, then warns because the binary data
does not necessarily conform to utf8 (which it has no need to, it's
binary).

Sounds weird, right, to make it easier the demo looks just like this:

import pymysql
import uuid

conn = pymysql.connect(
user="scott", passwd="tiger", host="mysql56",
db="test", charset="utf8mb4")
cursor = conn.cursor()
cursor.execute("""
CREATE TABLE IF NOT EXISTS `profiles` (
  `id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL,
  `city` blob NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
""")
cursor.execute(
"INSERT INTO profiles (id, city) VALUES (%(id)s, %(city)s)",
{
'id': uuid.uuid4().hex,
'city': pymysql.Binary(

b'z\xf9\x87jS?\xd4i\xa5\xa3\r\xa7\x1e\xed\x16\xe0\xb5\x05R\xa4\xec\x16\x8f\x06\xb5\xea+\xaf<\x00\\\x94I9A\xe0\x82\xa7\x13\x0c\x8c'
)
}
)

when using PyMySQL 0.8.0 (not 0.7.1) you then get a warning

Warning: (1300, "Invalid utf8mb4 character string: 'F9876A'").


So, Oracle upstream clearly is never going to fix this if you look at
the typically dismal discussion at [1].   I poked the PyMySQL project
at [2] to see what we can do.   Long term is that SQLAlchemy will add
the special "_binary" prefix to binary-bound parameter tokens to avoid
the warning, however right now PyMySQL supports a flag "binary_prefix"
that will do it for us on the driver side.

For Openstack, i need to know if we are in fact passing binary data to
databases in some project or another.   What we can do is add the
supply of this flag to oslo.db so that it is present automatically for
the PyMySQL driver, as well as checking the PyMySQL version for
compatibility.

If folks are seeing this warning already or are using BLOB / binary
columns in their project please ping me and we will get this added to
oslo.db.

__
OpenStack Development Mailing 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] [Openstack-operators] [nova] about rebuild instance booted from volume

[Tomáš Vondra]

Hi!
I say delete! Delete them all!
Really, it's called delete_on_termination and should be ignored on Rebuild.
We have a VPS service implemented on top of OpenStack and do throw the old 
contents away on Rebuild. When the user has the Backup service paid, they can 
restore a snapshot. Backup is implemented as volume snapshot, then clone 
volume, then upload to image (glance is on a different disk array).

I also sometimes multi-attach a volume manually to a service node and just dd 
an image onto it. If it was to be implemented this way, then there would be no 
deleting a volume with delete_on_termination, just overwriting. But the effect 
is the same.

IMHO you can have snapshots of volumes that have been deleted. Just some 
backends like our 3PAR don't allow it, but it's not disallowed in the API 
contract.
Tomas from Homeatcloud

-Original Message-
From: Saverio Proto [mailto:ziopr...@gmail.com] 
Sent: Wednesday, March 14, 2018 3:19 PM
To: Tim Bell; Matt Riedemann
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [nova] about rebuild 
instance booted from volume

My idea is that if delete_on_termination flag is set to False the Volume should 
never be deleted by Nova.

my 2 cents

Saverio

2018-03-14 15:10 GMT+01:00 Tim Bell :
> Matt,
>
> To add another scenario and make things even more difficult (sorry (), if the 
> original volume has snapshots, I don't think you can delete it.
>
> Tim
>
>
> -Original Message-
> From: Matt Riedemann 
> Reply-To: "OpenStack Development Mailing List (not for usage 
> questions)" 
> Date: Wednesday, 14 March 2018 at 14:55
> To: "openstack-dev@lists.openstack.org" 
> , openstack-operators 
> 
> Subject: Re: [openstack-dev] [nova] about rebuild instance booted from 
> volume
>
> On 3/14/2018 3:42 AM, 李杰 wrote:
> >
> >  This is the spec about  rebuild a instance booted from
> > volume.In the spec,there is a
> >question about if we should delete the old root_volume.Anyone who
> > is interested in
> >booted from volume can help to review this. Any suggestion is
> > welcome.Thank you!
> >The link is here.
> >Re:the rebuild spec:https://review.openstack.org/#/c/532407/
>
> Copying the operators list and giving some more context.
>
> This spec is proposing to add support for rebuild with a new image for
> volume-backed servers, which today is just a 400 failure in the API
> since the compute doesn't support that scenario.
>
> With the proposed solution, the backing root volume would be deleted and
> a new volume would be created from the new image, similar to how boot
> from volume works.
>
> The question raised in the spec is whether or not nova should delete the
> root volume even if its delete_on_termination flag is set to False. The
> semantics get a bit weird here since that flag was not meant for this
> scenario, it's meant to be used when deleting the server to which the
> volume is attached. Rebuilding a server is not deleting it, but we would
> need to replace the root volume, so what do we do with the volume we're
> replacing?
>
> Do we say that delete_on_termination only applies to deleting a server
> and not rebuild and therefore nova can delete the root volume during a
> rebuild?
>
> If we don't delete the volume during rebuild, we could end up leaving a
> lot of volumes lying around that the user then has to clean up,
> otherwise they'll eventually go over quota.
>
> We need user (and operator) feedback on this issue and what they would
> expect to happen.
>
> --
>
> 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
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operator
> s

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


__
OpenStack Development Mailing 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] [First Contact][SIG] [PTG] Summary of Discussions

[Jay S Bryant]

On 3/14/2018 10:04 AM, Petr Kovar wrote:

On Tue, 13 Mar 2018 18:57:24 -0500
Jay S Bryant  wrote:


Amy,

The top level page for projects is referenced under documentation from
here:  https://docs.openstack.org/queens/projects.html

So, I think we have that one covered for people who are just looking for
the top level documentation.

Yes, we have that covered. Just to clarify this a bit further, we also have
project lists like https://docs.openstack.org/queens/install/,
https://docs.openstack.org/queens/admin/ and
https://docs.openstack.org/queens/configuration/, what's missing is
https://docs.openstack.org/queens/contributor/.

Cheers,
pk


Petr,

Do we need a contributor link per-release?  I thought in past 
discussions that the contributor info should always go to latest and 
that was why this is slightly different.


Jay



On 3/13/2018 3:02 PM, Amy Marrich wrote:

I think if we're going to have that go to the development contributors
section (which makes sense) maybe we should also have ways of getting
to the deployment and admin docs as well?

Amy (spotz)

On Tue, Mar 13, 2018 at 2:55 PM, Jay S Bryant > wrote:



 On 3/13/2018 1:38 PM, Petr Kovar wrote:

 On Thu, 8 Mar 2018 12:54:06 -0600
 Jay S Bryant > wrote:

 Good overview.  Thank you!

 One additional goal I want to mention on the list, for
 awareness, is the
 fact that we would like to eventually get some consistency
 to the pages
 that the 'Contributor Guide' lands on for each of the
 projects.  Needs
 to be a page that is friendly to new contributors, makes
 it easy to
 learn about the project and is not overwhelming.

 What exactly that looks like isn't defined yet but I have
 talked to
 Manila about this.  They were interested in working
 together on this.
 Cinder and Manila will work together to get something
 consistent put
 together and then we can work on spreading that to other
 projects once
 we have agreement from the SIG that the approach is agreeable.

 This is a good cross-project goal, I think. We discussed a
 similar approach
 in the docs room wrt providing templates to project teams that
 they can
 use to design their landing pages for admin, user,
 configuration docs; that
 would also include the main index page for project docs.

 As for the project-specific contributor guides,
 https://docs.openstack.org/doc-contrib-guide/project-guides.html
 
 specifies
 that any contributor content should go to
 doc/source/contributor/. This will
 allow us to use templates to generate lists of links,
 similarly to what
 we do for other content areas.

 Cheers,
 pk


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

 Petr,

 Good point.  I was trying to think of how to make a better landing
 page for new contributors and you may have hit on the answer.
 RIght now when you click through from  here:
 https://www.openstack.org/community
  You land at the top level
 Cinder documentation page which is incredibly overwhelming for a
 new person: https://docs.openstack.org/cinder/latest/
 

 If the new contributor page instead lands here:
 https://docs.openstack.org/cinder/latest/contributor/index.html
 
 It would give me a page to craft for new users looking for
 information to get started.

 Thoughts on this approach?

 Kendall and Mike ... Does the above approach make sense?

 Jay



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

Re: [openstack-dev] [nova] about rebuild instance booted from volume

[Matthew Booth]

On 14 March 2018 at 13:46, Matt Riedemann  wrote:

> On 3/14/2018 3:42 AM, 李杰 wrote:
>
>>
>>  This is the spec about  rebuild a instance booted from
>> volume.In the spec,there is a
>>question about if we should delete the old root_volume.Anyone who
>> is interested in
>>booted from volume can help to review this. Any suggestion is
>> welcome.Thank you!
>>The link is here.
>>Re:the rebuild spec:https://review.openstack.org/#/c/532407/
>>
>
> Copying the operators list and giving some more context.
>
> This spec is proposing to add support for rebuild with a new image for
> volume-backed servers, which today is just a 400 failure in the API since
> the compute doesn't support that scenario.
>
> With the proposed solution, the backing root volume would be deleted and a
> new volume would be created from the new image, similar to how boot from
> volume works.
>
> The question raised in the spec is whether or not nova should delete the
> root volume even if its delete_on_termination flag is set to False. The
> semantics get a bit weird here since that flag was not meant for this
> scenario, it's meant to be used when deleting the server to which the
> volume is attached. Rebuilding a server is not deleting it, but we would
> need to replace the root volume, so what do we do with the volume we're
> replacing?
>
> Do we say that delete_on_termination only applies to deleting a server and
> not rebuild and therefore nova can delete the root volume during a rebuild?
>
> If we don't delete the volume during rebuild, we could end up leaving a
> lot of volumes lying around that the user then has to clean up, otherwise
> they'll eventually go over quota.
>
> We need user (and operator) feedback on this issue and what they would
> expect to happen.
>

My 2c was to overwrite, not delete the volume[1]. I believe this preserves
both sets of semantics: the server is rebuilt, and the volume is not
deleted. The user will still lose their data, of course, but that's implied
by the rebuild they explicitly requested. The volume id will remain the
same.

[1] I suspect this would require new functionality in cinder to
re-initialize from image.

Matt
-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

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

[openstack-dev] [sahara][all] Outcomes of Sahara Rocky virtual PTG session

[Jeremy Freudberg]

Hi again all,

As promised, the outcomes of our recent virtual PTG session are made
public. Please view the Etherpad containing those outcomes here:
https://etherpad.openstack.org/p/sahara-rocky-VIRTUAL-ptg

(The Dublin outcomes are on this Etherpad:
https://etherpad.openstack.org/p/sahara-rocky-ptg )

Thanks to all who participated. I do think that it was a productive
enough session that we do not need to schedule another one. If,
however, someone has further points to raise, please let the team
know.

Looking forward to an excellent cycle,
Jeremy

__
OpenStack Development Mailing 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] [First Contact][SIG] [PTG] Summary of Discussions

[Petr Kovar]

On Tue, 13 Mar 2018 18:57:24 -0500
Jay S Bryant  wrote:

> Amy,
> 
> The top level page for projects is referenced under documentation from 
> here:  https://docs.openstack.org/queens/projects.html
> 
> So, I think we have that one covered for people who are just looking for 
> the top level documentation.

Yes, we have that covered. Just to clarify this a bit further, we also have
project lists like https://docs.openstack.org/queens/install/,
https://docs.openstack.org/queens/admin/ and
https://docs.openstack.org/queens/configuration/, what's missing is
https://docs.openstack.org/queens/contributor/.

Cheers,
pk



> On 3/13/2018 3:02 PM, Amy Marrich wrote:
> > I think if we're going to have that go to the development contributors 
> > section (which makes sense) maybe we should also have ways of getting 
> > to the deployment and admin docs as well?
> >
> > Amy (spotz)
> >
> > On Tue, Mar 13, 2018 at 2:55 PM, Jay S Bryant  > > wrote:
> >
> >
> >
> > On 3/13/2018 1:38 PM, Petr Kovar wrote:
> >
> > On Thu, 8 Mar 2018 12:54:06 -0600
> > Jay S Bryant  > > wrote:
> >
> > Good overview.  Thank you!
> >
> > One additional goal I want to mention on the list, for
> > awareness, is the
> > fact that we would like to eventually get some consistency
> > to the pages
> > that the 'Contributor Guide' lands on for each of the
> > projects.  Needs
> > to be a page that is friendly to new contributors, makes
> > it easy to
> > learn about the project and is not overwhelming.
> >
> > What exactly that looks like isn't defined yet but I have
> > talked to
> > Manila about this.  They were interested in working
> > together on this.
> > Cinder and Manila will work together to get something
> > consistent put
> > together and then we can work on spreading that to other
> > projects once
> > we have agreement from the SIG that the approach is agreeable.
> >
> > This is a good cross-project goal, I think. We discussed a
> > similar approach
> > in the docs room wrt providing templates to project teams that
> > they can
> > use to design their landing pages for admin, user,
> > configuration docs; that
> > would also include the main index page for project docs.
> >
> > As for the project-specific contributor guides,
> > https://docs.openstack.org/doc-contrib-guide/project-guides.html
> > 
> > specifies
> > that any contributor content should go to
> > doc/source/contributor/. This will
> > allow us to use templates to generate lists of links,
> > similarly to what
> > we do for other content areas.
> >
> > Cheers,
> > pk
> >
> >
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 
> > 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> >
> > Petr,
> >
> > Good point.  I was trying to think of how to make a better landing
> > page for new contributors and you may have hit on the answer. 
> > RIght now when you click through from  here:
> > https://www.openstack.org/community
> >  You land at the top level
> > Cinder documentation page which is incredibly overwhelming for a
> > new person: https://docs.openstack.org/cinder/latest/
> > 
> >
> > If the new contributor page instead lands here:
> > https://docs.openstack.org/cinder/latest/contributor/index.html
> > 
> > It would give me a page to craft for new users looking for
> > information to get started.
> >
> > Thoughts on this approach?
> >
> > Kendall and Mike ... Does the above approach make sense?
> >
> > Jay
> >
> >
> >
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 
> > 

[openstack-dev] [reno] moved to storyboard

[Doug Hellmann]

The bug tracker for reno has moved to storyboard:
https://storyboard.openstack.org/#!/project/933

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] [nova] about rebuild instance booted from volume

[Blair Bethwaite]

Please do not default to deleting it, otherwise someone will eventually be
back here asking why an irate user has just lost data. The better scenario
is that the rebuild will fail (early - before impact to the running
instance) with a quota error.

Cheers,

On Thu., 15 Mar. 2018, 00:46 Matt Riedemann,  wrote:

> On 3/14/2018 3:42 AM, 李杰 wrote:
> >
> >  This is the spec about  rebuild a instance booted from
> > volume.In the spec,there is a
> >question about if we should delete the old root_volume.Anyone who
> > is interested in
> >booted from volume can help to review this. Any suggestion is
> > welcome.Thank you!
> >The link is here.
> >Re:the rebuild spec:https://review.openstack.org/#/c/532407/
>
> Copying the operators list and giving some more context.
>
> This spec is proposing to add support for rebuild with a new image for
> volume-backed servers, which today is just a 400 failure in the API
> since the compute doesn't support that scenario.
>
> With the proposed solution, the backing root volume would be deleted and
> a new volume would be created from the new image, similar to how boot
> from volume works.
>
> The question raised in the spec is whether or not nova should delete the
> root volume even if its delete_on_termination flag is set to False. The
> semantics get a bit weird here since that flag was not meant for this
> scenario, it's meant to be used when deleting the server to which the
> volume is attached. Rebuilding a server is not deleting it, but we would
> need to replace the root volume, so what do we do with the volume we're
> replacing?
>
> Do we say that delete_on_termination only applies to deleting a server
> and not rebuild and therefore nova can delete the root volume during a
> rebuild?
>
> If we don't delete the volume during rebuild, we could end up leaving a
> lot of volumes lying around that the user then has to clean up,
> otherwise they'll eventually go over quota.
>
> We need user (and operator) feedback on this issue and what they would
> expect to happen.
>
> --
>
> 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
>
__
OpenStack Development Mailing 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] about rebuild instance booted from volume

[Jay S Bryant]

On 3/14/2018 9:10 AM, Tim Bell wrote:

Matt,

To add another scenario and make things even more difficult (sorry (), if the 
original volume has snapshots, I don't think you can delete it.

Tim

Tim,

You are correct.  You can't delete volumes with snapshots.

Jay




-Original Message-
From: Matt Riedemann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 14 March 2018 at 14:55
To: "openstack-dev@lists.openstack.org" , 
openstack-operators 
Subject: Re: [openstack-dev] [nova] about rebuild instance booted from volume

 On 3/14/2018 3:42 AM, 李杰 wrote:
 >
 >  This is the spec about  rebuild a instance booted from
 > volume.In the spec,there is a
 >question about if we should delete the old root_volume.Anyone who
 > is interested in
 >booted from volume can help to review this. Any suggestion is
 > welcome.Thank you!
 >The link is here.
 >Re:the rebuild spec:https://review.openstack.org/#/c/532407/
 
 Copying the operators list and giving some more context.
 
 This spec is proposing to add support for rebuild with a new image for

 volume-backed servers, which today is just a 400 failure in the API
 since the compute doesn't support that scenario.
 
 With the proposed solution, the backing root volume would be deleted and

 a new volume would be created from the new image, similar to how boot
 from volume works.
 
 The question raised in the spec is whether or not nova should delete the

 root volume even if its delete_on_termination flag is set to False. The
 semantics get a bit weird here since that flag was not meant for this
 scenario, it's meant to be used when deleting the server to which the
 volume is attached. Rebuilding a server is not deleting it, but we would
 need to replace the root volume, so what do we do with the volume we're
 replacing?
 
 Do we say that delete_on_termination only applies to deleting a server

 and not rebuild and therefore nova can delete the root volume during a
 rebuild?
 
 If we don't delete the volume during rebuild, we could end up leaving a

 lot of volumes lying around that the user then has to clean up,
 otherwise they'll eventually go over quota.
 
 We need user (and operator) feedback on this issue and what they would

 expect to happen.
 
 --
 
 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
 


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



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

Re: [openstack-dev] [nova] about rebuild instance booted from volume

[Tim Bell]

Matt,

To add another scenario and make things even more difficult (sorry (), if the 
original volume has snapshots, I don't think you can delete it.

Tim


-Original Message-
From: Matt Riedemann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 14 March 2018 at 14:55
To: "openstack-dev@lists.openstack.org" , 
openstack-operators 
Subject: Re: [openstack-dev] [nova] about rebuild instance booted from volume

On 3/14/2018 3:42 AM, 李杰 wrote:
> 
>  This is the spec about  rebuild a instance booted from 
> volume.In the spec,there is a
>question about if we should delete the old root_volume.Anyone who 
> is interested in
>booted from volume can help to review this. Any suggestion is 
> welcome.Thank you!
>The link is here.
>Re:the rebuild spec:https://review.openstack.org/#/c/532407/

Copying the operators list and giving some more context.

This spec is proposing to add support for rebuild with a new image for 
volume-backed servers, which today is just a 400 failure in the API 
since the compute doesn't support that scenario.

With the proposed solution, the backing root volume would be deleted and 
a new volume would be created from the new image, similar to how boot 
from volume works.

The question raised in the spec is whether or not nova should delete the 
root volume even if its delete_on_termination flag is set to False. The 
semantics get a bit weird here since that flag was not meant for this 
scenario, it's meant to be used when deleting the server to which the 
volume is attached. Rebuilding a server is not deleting it, but we would 
need to replace the root volume, so what do we do with the volume we're 
replacing?

Do we say that delete_on_termination only applies to deleting a server 
and not rebuild and therefore nova can delete the root volume during a 
rebuild?

If we don't delete the volume during rebuild, we could end up leaving a 
lot of volumes lying around that the user then has to clean up, 
otherwise they'll eventually go over quota.

We need user (and operator) feedback on this issue and what they would 
expect to happen.

-- 

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


__
OpenStack Development Mailing 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] about rebuild instance booted from volume

[Matt Riedemann]

On 3/14/2018 3:42 AM, 李杰 wrote:


             This is the spec about  rebuild a instance booted from 
volume.In the spec,there is a
       question about if we should delete the old root_volume.Anyone who 
is interested in
       booted from volume can help to review this. Any suggestion is 
welcome.Thank you!

       The link is here.
       Re:the rebuild spec:https://review.openstack.org/#/c/532407/


Copying the operators list and giving some more context.

This spec is proposing to add support for rebuild with a new image for 
volume-backed servers, which today is just a 400 failure in the API 
since the compute doesn't support that scenario.


With the proposed solution, the backing root volume would be deleted and 
a new volume would be created from the new image, similar to how boot 
from volume works.


The question raised in the spec is whether or not nova should delete the 
root volume even if its delete_on_termination flag is set to False. The 
semantics get a bit weird here since that flag was not meant for this 
scenario, it's meant to be used when deleting the server to which the 
volume is attached. Rebuilding a server is not deleting it, but we would 
need to replace the root volume, so what do we do with the volume we're 
replacing?


Do we say that delete_on_termination only applies to deleting a server 
and not rebuild and therefore nova can delete the root volume during a 
rebuild?


If we don't delete the volume during rebuild, we could end up leaving a 
lot of volumes lying around that the user then has to clean up, 
otherwise they'll eventually go over quota.


We need user (and operator) feedback on this issue and what they would 
expect to happen.


--

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] Blueprints for Rocky

[Andy Smith]

Hi Alex,

The tripleo-messaging blueprint is pending approval:
https://blueprints.launchpad.net/tripleo/+spec/tripleo-messaging

Good progress has been made and working towards being ready for Rocky-1.

Thanks,
Andy


On Wed, Mar 14, 2018 at 8:11 AM, Dmitry Tantsur  wrote:

> Hi Alex,
>
> I have two small ironic-related blueprints pending approval:
> https://blueprints.launchpad.net/tripleo/+spec/ironic-rescue
> https://blueprints.launchpad.net/tripleo/+spec/networking-generic-switch
>
> and one larger:
> https://blueprints.launchpad.net/tripleo/+spec/ironic-inspector-overcloud
>
> Could you please check them?
>
> I would also like to talk about possibility to enable cleaning by default
> in the undercloud, but I guess it deserves a separate thread.
>
>
> On 03/13/2018 02:58 PM, Alex Schultz wrote:
>
>> Hey everyone,
>>
>> So we currently have 63 blueprints for currently targeted for
>> Rocky[0].  Please make sure that any blueprints you are interested in
>> delivering have an assignee set and have been approved.  I would like
>> to have the ones we plan on delivering for Rocky to be updated by
>> April 3, 2018.  Any blueprints that have not been updated will be
>> moved out to the next cycle after this date.
>>
>> Thanks,
>> -Alex
>>
>> [0] https://blueprints.launchpad.net/tripleo/rocky
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [FEMDC] Wed. 14 Mar. - IRC Meeting 15:00 UTC

[avankemp]

Dear all, 

A gentle reminder for our today meeting at 15:00 UTC 

A draft of the agenda is available at line 260 you are very welcome to add any 
item.
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2018 


Best,

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

Re: [openstack-dev] [keystone] [oslo] new unified limit library

[Doug Hellmann]

Excerpts from Lance Bragstad's message of 2018-03-12 11:45:28 -0500:
> I missed the document describing the process for this sort of thing [0].
> So I'm back tracking a bit to go through a more formal process.
> 
> [0]
> http://specs.openstack.org/openstack/oslo-specs/specs/policy/new-libraries.html
> 
> # Proposed new library oslo.limit
> 
> This is a proposal to create a new library dedicated to enabling more
> consistent quota and limit enforcement across OpenStack.
> 
> ## Proposed library mission
> 
> Enforcing quotas and limits across OpenStack has traditionally been a
> tough problem to solve. Determining enforcement requires quota knowledge
> from the service along with information about the project owning the
> resource. Up until the Queens release, quota calculation and enforcement
> has been left to the services to implement, forcing them to understand
> complexities of keystone project structure. During the Pike and Queens
> PTG, there were several productive discussions towards redesigning the
> current approach to quota enforcement. Because keystone is the authority
> of project structure, it makes sense to allow keystone to hold the
> association between a resource limit and a project. This means services
> still need to calculate quota and usage, but the problem should be
> easier for services to implement since developers shouldn't need to
> re-implement possible hierarchies of projects and their associated
> limits. Instead, we can offload some of that work to a common library
> for services to consume that handles enforcing quota calculation based
> on limits associated to projects in keystone. This proposal is to have a
> new library called oslo.limit that fills that need.
> 
> ## Consuming projects
> 
> The services consuming this work will be any service that currently
> implements a quota system, or plans to implement one. Since keystone
> already supports unified limits and association of limits to projects,
> the implementation for consuming projects is easier. instead of having
> to re-write that implementation, developers need to ensure quota
> calculation to passed to the oslo.limit library somewhere in the API's
> validation layer. The pattern described here is very similar to the
> pattern currently used by services that leverage oslo.policy for
> authorization decisions.
> 
> ## Alternative libraries
> 
> It looks like there was an existing library that attempted to solve some
> of these problems, called delimiter [1]. It looks like delimiter could
> be used to talk to keystone about quota enforcement, where as the
> existing approach with oslo.limit would be to use keystone directly.
> Someone more familiar with the library (harlowja?) can probably shed
> more light on it's intended uses (I couldn't find much documentation),
> but the presentation linked in a previous note was helpful.
> 
> [1] https://github.com/openstack/delimiter
> 
> ## Proposed adoption model/plan
> 
> The unified limit API [2] in keystone is currently marked as
> experimental, but the keystone team is actively collecting and
> addressing feedback that will result in stabilizing the API.
> Stabilization changes that effect the oslo.limit library will also be
> addressed before version 1.0.0 is released. From there, we can look to
> incorporate the library into various services that either have an
> existing quota implementation, or services that have a quota requirement
> but no implementation.
> 
> This should help us refine the interfaces between services and
> oslo.limit, while providing a facade to handle complexities of project
> hierarchies. This should enable adoption by simplifying the process and
> making it easier for quota to be implemented in a consistent way across
> services.
> 
> [2]
> https://docs.openstack.org/keystone/latest/admin/identity-unified-limits.html
> 
> ## Reviewer activity
> 
> At first thought, it makes sense to model the reviewer structure after
> the oslo.policy library, where the core team consists of people not only
> interested in limits and quota, but also people familiar with the
> keystone implementation of the unified limits API.
> 
> ## Implementation
> 
> ### Primary Authors:
> 
>   Lance Bragstad (lbrags...@gmail.com) lbragstad
>   You?
> 
> ### Other contributors:
> 
>   You?
> 
> ## Work Items
> 
> * Create a new library called oslo.limit
> * Create a core group for the project
> * Define the minimum we need to enforce quota calculations in oslo.limit
> * Propose an implementation that allows services to test out quota
> enforcement via unified limits
> 
> ## References
> 
> Rocky PTG Etherpad for unified limits:
> https://etherpad.openstack.org/p/unified-limits-rocky-ptg
> 
> ## Revision History
> 
> Introduced in Rocky
> 
> On 03/07/2018 11:55 PM, Joshua Harlow wrote:
> > So the following was a prior effort:
> >
> > https://github.com/openstack/delimiter
> >
> > Maybe just continue down the path of that and/or take that whole repo
> > over and iterate (or 

Re: [openstack-dev] Poll: S Release Naming

[Thierry Carrez]

Dmitry Tantsur wrote:
> I suspect that S-Bahn may be a protected (copyright, trademark,
> whatever) name. Did you have a chance to check it?

If you look at the release naming process, trademark vetting is done
once the ranking of preferred names is established (to limit the cost of
name vetting):

https://governance.openstack.org/tc/reference/release-naming.html

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] Poll: S Release Naming

[Jeremy Freudberg]

My apologies... Frank paints a more accurate picture of the trademark
situation than I have done.

Let's defer to Frank on this one.


On Mar 14, 2018 8:33 AM, "Frank Kloeker"  wrote:

Hi,

it's critical, I would say. They canceled the registration just today [1],
but there are still copyrights for name parts like  "S-Bahn Halleipzig". I
would remove it from the voting list to prevent us from trouble. S-Bahn is
not really a location in Berlin. If it does, S-Bahn is broken ;-)

kind regards

Frank (from Berlin)

[1] https://register.dpma.de/DPMAregister/marke/registerHABM?AKZ=007392194


Am 2018-03-14 13:14, schrieb Jeremy Freudberg:

> Hi Dmitry,
>
> According to Wikipedia [0] the trademark was removed. The citation [1]
> is actually inaccurate; it was not the final ruling. Regardless [2]
> seems to reflect the final result which is that the trademark is
> cancelled.
>
> Hope this helps.
>
> [0]
> https://en.wikipedia.org/wiki/S-train#Germany,_Austria_and_Switzerland
> (end of paragraph
> [1]
> http://juris.bundespatentgericht.de/cgi-bin/rechtsprechung/
> document.py?Gericht=bpatg=en=Aktuell=23159=
> 1=323=1.pdf
> [2]
> http://www.eurailpress.de/news/bahnbetrieb/single-view/news/
> bundesgerichtshof-db-verliert-marke-s-bahn.html
>
> On Wed, Mar 14, 2018 at 7:50 AM, Dmitry Tantsur 
> wrote:
>
> Hi,
>>
>> I suspect that S-Bahn may be a protected (copyright, trademark,
>> whatever) name. Did you have a chance to check it?
>>
>> On 03/14/2018 12:58 AM, Paul Belanger wrote:
>>
>> Greetings all,
>>>
>>> It is time again to cast your vote for the naming of the S
>>> Release. This time
>>> is little different as we've decided to use a public polling
>>> option over per
>>> user private URLs for voting. This means, everybody should proceed
>>> to use the
>>> following URL to cast their vote:
>>>
>>>
>>>
>>>
>> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3
> fcdf1=8cfdc1f5df5fe4d3
>
>> [1]
>>>
>>>
>>> Because this is a public poll, results will currently be only
>>> viewable by myself
>>> until the poll closes. Once closed, I'll post the URL making the
>>> results
>>> viewable to everybody. This was done to avoid everybody seeing the
>>> results while
>>> the public poll is running.
>>>
>>> The poll will officially end on 2018-03-21 23:59:59[1], and
>>> results will be
>>> posted shortly after.
>>>
>>> [1]
>>>
>>>
>> http://git.openstack.org/cgit/openstack/governance/tree/refe
> rence/release-naming.rst
>
>> [2]
>>>
>>> ---
>>>
>>> According to the Release Naming Process, this poll is to determine
>>> the
>>> community preferences for the name of the R release of OpenStack.
>>> It is
>>> possible that the top choice is not viable for legal reasons, so
>>> the second or
>>> later community preference could wind up being the name.
>>>
>>> Release Name Criteria
>>>
>>> Each release name must start with the letter of the ISO basic
>>> Latin alphabet
>>> following the initial letter of the previous release, starting
>>> with the
>>> initial release of "Austin". After "Z", the next name should start
>>> with
>>> "A" again.
>>>
>>> The name must be composed only of the 26 characters of the ISO
>>> basic Latin
>>> alphabet. Names which can be transliterated into this character
>>> set are also
>>> acceptable.
>>>
>>> The name must refer to the physical or human geography of the
>>> region
>>> encompassing the location of the OpenStack design summit for the
>>> corresponding release. The exact boundaries of the geographic
>>> region under
>>> consideration must be declared before the opening of nominations,
>>> as part of
>>> the initiation of the selection process.
>>>
>>> The name must be a single word with a maximum of 10 characters.
>>> Words that
>>> describe the feature should not be included, so "Foo City" or "Foo
>>> Peak"
>>> would both be eligible as "Foo".
>>>
>>> Names which do not meet these criteria but otherwise sound really
>>> cool
>>> should be added to a separate section of the wiki page and the TC
>>> may make
>>> an exception for one or more of them to be considered in the
>>> Condorcet poll.
>>> The naming official is responsible for presenting the list of
>>> exceptional
>>> names for consideration to the TC before the poll opens.
>>>
>>> Exact Geographic Region
>>>
>>> The Geographic Region from where names for the S release will come
>>> is Berlin
>>>
>>> Proposed Names
>>>
>>> Spree (a river that flows through the Saxony, Brandenburg and
>>> Berlin states of
>>> Germany)
>>>
>>> SBahn (The Berlin S-Bahn is a rapid transit system in and around
>>> Berlin)
>>>
>>> Spandau (One of the twelve boroughs of Berlin)
>>>
>>> Stein (Steinstraße or "Stein Street" in Berlin, can also be
>>> conveniently
>>> abbreviated as )
>>>
>>> Steglitz (a locality in the South Western part of the city)
>>>
>>> Springer (Berlin is headquarters of Axel Springer publishing
>>> house)
>>>
>>> Staaken (a locality within the Spandau borough)
>>>
>>> Schoenholz (A zone in the 

Re: [openstack-dev] Poll: S Release Naming

[Dmitry Tantsur]

On 03/14/2018 01:33 PM, Frank Kloeker wrote:

Hi,

it's critical, I would say. They canceled the registration just today [1], but 
there are still copyrights for name parts like  "S-Bahn Halleipzig". I would 
remove it from the voting list to prevent us from trouble. S-Bahn is not really 
a location in Berlin. If it does, S-Bahn is broken ;-)


And it often is /me looks at S42 schedule :D

Actually, I agree, a means of transport is not quite a location.



kind regards

Frank (from Berlin)

[1] https://register.dpma.de/DPMAregister/marke/registerHABM?AKZ=007392194

Am 2018-03-14 13:14, schrieb Jeremy Freudberg:

Hi Dmitry,

According to Wikipedia [0] the trademark was removed. The citation [1]
is actually inaccurate; it was not the final ruling. Regardless [2]
seems to reflect the final result which is that the trademark is
cancelled.

Hope this helps.

[0]
https://en.wikipedia.org/wiki/S-train#Germany,_Austria_and_Switzerland
(end of paragraph
[1]
http://juris.bundespatentgericht.de/cgi-bin/rechtsprechung/document.py?Gericht=bpatg=en=Aktuell=23159=1=323=1.pdf 


[2]
http://www.eurailpress.de/news/bahnbetrieb/single-view/news/bundesgerichtshof-db-verliert-marke-s-bahn.html 



On Wed, Mar 14, 2018 at 7:50 AM, Dmitry Tantsur 
wrote:


Hi,

I suspect that S-Bahn may be a protected (copyright, trademark,
whatever) name. Did you have a chance to check it?

On 03/14/2018 12:58 AM, Paul Belanger wrote:


Greetings all,

It is time again to cast your vote for the naming of the S
Release. This time
is little different as we've decided to use a public polling
option over per
user private URLs for voting. This means, everybody should proceed
to use the
following URL to cast their vote:





https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3 


[1]

Because this is a public poll, results will currently be only
viewable by myself
until the poll closes. Once closed, I'll post the URL making the
results
viewable to everybody. This was done to avoid everybody seeing the
results while
the public poll is running.

The poll will officially end on 2018-03-21 23:59:59[1], and
results will be
posted shortly after.

[1]



http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst 


[2]
---

According to the Release Naming Process, this poll is to determine
the
community preferences for the name of the R release of OpenStack.
It is
possible that the top choice is not viable for legal reasons, so
the second or
later community preference could wind up being the name.

Release Name Criteria

Each release name must start with the letter of the ISO basic
Latin alphabet
following the initial letter of the previous release, starting
with the
initial release of "Austin". After "Z", the next name should start
with
"A" again.

The name must be composed only of the 26 characters of the ISO
basic Latin
alphabet. Names which can be transliterated into this character
set are also
acceptable.

The name must refer to the physical or human geography of the
region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic
region under
consideration must be declared before the opening of nominations,
as part of
the initiation of the selection process.

The name must be a single word with a maximum of 10 characters.
Words that
describe the feature should not be included, so "Foo City" or "Foo
Peak"
would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really
cool
should be added to a separate section of the wiki page and the TC
may make
an exception for one or more of them to be considered in the
Condorcet poll.
The naming official is responsible for presenting the list of
exceptional
names for consideration to the TC before the poll opens.

Exact Geographic Region

The Geographic Region from where names for the S release will come
is Berlin

Proposed Names

Spree (a river that flows through the Saxony, Brandenburg and
Berlin states of
Germany)

SBahn (The Berlin S-Bahn is a rapid transit system in and around
Berlin)

Spandau (One of the twelve boroughs of Berlin)

Stein (Steinstraße or "Stein Street" in Berlin, can also be
conveniently
abbreviated as )

Steglitz (a locality in the South Western part of the city)

Springer (Berlin is headquarters of Axel Springer publishing
house)

Staaken (a locality within the Spandau borough)

Schoenholz (A zone in the Niederschönhausen district of Berlin)

Shellhaus (A famous office building)

Suedkreuz ("southern cross" - a railway station in
Tempelhof-Schöneberg)

Schiller (A park in the Mitte borough)

Saatwinkel (The name of a super tiny beach, and its surrounding
neighborhood)
(The adjective form, Saatwinkler is also a really cool
bridge but
that form is too long)

Sonne (Sonnenallee is the name of a large street in Berlin
crossing the former
wall, also translates as "sun")

Savigny (Common place in City-West)

Re: [openstack-dev] Poll: S Release Naming

[Frank Kloeker]

Hi,

it's critical, I would say. They canceled the registration just today 
[1], but there are still copyrights for name parts like  "S-Bahn 
Halleipzig". I would remove it from the voting list to prevent us from 
trouble. S-Bahn is not really a location in Berlin. If it does, S-Bahn 
is broken ;-)


kind regards

Frank (from Berlin)

[1] 
https://register.dpma.de/DPMAregister/marke/registerHABM?AKZ=007392194


Am 2018-03-14 13:14, schrieb Jeremy Freudberg:

Hi Dmitry,

According to Wikipedia [0] the trademark was removed. The citation [1]
is actually inaccurate; it was not the final ruling. Regardless [2]
seems to reflect the final result which is that the trademark is
cancelled.

Hope this helps.

[0]
https://en.wikipedia.org/wiki/S-train#Germany,_Austria_and_Switzerland
(end of paragraph
[1]
http://juris.bundespatentgericht.de/cgi-bin/rechtsprechung/document.py?Gericht=bpatg=en=Aktuell=23159=1=323=1.pdf
[2]
http://www.eurailpress.de/news/bahnbetrieb/single-view/news/bundesgerichtshof-db-verliert-marke-s-bahn.html

On Wed, Mar 14, 2018 at 7:50 AM, Dmitry Tantsur 
wrote:


Hi,

I suspect that S-Bahn may be a protected (copyright, trademark,
whatever) name. Did you have a chance to check it?

On 03/14/2018 12:58 AM, Paul Belanger wrote:


Greetings all,

It is time again to cast your vote for the naming of the S
Release. This time
is little different as we've decided to use a public polling
option over per
user private URLs for voting. This means, everybody should proceed
to use the
following URL to cast their vote:






https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3

[1]

Because this is a public poll, results will currently be only
viewable by myself
until the poll closes. Once closed, I'll post the URL making the
results
viewable to everybody. This was done to avoid everybody seeing the
results while
the public poll is running.

The poll will officially end on 2018-03-21 23:59:59[1], and
results will be
posted shortly after.

[1]




http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst

[2]
---

According to the Release Naming Process, this poll is to determine
the
community preferences for the name of the R release of OpenStack.
It is
possible that the top choice is not viable for legal reasons, so
the second or
later community preference could wind up being the name.

Release Name Criteria

Each release name must start with the letter of the ISO basic
Latin alphabet
following the initial letter of the previous release, starting
with the
initial release of "Austin". After "Z", the next name should start
with
"A" again.

The name must be composed only of the 26 characters of the ISO
basic Latin
alphabet. Names which can be transliterated into this character
set are also
acceptable.

The name must refer to the physical or human geography of the
region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic
region under
consideration must be declared before the opening of nominations,
as part of
the initiation of the selection process.

The name must be a single word with a maximum of 10 characters.
Words that
describe the feature should not be included, so "Foo City" or "Foo
Peak"
would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really
cool
should be added to a separate section of the wiki page and the TC
may make
an exception for one or more of them to be considered in the
Condorcet poll.
The naming official is responsible for presenting the list of
exceptional
names for consideration to the TC before the poll opens.

Exact Geographic Region

The Geographic Region from where names for the S release will come
is Berlin

Proposed Names

Spree (a river that flows through the Saxony, Brandenburg and
Berlin states of
Germany)

SBahn (The Berlin S-Bahn is a rapid transit system in and around
Berlin)

Spandau (One of the twelve boroughs of Berlin)

Stein (Steinstraße or "Stein Street" in Berlin, can also be
conveniently
abbreviated as )

Steglitz (a locality in the South Western part of the city)

Springer (Berlin is headquarters of Axel Springer publishing
house)

Staaken (a locality within the Spandau borough)

Schoenholz (A zone in the Niederschönhausen district of Berlin)

Shellhaus (A famous office building)

Suedkreuz ("southern cross" - a railway station in
Tempelhof-Schöneberg)

Schiller (A park in the Mitte borough)

Saatwinkel (The name of a super tiny beach, and its surrounding
neighborhood)
(The adjective form, Saatwinkler is also a really cool
bridge but
that form is too long)

Sonne (Sonnenallee is the name of a large street in Berlin
crossing the former
wall, also translates as "sun")

Savigny (Common place in City-West)

Soorstreet (Street in Berlin restrict Charlottenburg)

Solar (Skybar in Berlin)

See (Seestraße or "See Street" in Berlin)

Thanks,
Paul

[openstack-dev] [kuryr] [os-vif] kuryr-kubernetes gates unblocked

[Michał Dulko]

Hi,

kuryr-kubernetes gates were broken by recent try to switch from
neutron-legacy DevStack to plain neutron [1]. Meanwhile it modified
DevStack jobs we were relying on and introduced us another failure.

Now neutron-legacy change was reverted [2] and fix for the second issue
[3] is getting merged. Once it's in kuryr-kubernetes gates in both
kuryr and os-vif repos should be working again.

I apologize that it took so long, but it was multi-level issue and it
required a lot of debugging from us.

Thanks,
Michal

[1] https://github.com/openstack-dev/devstack/commit/d9c1275c5df55e822a
7df6880a9a1430ab4f24a0
[2] https://github.com/openstack-dev/devstack/com
mit/9f50f541385c929262a2e9c05093881960fe7d8f
[3] https://review.openstac
k.org/#/c/552701/

__
OpenStack Development Mailing 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] Poll: S Release Naming

[Jeremy Freudberg]

Hi Dmitry,

According to Wikipedia [0] the trademark was removed. The citation [1] is
actually inaccurate; it was not the final ruling. Regardless [2] seems to
reflect the final result which is that the trademark is cancelled.

Hope this helps.

[0] https://en.wikipedia.org/wiki/S-train#Germany,_Austria_and_Switzerland
(end of paragraph
[1]
http://juris.bundespatentgericht.de/cgi-bin/rechtsprechung/document.py?Gericht=bpatg=en=Aktuell=23159=1=323=1.pdf
[2]
http://www.eurailpress.de/news/bahnbetrieb/single-view/news/bundesgerichtshof-db-verliert-marke-s-bahn.html

On Wed, Mar 14, 2018 at 7:50 AM, Dmitry Tantsur  wrote:

> Hi,
>
> I suspect that S-Bahn may be a protected (copyright, trademark, whatever)
> name. Did you have a chance to check it?
>
>
> On 03/14/2018 12:58 AM, Paul Belanger wrote:
>
>> Greetings all,
>>
>> It is time again to cast your vote for the naming of the S Release. This
>> time
>> is little different as we've decided to use a public polling option over
>> per
>> user private URLs for voting. This means, everybody should proceed to use
>> the
>> following URL to cast their vote:
>>
>>https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be
>> 3fcdf1=8cfdc1f5df5fe4d3
>>
>> Because this is a public poll, results will currently be only viewable by
>> myself
>> until the poll closes. Once closed, I'll post the URL making the results
>> viewable to everybody. This was done to avoid everybody seeing the
>> results while
>> the public poll is running.
>>
>> The poll will officially end on 2018-03-21 23:59:59[1], and results will
>> be
>> posted shortly after.
>>
>> [1] http://git.openstack.org/cgit/openstack/governance/tree/refe
>> rence/release-naming.rst
>> ---
>>
>> According to the Release Naming Process, this poll is to determine the
>> community preferences for the name of the R release of OpenStack. It is
>> possible that the top choice is not viable for legal reasons, so the
>> second or
>> later community preference could wind up being the name.
>>
>> Release Name Criteria
>>
>> Each release name must start with the letter of the ISO basic Latin
>> alphabet
>> following the initial letter of the previous release, starting with the
>> initial release of "Austin". After "Z", the next name should start with
>> "A" again.
>>
>> The name must be composed only of the 26 characters of the ISO basic Latin
>> alphabet. Names which can be transliterated into this character set are
>> also
>> acceptable.
>>
>> The name must refer to the physical or human geography of the region
>> encompassing the location of the OpenStack design summit for the
>> corresponding release. The exact boundaries of the geographic region under
>> consideration must be declared before the opening of nominations, as part
>> of
>> the initiation of the selection process.
>>
>> The name must be a single word with a maximum of 10 characters. Words that
>> describe the feature should not be included, so "Foo City" or "Foo Peak"
>> would both be eligible as "Foo".
>>
>> Names which do not meet these criteria but otherwise sound really cool
>> should be added to a separate section of the wiki page and the TC may make
>> an exception for one or more of them to be considered in the Condorcet
>> poll.
>> The naming official is responsible for presenting the list of exceptional
>> names for consideration to the TC before the poll opens.
>>
>> Exact Geographic Region
>>
>> The Geographic Region from where names for the S release will come is
>> Berlin
>>
>> Proposed Names
>>
>> Spree (a river that flows through the Saxony, Brandenburg and Berlin
>> states of
>> Germany)
>>
>> SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)
>>
>> Spandau (One of the twelve boroughs of Berlin)
>>
>> Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
>> abbreviated as )
>>
>> Steglitz (a locality in the South Western part of the city)
>>
>> Springer (Berlin is headquarters of Axel Springer publishing house)
>>
>> Staaken (a locality within the Spandau borough)
>>
>> Schoenholz (A zone in the Niederschönhausen district of Berlin)
>>
>> Shellhaus (A famous office building)
>>
>> Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)
>>
>> Schiller (A park in the Mitte borough)
>>
>> Saatwinkel (The name of a super tiny beach, and its surrounding
>> neighborhood)
>> (The adjective form, Saatwinkler is also a really cool bridge
>> but
>> that form is too long)
>>
>> Sonne (Sonnenallee is the name of a large street in Berlin crossing the
>> former
>> wall, also translates as "sun")
>>
>> Savigny (Common place in City-West)
>>
>> Soorstreet (Street in Berlin restrict Charlottenburg)
>>
>> Solar (Skybar in Berlin)
>>
>> See (Seestraße or "See Street" in Berlin)
>>
>> Thanks,
>> Paul
>>
>> 
>> __
>> OpenStack Development Mailing List (not for 

Re: [openstack-dev] [tripleo] Blueprints for Rocky

[Dmitry Tantsur]

Hi Alex,

I have two small ironic-related blueprints pending approval:
https://blueprints.launchpad.net/tripleo/+spec/ironic-rescue
https://blueprints.launchpad.net/tripleo/+spec/networking-generic-switch

and one larger:
https://blueprints.launchpad.net/tripleo/+spec/ironic-inspector-overcloud

Could you please check them?

I would also like to talk about possibility to enable cleaning by default in the 
undercloud, but I guess it deserves a separate thread.


On 03/13/2018 02:58 PM, Alex Schultz wrote:

Hey everyone,

So we currently have 63 blueprints for currently targeted for
Rocky[0].  Please make sure that any blueprints you are interested in
delivering have an assignee set and have been approved.  I would like
to have the ones we plan on delivering for Rocky to be updated by
April 3, 2018.  Any blueprints that have not been updated will be
moved out to the next cycle after this date.

Thanks,
-Alex

[0] https://blueprints.launchpad.net/tripleo/rocky

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




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

Re: [openstack-dev] [tripleo] TLS by default

[Juan Antonio Osorio]

Correct, only public endpoints.

On Wed, Mar 14, 2018 at 1:52 PM, Dmitry Tantsur  wrote:

> Just to clarify: only for public endpoints, right? I don't think e.g.
> ironic-python-agent can talk to self-signed certificates yet.
>
>
> On 03/14/2018 07:03 AM, Juan Antonio Osorio wrote:
>
>> Hello,
>>
>> As part of the proposed changed by the Security Squad [1], we'd like the
>> deployment to use TLS by default.
>>
>> The first target is to get the undercloud to use it, so a patch has been
>> proposed recently [2] [3]. So, just wanted to give a heads up to people.
>>
>> This should be just fine from a quickstart/testing point of view, since
>> we explicitly set the value for autogenerating certificates in the
>> undercloud [4] [5].
>>
>> Note that there are also plans to change these defaults for the
>> containerized undercloud and the overcloud.
>>
>> BR
>>
>> [1] https://etherpad.openstack.org/p/tripleo-security-squad
>> [2] https://review.openstack.org/#/c/552382/
>> [3] https://review.openstack.org/552781
>> [4] https://github.com/openstack/tripleo-quickstart-extras/blob/
>> master/roles/extras-common/defaults/main.yml#L15
>> [5] https://github.com/openstack/tripleo-quickstart-extras/blob/
>> master/roles/undercloud-deploy/templates/undercloud.conf.j2#L117
>> --
>> Juan Antonio Osorio R.
>> e-mail: jaosor...@gmail.com 
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@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] [openstack-ansible] Meetings change (PTG discussion follow-up)

[Jean-Philippe Evrard]

Hello,

We discussed the problem of the miscommunication at the PTG, and we
agreed the focus of the week solved many things for clarity.
I am not sure we need to send a ML summary, if all is recorded in the
meeting each week: people can just browse meetings for this info.

I have no strong opinion about office hours:
- it is more formal than our ad-hoc dicussions (more than necessary?).;
- it helps for timezones: We can have different office hours (US
based/Europe based) for discussing things;
- it can be reported during Tuesday's meeting.

Let's discuss this on the chan and validate next Tuesday I guess :)

Because there were no strong against the meeting time change/format we
should go ahead on the change of the community meetings.
So from now on, until daylight saving applies to Europe, we should
have the meetings on Tuesday at 5PM UTC.

Thanks everyone!



On 6 March 2018 at 16:08, Amy Marrich  wrote:
> JP,
>
> When the Community meeting was moved to once a month there was a lot of
> resulting miscommunication as a result. If a weekly review is going to be
> sent to the mailing list with channel discussions is going to be sent out, I
> think that's a good alternative but the conversations still need to take
> place and as many people involved as possible. What about having office
> hours?
>
> Amy (spotz)
>
> On Tue, Mar 6, 2018 at 9:51 AM, Jean-Philippe Evrard
>  wrote:
>>
>> Hello,
>>
>> During the PTG, we've discussed about changing our meetings.
>> I'd like to have a written evidence in our mailing lists, showing what
>> we discussed, and what we proposed to change. I propose we validate
>> those changes if they get no opposition in the next 7 days (deadline:
>> 13 March).
>>
>> What we discussed was:
>> - Should the meetings be rescheduled, and at what time;
>> - Should the meetings be happening in alternance for US/Europe
>> friendly timezones;
>> - What is the purpose/expected outcome of those meetings;
>> - What is the reason the attendance is low.
>>
>> The summary is the following:
>> - The expected outcome of bug triage is currently (drumroll)
>> actively triaging bugs which produces better deliverables (what a
>> surprise!).
>> - The expected outcome of the community meeting is to discuss about
>> what we actively need to work on together, but we are doing these kind
>> of conversations, ad-hoc, in the channel. So if we summarize things on
>> a regular basis to make sure everyone is aware of the conversations,
>> we should be good.
>> - The timezone friendly things won't impact the attendance positively.
>> - Right now, the Europe meetings can be postponed of one hour, but
>> decision should be re-discussed with daylight saving.
>> - A lot of ppl have meetings at 4PM UTC right now.
>>
>> As such, here is the PTG proposed change:
>> - Moving the bug triage meeting to 5PM UTC until next daylight saving
>> change.
>> - Keep the "Focus of the week" section of the bug triage, to list what
>> we discussed in the week (if more conversations have to happen, they
>> can happen just after the bug triage)
>> - Removing the community meeting.
>>
>> Any opposition there? If we are all okay, I will update our procedures
>> next week.
>>
>> Best regards,
>> JP
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [tripleo] TLS by default

[Dmitry Tantsur]

Just to clarify: only for public endpoints, right? I don't think e.g. 
ironic-python-agent can talk to self-signed certificates yet.


On 03/14/2018 07:03 AM, Juan Antonio Osorio wrote:

Hello,

As part of the proposed changed by the Security Squad [1], we'd like the 
deployment to use TLS by default.


The first target is to get the undercloud to use it, so a patch has been 
proposed recently [2] [3]. So, just wanted to give a heads up to people.


This should be just fine from a quickstart/testing point of view, since we 
explicitly set the value for autogenerating certificates in the undercloud [4] [5].


Note that there are also plans to change these defaults for the containerized 
undercloud and the overcloud.


BR

[1] https://etherpad.openstack.org/p/tripleo-security-squad
[2] https://review.openstack.org/#/c/552382/
[3] https://review.openstack.org/552781
[4] 
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/extras-common/defaults/main.yml#L15
[5] 
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/undercloud-deploy/templates/undercloud.conf.j2#L117

--
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com 



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




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

Re: [openstack-dev] Poll: S Release Naming

[Dmitry Tantsur]

On 03/14/2018 10:05 AM, Thierry Carrez wrote:

Jens Harbott wrote:

2018-03-14 9:21 GMT+01:00 Sławomir Kapłoński :

Hi,

Are You sure this link is good? I just tried it and I got info that "Already 
voted" which isn't true in fact :)


Comparing with previous polls, these should be personalized links that
need to be sent out to each voter individually, so I agree that this
looks like a mistake.


We crashed CIVS for the last naming with a private poll sent to all the
Foundation membership, so the TC decided to use public (open) polling
this time around. Anyone with the link can vote, nothing was sent to
each of the voters individually.

The "Already voted" error might be due to CIVS limiting public polling
to one entry per IP, and a colleague of yours already voted... Maybe try
from another IP address ?



I don't think every small company has an unlimited pool of IP addresses.. 
Neither do people working from home from a big internet provider.


__
OpenStack Development Mailing 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] Poll: S Release Naming

[Dmitry Tantsur]

Hi,

I suspect that S-Bahn may be a protected (copyright, trademark, whatever) name. 
Did you have a chance to check it?


On 03/14/2018 12:58 AM, Paul Belanger wrote:

Greetings all,

It is time again to cast your vote for the naming of the S Release. This time
is little different as we've decided to use a public polling option over per
user private URLs for voting. This means, everybody should proceed to use the
following URL to cast their vote:

   
https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3

Because this is a public poll, results will currently be only viewable by myself
until the poll closes. Once closed, I'll post the URL making the results
viewable to everybody. This was done to avoid everybody seeing the results while
the public poll is running.

The poll will officially end on 2018-03-21 23:59:59[1], and results will be
posted shortly after.

[1] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst
---

According to the Release Naming Process, this poll is to determine the
community preferences for the name of the R release of OpenStack. It is
possible that the top choice is not viable for legal reasons, so the second or
later community preference could wind up being the name.

Release Name Criteria

Each release name must start with the letter of the ISO basic Latin alphabet
following the initial letter of the previous release, starting with the
initial release of "Austin". After "Z", the next name should start with
"A" again.

The name must be composed only of the 26 characters of the ISO basic Latin
alphabet. Names which can be transliterated into this character set are also
acceptable.

The name must refer to the physical or human geography of the region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic region under
consideration must be declared before the opening of nominations, as part of
the initiation of the selection process.

The name must be a single word with a maximum of 10 characters. Words that
describe the feature should not be included, so "Foo City" or "Foo Peak"
would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may make
an exception for one or more of them to be considered in the Condorcet poll.
The naming official is responsible for presenting the list of exceptional
names for consideration to the TC before the poll opens.

Exact Geographic Region

The Geographic Region from where names for the S release will come is Berlin

Proposed Names

Spree (a river that flows through the Saxony, Brandenburg and Berlin states of
Germany)

SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)

Spandau (One of the twelve boroughs of Berlin)

Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
abbreviated as )

Steglitz (a locality in the South Western part of the city)

Springer (Berlin is headquarters of Axel Springer publishing house)

Staaken (a locality within the Spandau borough)

Schoenholz (A zone in the Niederschönhausen district of Berlin)

Shellhaus (A famous office building)

Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)

Schiller (A park in the Mitte borough)

Saatwinkel (The name of a super tiny beach, and its surrounding neighborhood)
(The adjective form, Saatwinkler is also a really cool bridge but
that form is too long)

Sonne (Sonnenallee is the name of a large street in Berlin crossing the former
wall, also translates as "sun")

Savigny (Common place in City-West)

Soorstreet (Street in Berlin restrict Charlottenburg)

Solar (Skybar in Berlin)

See (Seestraße or "See Street" in Berlin)

Thanks,
Paul

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




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

[openstack-dev] [manila][ptg] Rocky PTG summary

[Tom Barron]

We had a good showing [1] at the Rocky PTG in Dublin.  Most of us see
each other face-to-face rarely and we had some (even long time)
contributors come to the PTG for the first time or join manila from
other projects!  We had a good time together [2], took on some tough
subjects, and planned out our approach to Rocky.

The following summarizes our main discussions.  For the raw
discussion topic/log etherpad see [3] or for video of the team in
action see [4].  This summary has also been rendered in this
etherpad:

https://etherpad.openstack.org/p/manila-rocky-ptg-summary

Please follow up in the etherpad with corrections or additions,
especially where we've missed a perspective or interpretation.

== Queens Retrospective ==

Summary [5] shows focus on maintaining quality and integrity of the
project while at the same time seeking ways to encourage developer
participation, new driver engagement, and adoption of manila in real
deployments.

== Rocky Schedule ==

- We'll keep the same project specific deadlines as Queens:
* Spec freeze at Rocky-1 milestone
* New Driver Submission Freeze at Rocky-2 milestone
* Feature Proposal Freeze at release-7 week
 (two weeks before Rocky-3 milestone)

== Cross Project Goals ==

- Manila met the queens goals (policy in code [6] and split of tempest
 into its own repos [7]).
- For Rocky mox removal goal [8] we have no direct usage of mox
 anymore but need to track the transitive dependency of the manila-ui
 plugin on mox via horizon [9]
- We have already met the minimum Rocky mutable configuration goal [10]
 in that we have general support for toggle of debug logging without
 restart.  We agreed that additional mutable configuration options
 should be proposed on a case-by-case basis, with use-cases and
 supporting arguments to the effect that they are indeed safe to be
 treated as mutable.

== Documentation Gaps ==

- amito's experience introducing the new Infinidat driver in Queens
 shows significant gaps in our doc for new drivers
- jungleboyj proposed that cinder will clean up its onboarding doc
 including its wiki for how to contribute a driver [11]
- amito will work with the manila community to port over this information
 and identify any remaining gaps
- patrickeast will be adding a Pure back end in Rocky and can help
 identify gaps
- we agreed to work with cinder to drive consistency in 'Contributor
 Guide' format and subject matter.

== Python 3 ==

- Distros are dropping support for python 2, completely, between now
 and 2020 so OpenStack projects we need to start getting ready now 
 [12]

- Our main exposure is in manila-ui where we still run unit tests with
 python 2 only
- Also need to add a good set of python 3 tempest tests for manila proper
- CentOS jobs will need to be replaced with stable Fedora jobs
- vkmc will drive this; overall goal may take more than one release

== NFSExportsHelper ==

- bswartz has a better implementation
- in discussion he developed a preliminary plan for migrating users
 from the old to the new implementation
- impacts generic and lvm drivers, arguably reference only
- bswartz will communicate any impact to openstack-dev, openstack-operators,
 and openstack-users mailing lists

== Quota Resource Usage Tracking ==

- we inherited our reservation/commit/rollback system from Cinder who
 in turn took theirs from Nova
- it is buggy, making reservations in one service and doing commit/rollback
 in scattered places in another service.  Customer bugs with quotas 
 are painful and confidence that they are actually fixed is low.

- melwitt and dansmith explained how Nova has now abandoned this
 system in favor of actual resource counting in the api service
- we intend to explore the possibility of implementing a similar system
 as the new Nova approach; cinder is exploring this as well
- can be implemented as bug fixes if it's clean and easy to understand

== Replacing rootwrap with privsep ==

- What's in it for manila?
- Nova says it improves performance; Cinder says it harms performance :)
- It serializes operations so the performance impact depends on how long
 the elevated privilege operations run.
- We need to study our codebase more to understand impact; not a Rocky
 goal for us to implement this.

== Huawei proposal to support more access rule attributes ==

* access levels like all_squash / no all_squash
 Most but not all vendors can support these.
 We agreed that although opaque metadata on access rules _could_ be
 used to allow manila forks to implement such support opaquely to
 manila proper, this is a generally useful characteristic, not
 something only useful for Huawei private cloud.  So it should be
 implemented using new public extra specs and back end capability
 checking in the scheduler in order to avoid error cases with back
 ends that cannot support the capabilities in question.
* ordering semantics for access rules to dis-ambiguate rule sets
 where incompatible access modes (like r/w and r/o) are applied
 to the same 

Re: [openstack-dev] [nova] [placement] placement update 18-10

[Chris Dent]

On Mon, 12 Mar 2018, Tetsuro Nakamura wrote:


# Questions

What's the status of shared resource providers? Did we even talk
about that in Dublin?



In terms of bug fixes related to allocation candidates, I'll try to answer
that question :)


Thanks very much for doing this.


* https://review.openstack.org/#/c/533396
AllocationCandidates.get_by_filters ignores shared RPs when the RC exists
in both places


I've just manually rebased the stack that includes the above to
account for the move of the resource provider objects which has
caused merged conflicts all over the place.


Besides these bugs, how we collaborate and merge existing logic of shared
resource provider and now being constructed logic of nested resource
provider remains one of the challenges in Rocky in my understanding.


Indeed.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cyborg][glance][nova]cyborg FPGA management flow disscusion.

[Feng, Shaohe]

Hi all.
This is the agent of today’s discussion.
https://etherpad.openstack.org/p/cyborg-nova-poc

BR
Feng, Shaohe

From: Zhipeng Huang [mailto:zhipengh...@gmail.com]
Sent: 2018年3月8日 12:08
To: Feng, Shaohe 
Cc: openstack-dev@lists.openstack.org; openstack-operat...@lists.openstack.org; 
Du, Dolpher ; Ding, Jian-feng ; 
Sun, Yih Leong ; Nadathur, Sundar 
; Dutch ; Rushil Chugh 
; Nguyen Hung Phuong ; Justin 
Kilpatrick ; Ranganathan, Shobha 
; zhuli ; 
bao.yum...@zte.com.cn; Li Liu ; xiaodong...@tencent.com; 
kong.w...@zte.com.cn; li.xia...@zte.com.cn
Subject: Re: [openstack-dev][cyborg][glance][nova]cyborg FPGA management flow 
disscusion.

Thanks Shaohe,

Let's schedule a video conf session next week.

On Thu, Mar 8, 2018 at 11:41 AM, Feng, Shaohe 
> wrote:
Hi All:

The POC is here:
https://github.com/shaohef/cyborg

BR
Shaohe Feng

_
From: Feng, Shaohe
Sent: 2018年2月12日 15:06
To: 
openstack-dev@lists.openstack.org; 
openstack-operat...@lists.openstack.org
Cc: Du, Dolpher >; Zhipeng 
Huang >; Ding, Jian-feng 
>; Sun, Yih Leong 
>; Nadathur, Sundar 
>; Dutch 
>; Rushil Chugh 
>; Nguyen Hung Phuong 
>; Justin Kilpatrick 
>; Ranganathan, Shobha 
>; zhuli 
>; 
bao.yum...@zte.com.cn; 
xiaodong...@tencent.com; 
kong.w...@zte.com.cn; 
li.xia...@zte.com.cn; Feng, Shaohe 
>
Subject: [openstack-dev][cyborg][glance][nova]cyborg FPGA management flow 
disscusion.


Now I am working on an FPGA management POC with Dolpher.
We have finished some code, and have discussion with Li Liu and some cyborg 
developer guys.

Here are some discussions:

image management
1. User should upload the FPGA image to glance and set the tags as follow:
There are two suggestions to upload an FPGA image.
A. use raw glance api like:
   $ openstack image create --file mypath/FPGA.img  fpga.img
   $ openstack image set --tag FPGA --property vendor=intel --property 
type=crypto 58b813db-1fb7-43ec-b85c-3b771c685d22
   The image must have "FPGA" tag and accelerator type(such as type=crypto).
B. cyborg support a new api to upload a image.
   This API will wrap glance api and include the above steps, also make image 
record in it's local DB.

2. Cyborg agent/conductor get the FPGA image info from glance.
There are also two suggestions to get the FPGA image info.
A. use raw glance api.
Cyborg will get the images by FPGA tag and timestamp periodically and store 
them in it's local cache.
It will use the images tags and properties to form placement taits and 
resource_class name.
B. store the imformations when call cybort's new upload API.

3. Image download.
call glance image download API to local file. and make a corresponding md5 
files for checksum.

GAP in image management：
missing related glance image client in cyborg.

resource report management for scheduler.
1.  Cyborg agent/conductor need synthesize all useful information from FPGA 
driver and image information.
The traits will be like:
CUSTOM_FPGA, CUSTOM_ACCELERATOR_CRYPTO,
The resource_class will be like:
CUSTOM_FPGA_INTEL_PF, CUSTOM_FPGA_INTEL_VF
{"inventories":
"CUSTOM_FPGA_INTEL_PF": {
"allocation_ratio": 1.0,
"max_unit": 4,
"min_unit": 1,
"reserved": 0,
"step_size": 1,
"total": 4
}
}


Accelerator claim and release:
1. Cybort will support the releated API for accelerator claim and release.
It can pass the follow parameters:
  nodename: Which host that accelerator located on, it is required.
  type: This accelerator type, cyborg can get image uuid by it. it is optional.
  image uuid: the uuid of FPGA bitstream image, . it is optional.
  traits: the traits info that cyborg reports to placement.
  resource_class: the resource_class name that reports to placement.
And return the address for the accelerator. At present, it 

Re: [openstack-dev] [masakari] Masakari Project mascot ideas

[Shewale, Bhagyashri]

+1 for St. Bernard

Regards,
Bhagyashri Shewale


From: Patil, Tushar 
Sent: Wednesday, March 14, 2018 7:52:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari] Masakari Project mascot ideas

Hi,


Total 4 people attended last IRC meeting and all of them have voted for 
St.Bernard Dog.


If someone has missed to vote, please vote for mascot now.


Options:

1) Asiatic black bear
2) Gekko : Geckos is able to regrow it's tail when the tail is lost.
3) St. Bernard: St. Bernard is famous as rescue dog (Masakari rescues VM 
instances)


Thank you.


Regards,

Tushar Patil




From: Bhor, Dinesh 
Sent: Wednesday, March 14, 2018 10:16:29 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari] Masakari Project mascot ideas


Hi Sampath San,


There is one more option which we discussed in yesterdays masakari meeting [1]:

St. Bernard(Dog) [2].


[1] 
http://eavesdrop.openstack.org/meetings/masakari/2018/masakari.2018-03-13-04.01.log.html#l-38


[2] https://en.wikipedia.org/wiki/St._Bernard_(dog)


Thank you,

Dinesh Bhor



From: Sam P 
Sent: 13 March 2018 22:19:00
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [masakari] Masakari Project mascot ideas

Hi All,

We started this discussion on IRC meeting few weeks ago and still no 
progress..;)
(aspiers: thanks for the reminder!)

Need mascot proposals for Masakari, see FAQ [1] for more info
Current ideas: Origin of "Masakari" is related to hero from Japanese folklore 
[2].
Considering that relationship and to start the process, here are few ideas,
(1) Asiatic black bear
(2) Gekko : Geckos is able to regrow it's tail when the tail is lost.

[1] https://www.openstack.org/project-mascots/
[http://www.openstack.org/themes/openstack/images/openstack-logo-full.png]

Project Mascots - OpenStack is open source software for 
...
www.openstack.org
We are OpenStack. We’re also passionately developing more than 60 projects 
within OpenStack. To support each project’s unique identity and visually 
demonstrate ...


[2] https://en.wikipedia.org/wiki/Kintar%C5%8D

--- Regards,
Sampath


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
OpenStack Development Mailing 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] [tricircle] Nominate change in tricircle core team (crh)

[Yipei Niu]

+1.

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

Re: [openstack-dev] [cyborg]Weekly Team Meeting 2018.03.14 Agenda (No Time Change For US)

[Zhipeng Huang]

Update:

1. ZOOM link:
- Part 1:  https://zoom.us/j/511883630 (starting UTC1400 )
- Part 2:  https://zoom.us/j/741227793

2. Agenda:
- PoC demo from Shaohe
- Rocky Work Assignment: (nova-cyborg interaction, programmability,
multi-tenancy/quota, more drivers, metadata, GPU, documentation, testing)




On Wed, Mar 14, 2018 at 10:14 AM, Zhipeng Huang 
wrote:

> Yes that would be one of the issue we need to discuss after the PoC demo :)
>
> On Wed, Mar 14, 2018 at 10:11 AM, Nadathur, Sundar <
> sundar.nadat...@intel.com> wrote:
>
>> Hi Howard,
>>
>> Can we discuss the possibility of using a filter/weigher that invokes
>> Cyborg API, as we discussed during the Cyborg/Nova discussion in the PTG?
>>
>>
>>
>> This is line 56 in https://etherpad.openstack.org
>> /p/cyborg-ptg-rocky-nova-cyborg-interaction .
>>
>>
>>
>> Regards,
>>
>> Sundar
>>
>>
>>
>> *From:* Zhipeng Huang [mailto:zhipengh...@gmail.com]
>> *Sent:* Monday, March 12, 2018 1:28 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Cc:* Konstantinos Samaras-Tsakiris > @cern.ch>; Dutch Althoff 
>> *Subject:* [openstack-dev] [cyborg]Weekly Team Meeting 2018.03.14 Agenda
>> (No Time Change For US)
>>
>>
>>
>> Hi Team,
>>
>>
>>
>> We will resume the team meeting this week. The meeting starting time is
>> still ET 10:00am/PT 7:00am, whereas in China it is moved one hour early to
>> 10:00pm. For Europe please refer to UTC1400 as the baseline.
>>
>>
>>
>> This week we will have a special 2 hour meeting. In the first one hour we
>> will have Shaohe demo the PoC Intel dev team had conducted, and in the
>> second half we will confirm the task and milestones for Rocky based upon
>> the PTG discussion (summary sent out last Friday).
>>
>>
>>
>> ZOOM link will be provided before the meeting :)
>>
>>
>>
>> If there are any other topics anyone would like to propose, feel free to
>> reply to this email thread.
>>
>>
>>
>> --
>>
>> Zhipeng (Howard) Huang
>>
>>
>>
>> Standard Engineer
>>
>> IT Standard & Patent/IT Product Line
>>
>> Huawei Technologies Co,. Ltd
>>
>> Email: huangzhip...@huawei.com
>>
>> Office: Huawei Industrial Base, Longgang, Shenzhen
>>
>>
>>
>> (Previous)
>>
>> Research Assistant
>>
>> Mobile Ad-Hoc Network Lab, Calit2
>>
>> University of California, Irvine
>>
>> Email: zhipe...@uci.edu
>>
>> Office: Calit2 Building Room 2402
>>
>>
>>
>> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>



-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] Poll: S Release Naming

[Sławomir Kapłoński]

Indeed. I now tried from different IP address and I was able to vote. Thx a lot 
for help.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl

> Wiadomość napisana przez Thierry Carrez  w dniu 
> 14.03.2018, o godz. 10:05:
> 
> Jens Harbott wrote:
>> 2018-03-14 9:21 GMT+01:00 Sławomir Kapłoński :
>>> Hi,
>>> 
>>> Are You sure this link is good? I just tried it and I got info that 
>>> "Already voted" which isn't true in fact :)
>> 
>> Comparing with previous polls, these should be personalized links that
>> need to be sent out to each voter individually, so I agree that this
>> looks like a mistake.
> 
> We crashed CIVS for the last naming with a private poll sent to all the
> Foundation membership, so the TC decided to use public (open) polling
> this time around. Anyone with the link can vote, nothing was sent to
> each of the voters individually.
> 
> The "Already voted" error might be due to CIVS limiting public polling
> to one entry per IP, and a colleague of yours already voted... Maybe try
> from another IP address ?
> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing 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] Poll: S Release Naming

[Thierry Carrez]

Jens Harbott wrote:
> 2018-03-14 9:21 GMT+01:00 Sławomir Kapłoński :
>> Hi,
>>
>> Are You sure this link is good? I just tried it and I got info that "Already 
>> voted" which isn't true in fact :)
> 
> Comparing with previous polls, these should be personalized links that
> need to be sent out to each voter individually, so I agree that this
> looks like a mistake.

We crashed CIVS for the last naming with a private poll sent to all the
Foundation membership, so the TC decided to use public (open) polling
this time around. Anyone with the link can vote, nothing was sent to
each of the voters individually.

The "Already voted" error might be due to CIVS limiting public polling
to one entry per IP, and a colleague of yours already voted... Maybe try
from another IP address ?

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [nova] about rebuild instance booted from volume

[李杰]

Hi,all


This is the spec about  rebuild a instance booted from volume.In 
the spec,there is a 
  question about if we should delete the old root_volume.Anyone who is 
interested in
  booted from volume can help to review this. Any suggestion is 
welcome.Thank you!
  The link is here.
  Re:the rebuild spec:https://review.openstack.org/#/c/532407/














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

[openstack-dev] [nova] about rebuild instance booted from volume

[李杰]

Hi,all


This is the spec about  backup a instance booted from volume, 
anyone who is interested in
  booted from volume can help to review this. Any suggestion is welcome.
  The link is here.
  Re:the backup spec:https://review.openstack.org/#/c/530214/














Best Regards
Lijie__
OpenStack Development Mailing 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] Poll: S Release Naming

[Jens Harbott]

2018-03-14 9:21 GMT+01:00 Sławomir Kapłoński :
> Hi,
>
> Are You sure this link is good? I just tried it and I got info that "Already 
> voted" which isn't true in fact :)

Comparing with previous polls, these should be personalized links that
need to be sent out to each voter individually, so I agree that this
looks like a mistake.

>> Wiadomość napisana przez Paul Belanger  w dniu 
>> 14.03.2018, o godz. 00:58:
>>
>> Greetings all,
>>
>> It is time again to cast your vote for the naming of the S Release. This time
>> is little different as we've decided to use a public polling option over per
>> user private URLs for voting. This means, everybody should proceed to use the
>> following URL to cast their vote:
>>
>>  
>> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3
>>
>> Because this is a public poll, results will currently be only viewable by 
>> myself
>> until the poll closes. Once closed, I'll post the URL making the results
>> viewable to everybody. This was done to avoid everybody seeing the results 
>> while
>> the public poll is running.
>>
>> The poll will officially end on 2018-03-21 23:59:59[1], and results will be
>> posted shortly after.
>>
>> [1] 
>> http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst
>> ---
>>
>> According to the Release Naming Process, this poll is to determine the
>> community preferences for the name of the R release of OpenStack. It is
>> possible that the top choice is not viable for legal reasons, so the second 
>> or
>> later community preference could wind up being the name.
>>
>> Release Name Criteria
>>
>> Each release name must start with the letter of the ISO basic Latin alphabet
>> following the initial letter of the previous release, starting with the
>> initial release of "Austin". After "Z", the next name should start with
>> "A" again.
>>
>> The name must be composed only of the 26 characters of the ISO basic Latin
>> alphabet. Names which can be transliterated into this character set are also
>> acceptable.
>>
>> The name must refer to the physical or human geography of the region
>> encompassing the location of the OpenStack design summit for the
>> corresponding release. The exact boundaries of the geographic region under
>> consideration must be declared before the opening of nominations, as part of
>> the initiation of the selection process.
>>
>> The name must be a single word with a maximum of 10 characters. Words that
>> describe the feature should not be included, so "Foo City" or "Foo Peak"
>> would both be eligible as "Foo".
>>
>> Names which do not meet these criteria but otherwise sound really cool
>> should be added to a separate section of the wiki page and the TC may make
>> an exception for one or more of them to be considered in the Condorcet poll.
>> The naming official is responsible for presenting the list of exceptional
>> names for consideration to the TC before the poll opens.
>>
>> Exact Geographic Region
>>
>> The Geographic Region from where names for the S release will come is Berlin
>>
>> Proposed Names
>>
>> Spree (a river that flows through the Saxony, Brandenburg and Berlin states 
>> of
>>   Germany)
>>
>> SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)
>>
>> Spandau (One of the twelve boroughs of Berlin)
>>
>> Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
>>   abbreviated as )
>>
>> Steglitz (a locality in the South Western part of the city)
>>
>> Springer (Berlin is headquarters of Axel Springer publishing house)
>>
>> Staaken (a locality within the Spandau borough)
>>
>> Schoenholz (A zone in the Niederschönhausen district of Berlin)
>>
>> Shellhaus (A famous office building)
>>
>> Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)
>>
>> Schiller (A park in the Mitte borough)
>>
>> Saatwinkel (The name of a super tiny beach, and its surrounding neighborhood)
>>   (The adjective form, Saatwinkler is also a really cool bridge but
>>   that form is too long)
>>
>> Sonne (Sonnenallee is the name of a large street in Berlin crossing the 
>> former
>>   wall, also translates as "sun")
>>
>> Savigny (Common place in City-West)
>>
>> Soorstreet (Street in Berlin restrict Charlottenburg)
>>
>> Solar (Skybar in Berlin)
>>
>> See (Seestraße or "See Street" in Berlin)
>>
>> Thanks,
>> Paul
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] Poll: S Release Naming

[Sławomir Kapłoński]

Hi,

Are You sure this link is good? I just tried it and I got info that "Already 
voted" which isn't true in fact :)

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl

> Wiadomość napisana przez Paul Belanger  w dniu 
> 14.03.2018, o godz. 00:58:
> 
> Greetings all,
> 
> It is time again to cast your vote for the naming of the S Release. This time
> is little different as we've decided to use a public polling option over per
> user private URLs for voting. This means, everybody should proceed to use the
> following URL to cast their vote:
> 
>  
> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3
> 
> Because this is a public poll, results will currently be only viewable by 
> myself
> until the poll closes. Once closed, I'll post the URL making the results
> viewable to everybody. This was done to avoid everybody seeing the results 
> while
> the public poll is running.
> 
> The poll will officially end on 2018-03-21 23:59:59[1], and results will be
> posted shortly after.
> 
> [1] 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst
> ---
> 
> According to the Release Naming Process, this poll is to determine the
> community preferences for the name of the R release of OpenStack. It is
> possible that the top choice is not viable for legal reasons, so the second or
> later community preference could wind up being the name.
> 
> Release Name Criteria
> 
> Each release name must start with the letter of the ISO basic Latin alphabet
> following the initial letter of the previous release, starting with the
> initial release of "Austin". After "Z", the next name should start with
> "A" again.
> 
> The name must be composed only of the 26 characters of the ISO basic Latin
> alphabet. Names which can be transliterated into this character set are also
> acceptable.
> 
> The name must refer to the physical or human geography of the region
> encompassing the location of the OpenStack design summit for the
> corresponding release. The exact boundaries of the geographic region under
> consideration must be declared before the opening of nominations, as part of
> the initiation of the selection process.
> 
> The name must be a single word with a maximum of 10 characters. Words that
> describe the feature should not be included, so "Foo City" or "Foo Peak"
> would both be eligible as "Foo".
> 
> Names which do not meet these criteria but otherwise sound really cool
> should be added to a separate section of the wiki page and the TC may make
> an exception for one or more of them to be considered in the Condorcet poll.
> The naming official is responsible for presenting the list of exceptional
> names for consideration to the TC before the poll opens.
> 
> Exact Geographic Region
> 
> The Geographic Region from where names for the S release will come is Berlin
> 
> Proposed Names
> 
> Spree (a river that flows through the Saxony, Brandenburg and Berlin states of
>   Germany)
> 
> SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)
> 
> Spandau (One of the twelve boroughs of Berlin)
> 
> Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
>   abbreviated as )
> 
> Steglitz (a locality in the South Western part of the city)
> 
> Springer (Berlin is headquarters of Axel Springer publishing house)
> 
> Staaken (a locality within the Spandau borough)
> 
> Schoenholz (A zone in the Niederschönhausen district of Berlin)
> 
> Shellhaus (A famous office building)
> 
> Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)
> 
> Schiller (A park in the Mitte borough)
> 
> Saatwinkel (The name of a super tiny beach, and its surrounding neighborhood)
>   (The adjective form, Saatwinkler is also a really cool bridge but
>   that form is too long)
> 
> Sonne (Sonnenallee is the name of a large street in Berlin crossing the former
>   wall, also translates as "sun")
> 
> Savigny (Common place in City-West)
> 
> Soorstreet (Street in Berlin restrict Charlottenburg)
> 
> Solar (Skybar in Berlin)
> 
> See (Seestraße or "See Street" in Berlin)
> 
> Thanks,
> Paul
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] OpenStack - Install gnocchi error.

[Julien Danjou]

On Wed, Mar 14 2018, __ mango. wrote:

> After the installation (apt-get install gnocchi-api gnocchi- gnocchiclient),
> When I tried to launch the gnocc-api, I got the message.
>Failed to start gnocchi-api. Service: Unit gnocchi-api. Service not found.
> I checked /etc/init.d and there is no script gnocchi-api (although 
> gnocchi-metricd is, and it's working properly).
>
> Why is that? Please help me to solve it. Thank you.

Sounds like a Ubuntu packaging issue potentially.
Did you try reading the documentation?
  https://gnocchi.xyz/operating.html#running-api-as-a-wsgi-application

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


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

Re: [openstack-dev] [neutron] Prevent ARP spoofing

[Tatiana Kholkina]

Sure, there is an ability to enable ARP spoofing for the port/network, but
it is impossible to make it enabled by default for all ports.
It looks a bit complicated to me and I think it would be better to have an
ability to set default port security via config file.

Best regards,
Tatiana

2018-03-13 15:10 GMT+03:00 Claudiu Belu :

> Hi,
>
> Indeed ARP spoofing is prevented by default, but AFAIK, if you want it
> enabled for a port / network, you can simply disable the security groups on
> that neutron network / port.
>
> Best regards,
>
> Claudiu Belu
>
> --
> *From:* Татьяна Холкина [holk...@selectel.ru]
> *Sent:* Tuesday, March 13, 2018 12:54 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [neutron] Prevent ARP spoofing
>
> Hi,
> I'm using an ocata release of OpenStack where the option
> prevent_arp_spoofing can be managed via conf. But later in pike it was
> removed and it was decided to prevent spoofing by default.
> There are cases where security features should be disabled. As I can see
> now we can use a port_security option for these cases. But this option
> should be set for a particular port or network on create. The default value
> is set to True [1] and itt is impossible to change it. I'd like to
> suggest to get default value for port_security [2] from config option.
> It would be nice to know your opinion.
>
> [1] https://github.com/openstack/neutron-lib/blob/
> stable/queens/neutron_lib/api/definitions/port_security.py#L21
> [2] https://github.com/openstack/neutron/blob/stable/
> queens/neutron/objects/extensions/port_security.py#L24
>
> Best regards,
> Tatiana
>
> __
> OpenStack Development Mailing 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] [masakari] Masakari Project mascot ideas

[Abhishek Kekane]

+1 for St. Bernard

Thanks,

Abhishek

On Wed, Mar 14, 2018 at 12:04 PM, Sam P  wrote:

> Nice idea. Thanks..
> ​>
> 3) St. > Bernard: St. Bernard is famous as rescue dog (Masakari rescues
> VM instances)
> ​+1​
> ​ I will confirm in advance whether we can use this as our mascot.
>
> --- Regards,
> Sampath
>
>
> On Wed, Mar 14, 2018 at 11:22 AM, Patil, Tushar 
> wrote:
>
>> Hi,
>>
>>
>> Total 4 people attended last IRC meeting and all of them have voted for
>> St.Bernard Dog.
>>
>>
>> If someone has missed to vote, please vote for mascot now.
>>
>>
>> Options:
>> 1) Asiatic black bear
>>
>> 2) Gekko : Geckos is able to regrow it's tail when the tail is lost.
>> ​​
>> 3) St. Bernard: St. Bernard is famous as rescue dog (Masakari rescues VM
>> instances)
>>
>> Thank you.
>>
>>
>> Regards,
>>
>> Tushar Patil
>>
>>
>>
>> --
>> *From:* Bhor, Dinesh 
>> *Sent:* Wednesday, March 14, 2018 10:16:29 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [masakari] Masakari Project mascot ideas
>>
>>
>> Hi Sampath San,
>>
>>
>> There is one more option which we discussed in yesterdays masakari
>> meeting [1]:
>>
>> St. Bernard(Dog) [2].
>>
>>
>> [1] http://eavesdrop.openstack.org/meetings/masakari/2018/ma
>> sakari.2018-03-13-04.01.log.html#l-38
>>
>>
>> [2] https://en.wikipedia.org/wiki/St._Bernard_(dog)
>>
>>
>> Thank you,
>>
>> Dinesh Bhor
>>
>>
>> --
>> *From:* Sam P 
>> *Sent:* 13 March 2018 22:19:00
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] [masakari] Masakari Project mascot ideas
>>
>> Hi All,
>>
>> We started this discussion on IRC meeting few weeks ago and still no
>> progress..;)
>> (aspiers: thanks for the reminder!)
>>
>> Need mascot proposals for Masakari, see FAQ [1] for more info
>>
>> Current ideas: Origin of "Masakari" is related to hero from Japanese
>> folklore [2].
>> Considering that relationship and to start the process, here are few
>> ideas,
>> (1) Asiatic black bear
>>
>> (2) Gekko : Geckos is able to regrow it's tail when the tail is lost.
>>
>> [1] https://www.openstack.org/project-mascots/
>> 
>> Project Mascots - OpenStack is open source software for ...
>> 
>> www.openstack.org
>> We are OpenStack. We’re also passionately developing more than 60
>> projects within OpenStack. To support each project’s unique identity and
>> visually demonstrate ...
>>
>> [2] https://en.wikipedia.org/wiki/Kintar%C5%8D
>>
>> --- Regards,
>> Sampath
>>
>>
>> __
>> Disclaimer: This email and any attachments are sent in strictest
>> confidence
>> for the sole use of the addressee and may contain legally privileged,
>> confidential, and proprietary data. If you are not the intended recipient,
>> please advise the sender by replying promptly to this email and then
>> delete
>> and destroy this email and any attachments without any further use,
>> copying
>> or forwarding.
>>
>> __
>> Disclaimer: This email and any attachments are sent in strictest
>> confidence
>> for the sole use of the addressee and may contain legally privileged,
>> confidential, and proprietary data. If you are not the intended recipient,
>> please advise the sender by replying promptly to this email and then
>> delete
>> and destroy this email and any attachments without any further use,
>> copying
>> or forwarding.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [masakari] Masakari Project mascot ideas

[Sam P]

Nice idea. Thanks..
​>
3) St. > Bernard: St. Bernard is famous as rescue dog (Masakari rescues VM
instances)
​+1​
​ I will confirm in advance whether we can use this as our mascot.

--- Regards,
Sampath


On Wed, Mar 14, 2018 at 11:22 AM, Patil, Tushar 
wrote:

> Hi,
>
>
> Total 4 people attended last IRC meeting and all of them have voted for
> St.Bernard Dog.
>
>
> If someone has missed to vote, please vote for mascot now.
>
>
> Options:
> 1) Asiatic black bear
>
> 2) Gekko : Geckos is able to regrow it's tail when the tail is lost.
> ​​
> 3) St. Bernard: St. Bernard is famous as rescue dog (Masakari rescues VM
> instances)
>
> Thank you.
>
>
> Regards,
>
> Tushar Patil
>
>
>
> --
> *From:* Bhor, Dinesh 
> *Sent:* Wednesday, March 14, 2018 10:16:29 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [masakari] Masakari Project mascot ideas
>
>
> Hi Sampath San,
>
>
> There is one more option which we discussed in yesterdays masakari meeting
> [1]:
>
> St. Bernard(Dog) [2].
>
>
> [1] http://eavesdrop.openstack.org/meetings/masakari/2018/
> masakari.2018-03-13-04.01.log.html#l-38
>
>
> [2] https://en.wikipedia.org/wiki/St._Bernard_(dog)
>
>
> Thank you,
>
> Dinesh Bhor
>
>
> --
> *From:* Sam P 
> *Sent:* 13 March 2018 22:19:00
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [masakari] Masakari Project mascot ideas
>
> Hi All,
>
> We started this discussion on IRC meeting few weeks ago and still no
> progress..;)
> (aspiers: thanks for the reminder!)
>
> Need mascot proposals for Masakari, see FAQ [1] for more info
>
> Current ideas: Origin of "Masakari" is related to hero from Japanese
> folklore [2].
> Considering that relationship and to start the process, here are few
> ideas,
> (1) Asiatic black bear
>
> (2) Gekko : Geckos is able to regrow it's tail when the tail is lost.
>
> [1] https://www.openstack.org/project-mascots/
> 
> Project Mascots - OpenStack is open source software for ...
> 
> www.openstack.org
> We are OpenStack. We’re also passionately developing more than 60 projects
> within OpenStack. To support each project’s unique identity and visually
> demonstrate ...
>
> [2] https://en.wikipedia.org/wiki/Kintar%C5%8D
>
> --- Regards,
> Sampath
>
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> OpenStack Development Mailing 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] [ceilometer][gnocchi]-gnocchi installation failed.

[__ mango.]

hi??
I refer to: 
https://docs.openstack.org/ceilometer/pike/install/install-base-ubuntu.html to 
install gnocchi,
Operation (apt-get installed gnocchi-api gnocchi-gnocchiclient),
When I tried to launch the gnocc-api, I got the message.
No gnocchi- API starts. Service :gnocchi-api unit. The service was not found.
I checked /etc/init.d and no script gnocchi-api(although gnocchi-metricd is, 
and it works).
Why is that? Please help me to solve this problem. Thank you very much.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules

[Xinni Ge]

Hi Horizon Team,

I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin option,
 and submitted a patch for it.
Could you please help to review the patch.

https://bugs.launchpad.net/horizon/+bug/1755339
https://review.openstack.org/#/c/552259/

Thank you very much.

Best Regards,
Xinni

On Tue, Mar 13, 2018 at 6:41 PM, Ivan Kolodyazhny  wrote:

> Hi Kaz,
>
> Thanks for cleaning this up. I put +1 on both of these patches
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara 
> wrote:
>
>> Hi Ivan & Horizon folks,
>>
>>
>> Now we are submitting a couple of patches to have the new xstatic modules.
>> Let me request you to have review the following patches.
>> We need Horizon PTL's +1 to move these forward.
>>
>> project-config
>> https://review.openstack.org/#/c/551978/
>>
>> governance
>> https://review.openstack.org/#/c/551980/
>>
>> Thanks in advance:)
>>
>> Regards,
>> Kaz
>>
>>
>> 2018-03-12 20:00 GMT+09:00 Radomir Dopieralski :
>> > Yes, please do that. We can then discuss in the review about technical
>> > details.
>> >
>> > On Mon, Mar 12, 2018 at 2:54 AM, Xinni Ge 
>> wrote:
>> >>
>> >> Hi, Akihiro
>> >>
>> >> Thanks for the quick reply.
>> >>
>> >> I agree with your opinion that BASE_XSTATIC_MODULES should not be
>> >> modified.
>> >> It is much better to enhance horizon plugin settings,
>> >>  and I think maybe there could be one option like ADD_XSTATIC_MODULES.
>> >> This option adds the plugin's xstatic files in STATICFILES_DIRS.
>> >> I am considering to add a bug report to describe it at first, and give
>> a
>> >> patch later maybe.
>> >> Is that ok with the Horizon team?
>> >>
>> >> Best Regards.
>> >> Xinni
>> >>
>> >> On Fri, Mar 9, 2018 at 11:47 PM, Akihiro Motoki 
>> wrote:
>> >>>
>> >>> Hi Xinni,
>> >>>
>> >>> 2018-03-09 12:05 GMT+09:00 Xinni Ge :
>> >>> > Hello Horizon Team,
>> >>> >
>> >>> > I would like to hear about your opinions about how to add new
>> xstatic
>> >>> > modules to horizon settings.
>> >>> >
>> >>> > As for Heat-dashboard project embedded 3rd-party files issue, thanks
>> >>> > for
>> >>> > your advices in Dublin PTG, we are now removing them and
>> referencing as
>> >>> > new
>> >>> > xstatic-* libs.
>> >>>
>> >>> Thanks for moving this forward.
>> >>>
>> >>> > So we installed the new xstatic files (not uploaded as openstack
>> >>> > official
>> >>> > repos yet) in our development environment now, but hesitate to
>> decide
>> >>> > how to
>> >>> > add the new installed xstatic lib path to STATICFILES_DIRS in
>> >>> > openstack_dashboard.settings so that the static files could be
>> >>> > automatically
>> >>> > collected by *collectstatic* process.
>> >>> >
>> >>> > Currently Horizon defines BASE_XSTATIC_MODULES in
>> >>> > openstack_dashboard/utils/settings.py and the relevant static fils
>> are
>> >>> > added
>> >>> > to STATICFILES_DIRS before it updates any Horizon plugin dashboard.
>> >>> > We may want new plugin setting keywords ( something similar to
>> >>> > ADD_JS_FILES)
>> >>> > to update horizon XSTATIC_MODULES (or directly update
>> >>> > STATICFILES_DIRS).
>> >>>
>> >>> IMHO it is better to allow horizon plugins to add xstatic modules
>> >>> through horizon plugin settings. I don't think it is a good idea to
>> >>> add a new entry in BASE_XSTATIC_MODULES based on horizon plugin
>> >>> usages. It makes difficult to track why and where a xstatic module in
>> >>> BASE_XSTATIC_MODULES is used.
>> >>> Multiple horizon plugins can add a same entry, so horizon code to
>> >>> handle plugin settings should merge multiple entries to a single one
>> >>> hopefully.
>> >>> My vote is to enhance the horizon plugin settings.
>> >>>
>> >>> Akihiro
>> >>>
>> >>> >
>> >>> > Looking forward to hearing any suggestions from you guys, and
>> >>> > Best Regards,
>> >>> >
>> >>> > Xinni Ge
>> >>> >
>> >>> >
>> >>> > 
>> __
>> >>> > OpenStack Development Mailing 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
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> 葛馨霓 Xinni Ge
>> >>
>> >> 
>> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> >> 

[openstack-dev] [tripleo] TLS by default

[Juan Antonio Osorio]

Hello,

As part of the proposed changed by the Security Squad [1], we'd like the
deployment to use TLS by default.

The first target is to get the undercloud to use it, so a patch has been
proposed recently [2] [3]. So, just wanted to give a heads up to people.

This should be just fine from a quickstart/testing point of view, since we
explicitly set the value for autogenerating certificates in the undercloud
[4] [5].

Note that there are also plans to change these defaults for the
containerized undercloud and the overcloud.

BR

[1] https://etherpad.openstack.org/p/tripleo-security-squad
[2] https://review.openstack.org/#/c/552382/
[3] https://review.openstack.org/552781
[4]
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/extras-common/defaults/main.yml#L15
[5]
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/undercloud-deploy/templates/undercloud.conf.j2#L117
-- 
Juan Antonio Osorio R.
e-mail: jaosor...@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