date:20170727

+1000

2017-07-27 22:04 GMT+08:00 Doug Hellmann :

> I have noticed that Jay has been very deeply involved in several
> recent design discussions about oslo.db, and he obviously has a
> great deal of experience in the area, so even though he hasn't been
> actively reviewing patches recently I think he would be a good
> addition to the team. I have asked him, and he is interested and will
> try to become more active as well.
>
> Please indicate your opinion with +1/-1.
>
> 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
>



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

[openstack-dev] [tempest][infra][congress] subprocess launched in tempest test lacks file permission

2017-07-27 Thread Eric K

A tempest test [1] launches additional instances of Congress using
subprocess.popen and tests the coordination between them and the original
instance launched by devstack. The problem is, the new instances are
launched from the tempest test user rather than the user of the original
congress instance devstack created. As a result, the new instances fail
for being unable to access the encryption keys created by the original
congress instance (600 permission).[2]

Any suggestions for how to workaround this problem? Is it possible to
somehow configure the gate job to run tempest tests as SU or as the
stackuser that launches the original congress instance? Thanks so much!

[1] 
https://github.com/openstack/congress/blob/master/congress_tempest_tests/te
sts/scenario/congress_ha/test_ha.py.disabled#L117 (currently disabled,
trying to re-enable)

[2] 
http://logs.openstack.org/35/487235/5/check/gate-congress-dsvm-api-mysql-ub
untu-xenial/607623d/logs/testr_results.html.gz (find: OSError: [Errno 13]
Permission denied: '/etc/congress/keys/aes_key¹)



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

Re: [openstack-dev] [all][docs] 404s on docs website after the great reorg

++ for the solution.

2017-07-28 2:24 GMT+08:00 Doug Hellmann :

> Excerpts from Jeremy Stanley's message of 2017-07-27 16:40:08 +:
> > On 2017-07-27 12:23:39 -0400 (-0400), Sean Dague wrote:
> > > In the #openstack-nova channel this morning we were debugging some
> cells
> > > v2 things, and ran into the fact that the online docs for this -
> > > https://docs.openstack.org/nova/latest/cells.html go to a 404. That's
> a
> > > previously well known link, people have it in their browser history,
> > > bookmarks, wiki pages, other websites.
> > >
> > > My understanding of big moves like this is that redirects are
> important.
> > > Things going blackhole like that not only is an inconvenience to users,
> > > but impacts our search engine rankings, and takes a while for them to
> > > all sift out. I know in sites I run I'm still regularly getting in
> > > bounds to paths on the site that haven't been there for 8 years.
> > >
> > > It would be really good if we had a way (manual or automated) to have
> > > 301 redirects, that are fixable by the teams that now own the
> > > documentation (the project teams).
> >
> > We can look at including .htaccess files in the tree I guess? Or
> > some metadata the publish job uses to build them maybe?
>
> That's exactly what I was thinking.
>
> 1. Enable .htaccess files by turning on allowoverride for
>docs.openstack.org.
>
> 2. Add .htaccess files in each tree, as needed (see
>https://review.openstack.org/487932 for an example of how this
>is done with sphinx).
>
> 3. Update the main .htaccess file in openstack-manuals to redirect
>from the old location of docs in a way that passes the full path.
>Right now we redirect to /project/latest/:
>
>   redirectmatch 301 "^/developer/([^/]+)/.*$" /$1/latest/
>
>I think that would change to look something like:
>
>   redirectmatch 301 "^/developer/([^/]+)/(.*)$" /$1/latest/$2
>
>We would only want to do that for projects that actually have
>.htaccess files, so we can put a flag in the project-data files in
>openstack-manuals and generate project-specific redirect rules (we're
>already doing that for some other pages).
>
> Then when someone visits docs.o.o/developer/nova/cells.html it would
> redirect to docs.o.o/nova/latest/cells.html. The nova team then
> need to have a redirect from docs.o.o/nova/latest/cells.html to
> docs.o.o/nova/latest/user/cells.html.
>
> If folks think that's a good approach, I will start on the patches
> needed in infra and openstack-manuals (1 and 3).
>
> 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
>



-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing 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] Broken nova-lxd

For the specific case with method "last_bytes",  it's also used  in other
projects [1], an alternative solution is that add this method in
oslo.utils.fileutils, then consume it from oslo.

[1] http://codesearch.openstack.org/?q=last_bytes&i=nope&files=&repos=

2017-07-28 6:57 GMT+08:00 Michael Still :

> Hi,
>
> I'm cc'ing openstack-dev because your email is the same as the comment you
> made on the relevant review, and I think getting visibility with the wider
> Nova team is a good idea.
>
> Unfortunately this is a risk of having an out of tree Nova driver, which
> has never been the recommended path for implementing drivers for Nova.
> Being out of tree isn't forbidden, but it does come with the cost of
> staying up to date with Nova and handling changes as they occur.
>
> In this case, if you look at the review chain you'll see that the move is
> a pre-cursor to moving this code to use oslo.privsep. Unless lxd is going
> to move to privsep in lockstep with nova, your best bet would be to
> duplicate this utility method in the nova-lxd codebase.
>
> Michael
>
>
>
>
> On Thu, Jul 27, 2017 at 11:25 PM, Kharkov Alexander <
> kharkovalexan...@gmail.com> wrote:
>
>> Hi, Michael
>> I recently found that you commit to nova break nova-lxd driver
>> functionality because it utilizes last_bytes function from nova/utils.py
>> which you recently move to libvirt. Could you please confirm that it was
>> not expected and suggest a fix? I'm currently working on nova-lxd now and
>> want to have functioning unit tests to pull my changes for review.
>> Your commit and review links below:
>> https://git.openstack.org/cgit/openstack/nova/commit/?id=234
>> 1a41eaee5152e95379e5ed38012270af82ef5
>> https://review.openstack.org/#/c/472228/9
>> ...
>> Failed nova-lxd
>> ...
>>
>> Failed 1 tests - output below:
>>
>> ==
>>
>>
>> test_driver.LXDDriverTest.test_get_console_output
>>
>> -
>>
>>
>> Captured traceback:
>>
>> ~~~
>>
>> b'Traceback (most recent call last):'
>>
>> b'  File 
>> "/home/ubuntu/nova-lxd/.tox/py35/lib/python3.5/site-packages/mock/mock.py",
>> line 1305, in patched'
>>
>> b'return func(*args, **keywargs)'
>>
>> b'  File "/home/ubuntu/nova-lxd/nova/tests/unit/virt/lxd/test_driver.py",
>> line 604, in test_get_console_output'
>>
>> b'contents = lxd_driver.get_console_output(context, instance)'
>>
>> b'  File "/home/ubuntu/nova-lxd/nova/virt/lxd/driver.py", line 594,
>> in get_console_output'
>>
>> b'log_data, _ = utils.last_bytes(f, MAX_CONSOLE_BYTES)'
>>
>> b"AttributeError: module 'nova.utils' has no attribute 'last_bytes'"
>>
>> b''
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [neutron][vpnaas] driver removal

2017-07-27 Thread Takashi Yamamoto

hi,

some of drivers in neutron-vpnaas don't have maintainers. [1]
unless someone steps up, we might end up with removing those drivers.

especially, VyattaIPsecDriver will likely be removed in near future,
as it requires a special agent [2] which is difficult to maintain for
those who are not familiar with it.

[1] 
https://github.com/openstack/neutron-vpnaas/blob/master/doc/source/devref/team.rst
[2] 
https://github.com/openstack/neutron-vpnaas/blob/797c0466693108dd63415a065750e7a62a5f5ce8/setup.cfg#L36

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

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

2017-07-27 Thread Sean McGinnis

[snip]
> 
> My proposal is to put the documentation on docs.openstack.org and
> leave it there indefinitely.
> 

I like this approach. With the size being manageable (large, but
manageable), I would prefer we leave it until we need to free up
some of the space.

So until that time, no action is required and passively we provide
the legacy information for those that need it.

Sean

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

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

Excerpts from Doug Hellmann's message of 2017-07-27 19:05:16 -0400:
> Excerpts from Jeremy Stanley's message of 2017-07-27 22:07:33 +:
> > On 2017-07-27 15:40:22 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> > > Are we over-emphasizing the scale of the discovery problem?
> > > 
> > > When I search for how to install a package on Ubuntu (or Red Hat
> > > or Debian for that matter), I find all sorts of references all over
> > > the web (including on the sites for those distros) and I have to
> > > sift through it all to find right command or package name to use
> > > for my version.  Usually the easiest way to do that is to put the
> > > version in the search query.
> > > 
> > > Are our users incapable of finding the right version of a document
> > > if we clearly mark the version to which each document applies? Every
> > > URL now has a release series name or version tag in the path. The
> > > docs theme inserts the version number into every page as well. Is
> > > that sufficient to help a reader understand what version the info
> > > they're view is for?
> > > 
> > > That's not to say we shouldn't do some work to make newer docs easy
> > > to find. If we can modify the sitemap to make them appear earlier
> > > in search results, that's good. The docs theme allows a project to
> > > include links to several older versions to switch between them,
> > > too, so users who land on the "wrong" version can switch. We could
> > > update that to include branches as well as tags, so that someone
> > > can easily move to the series they need without knowing the version
> > > number.
> > [...]
> > 
> > The biggest liability is people not realizing there are multiple
> > "versions" of OpenStack finding an old install doc and using it
> > because they don't know it's out of date, then seeking support
> > upstream or just generally contributing to the number of deployments
> > unnecessarily stuck on obsolete software. The current solution of
> > not publishing installation guides for EOL releases seems like a
> > good enough compromise there to me.
> 
> That content will now live in the project trees. Perhaps part of marking
> branches in those repos EOL needs to include deleting the install tree
> from the docs? Now that the docs are in a standard location, that could
> be part of an EOL script (although it means 2 phases, since we have to
> land the patch and let the docs rebuild before we remove the branch).
> 
> We could also update the openstack-manuals tree to not publish links
> to the install guides (either removing the page or replacing it
> with a placeholder that explains they should be trying to use a
> newer version).
> 
> Doug
> 

Today we're publishing series-specific (e.g., newton) and
version-specific (e.g., 10.0.0) docs. I wonder if we should stop
publishing docs when we tag repositories, and just stick to the
series? There's no way to go back and update those version-specific
builds after the fact, so we can't remove the installation guides
and we can't rebuild them easily if there are security issues with
the content.

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] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

Excerpts from Jeremy Stanley's message of 2017-07-27 21:56:35 +:
> On 2017-07-27 15:40:22 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > Regarding point 2, if we don't have the space to host the content
> > indefinitely, then we need to set a fixed, but longer, retention
> > period before deleting it.  Several years, at least. In the mean
> > time, we could delete builds for intermediate versions (maybe if
> > we have 10.0.0, 10.1.0, and 10.1.1 we only need to keep 10.1.1, for
> > example).  The point is that there are ways to remove some content
> > without removing it all. I know space used to be a real problem
> > when we were hosting on CloudSites, but maybe someone from the infra
> > team can give us some insight into how significant the space issue
> > is today?
> [...]
> 
> The current content for all of docs.openstack.org weighs in at
> roughly 11GiB on disk. I'm not surprised that was a massive Web site
> by CloudSites' standards, but compared to the ~11TiB we host for
> just two months of CI job logs it's a 1ml drop in a liter bucket.

Excellent, so we don't need to worry about space, for now.

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] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

Excerpts from Jeremy Stanley's message of 2017-07-27 22:07:33 +:
> On 2017-07-27 15:40:22 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > Are we over-emphasizing the scale of the discovery problem?
> > 
> > When I search for how to install a package on Ubuntu (or Red Hat
> > or Debian for that matter), I find all sorts of references all over
> > the web (including on the sites for those distros) and I have to
> > sift through it all to find right command or package name to use
> > for my version.  Usually the easiest way to do that is to put the
> > version in the search query.
> > 
> > Are our users incapable of finding the right version of a document
> > if we clearly mark the version to which each document applies? Every
> > URL now has a release series name or version tag in the path. The
> > docs theme inserts the version number into every page as well. Is
> > that sufficient to help a reader understand what version the info
> > they're view is for?
> > 
> > That's not to say we shouldn't do some work to make newer docs easy
> > to find. If we can modify the sitemap to make them appear earlier
> > in search results, that's good. The docs theme allows a project to
> > include links to several older versions to switch between them,
> > too, so users who land on the "wrong" version can switch. We could
> > update that to include branches as well as tags, so that someone
> > can easily move to the series they need without knowing the version
> > number.
> [...]
> 
> The biggest liability is people not realizing there are multiple
> "versions" of OpenStack finding an old install doc and using it
> because they don't know it's out of date, then seeking support
> upstream or just generally contributing to the number of deployments
> unnecessarily stuck on obsolete software. The current solution of
> not publishing installation guides for EOL releases seems like a
> good enough compromise there to me.

That content will now live in the project trees. Perhaps part of marking
branches in those repos EOL needs to include deleting the install tree
from the docs? Now that the docs are in a standard location, that could
be part of an EOL script (although it means 2 phases, since we have to
land the patch and let the docs rebuild before we remove the branch).

We could also update the openstack-manuals tree to not publish links
to the install guides (either removing the page or replacing it
with a placeholder that explains they should be trying to use a
newer version).

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] Broken nova-lxd

2017-07-27 Thread Michael Still

Hi,

I'm cc'ing openstack-dev because your email is the same as the comment you
made on the relevant review, and I think getting visibility with the wider
Nova team is a good idea.

Unfortunately this is a risk of having an out of tree Nova driver, which
has never been the recommended path for implementing drivers for Nova.
Being out of tree isn't forbidden, but it does come with the cost of
staying up to date with Nova and handling changes as they occur.

In this case, if you look at the review chain you'll see that the move is a
pre-cursor to moving this code to use oslo.privsep. Unless lxd is going to
move to privsep in lockstep with nova, your best bet would be to duplicate
this utility method in the nova-lxd codebase.

Michael

On Thu, Jul 27, 2017 at 11:25 PM, Kharkov Alexander <
kharkovalexan...@gmail.com> wrote:

> Hi, Michael
> I recently found that you commit to nova break nova-lxd driver
> functionality because it utilizes last_bytes function from nova/utils.py
> which you recently move to libvirt. Could you please confirm that it was
> not expected and suggest a fix? I'm currently working on nova-lxd now and
> want to have functioning unit tests to pull my changes for review.
> Your commit and review links below:
> https://git.openstack.org/cgit/openstack/nova/commit/?id=
> 2341a41eaee5152e95379e5ed38012270af82ef5
> https://review.openstack.org/#/c/472228/9
> ...
> Failed nova-lxd
> ...
>
> Failed 1 tests - output below:
>
> ==
>
>
> test_driver.LXDDriverTest.test_get_console_output
>
> -
>
>
> Captured traceback:
>
> ~~~
>
> b'Traceback (most recent call last):'
>
> b'  File 
> "/home/ubuntu/nova-lxd/.tox/py35/lib/python3.5/site-packages/mock/mock.py",
> line 1305, in patched'
>
> b'return func(*args, **keywargs)'
>
> b'  File "/home/ubuntu/nova-lxd/nova/tests/unit/virt/lxd/test_driver.py",
> line 604, in test_get_console_output'
>
> b'contents = lxd_driver.get_console_output(context, instance)'
>
> b'  File "/home/ubuntu/nova-lxd/nova/virt/lxd/driver.py", line 594,
> in get_console_output'
>
> b'log_data, _ = utils.last_bytes(f, MAX_CONSOLE_BYTES)'
>
> b"AttributeError: module 'nova.utils' has no attribute 'last_bytes'"
>
> b''
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

On 2017-07-27 15:40:22 -0400 (-0400), Doug Hellmann wrote:
[...]
> Are we over-emphasizing the scale of the discovery problem?
> 
> When I search for how to install a package on Ubuntu (or Red Hat
> or Debian for that matter), I find all sorts of references all over
> the web (including on the sites for those distros) and I have to
> sift through it all to find right command or package name to use
> for my version.  Usually the easiest way to do that is to put the
> version in the search query.
> 
> Are our users incapable of finding the right version of a document
> if we clearly mark the version to which each document applies? Every
> URL now has a release series name or version tag in the path. The
> docs theme inserts the version number into every page as well. Is
> that sufficient to help a reader understand what version the info
> they're view is for?
> 
> That's not to say we shouldn't do some work to make newer docs easy
> to find. If we can modify the sitemap to make them appear earlier
> in search results, that's good. The docs theme allows a project to
> include links to several older versions to switch between them,
> too, so users who land on the "wrong" version can switch. We could
> update that to include branches as well as tags, so that someone
> can easily move to the series they need without knowing the version
> number.
[...]

The biggest liability is people not realizing there are multiple
"versions" of OpenStack finding an old install doc and using it
because they don't know it's out of date, then seeking support
upstream or just generally contributing to the number of deployments
unnecessarily stuck on obsolete software. The current solution of
not publishing installation guides for EOL releases seems like a
good enough compromise there to me.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

On 2017-07-27 15:40:22 -0400 (-0400), Doug Hellmann wrote:
[...]
> Regarding point 2, if we don't have the space to host the content
> indefinitely, then we need to set a fixed, but longer, retention
> period before deleting it.  Several years, at least. In the mean
> time, we could delete builds for intermediate versions (maybe if
> we have 10.0.0, 10.1.0, and 10.1.1 we only need to keep 10.1.1, for
> example).  The point is that there are ways to remove some content
> without removing it all. I know space used to be a real problem
> when we were hosting on CloudSites, but maybe someone from the infra
> team can give us some insight into how significant the space issue
> is today?
[...]

The current content for all of docs.openstack.org weighs in at
roughly 11GiB on disk. I'm not surprised that was a massive Web site
by CloudSites' standards, but compared to the ~11TiB we host for
just two months of CI job logs it's a 1ml drop in a liter bucket.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [release] nominating Sean McGinnis for releases-core

2017-07-27 Thread Tony Breeds

On Thu, Jul 27, 2017 at 11:14:51AM -0400, Doug Hellmann wrote:
> Sean has been increasingly active with the release team this cycle, and
> wants to contribute. I think we should go ahead and add him to the
> releases-core group.
> 
> Please respond +1/-1.

+1

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] [all][docs] 404s on docs website after the great reorg

Excerpts from Doug Hellmann's message of 2017-07-27 14:24:53 -0400:
> Excerpts from Jeremy Stanley's message of 2017-07-27 16:40:08 +:
> > On 2017-07-27 12:23:39 -0400 (-0400), Sean Dague wrote:
> > > In the #openstack-nova channel this morning we were debugging some cells
> > > v2 things, and ran into the fact that the online docs for this -
> > > https://docs.openstack.org/nova/latest/cells.html go to a 404. That's a
> > > previously well known link, people have it in their browser history,
> > > bookmarks, wiki pages, other websites.
> > > 
> > > My understanding of big moves like this is that redirects are important.
> > > Things going blackhole like that not only is an inconvenience to users,
> > > but impacts our search engine rankings, and takes a while for them to
> > > all sift out. I know in sites I run I'm still regularly getting in
> > > bounds to paths on the site that haven't been there for 8 years.
> > > 
> > > It would be really good if we had a way (manual or automated) to have
> > > 301 redirects, that are fixable by the teams that now own the
> > > documentation (the project teams).
> > 
> > We can look at including .htaccess files in the tree I guess? Or
> > some metadata the publish job uses to build them maybe?
> 
> That's exactly what I was thinking.
> 
> 1. Enable .htaccess files by turning on allowoverride for
>docs.openstack.org.
> 
> 2. Add .htaccess files in each tree, as needed (see
>https://review.openstack.org/487932 for an example of how this
>is done with sphinx).
> 
> 3. Update the main .htaccess file in openstack-manuals to redirect
>from the old location of docs in a way that passes the full path.
>Right now we redirect to /project/latest/:
> 
>   redirectmatch 301 "^/developer/([^/]+)/.*$" /$1/latest/
> 
>I think that would change to look something like:
> 
>   redirectmatch 301 "^/developer/([^/]+)/(.*)$" /$1/latest/$2
> 
>We would only want to do that for projects that actually have
>.htaccess files, so we can put a flag in the project-data files in
>openstack-manuals and generate project-specific redirect rules (we're
>already doing that for some other pages).
> 
> Then when someone visits docs.o.o/developer/nova/cells.html it would
> redirect to docs.o.o/nova/latest/cells.html. The nova team then
> need to have a redirect from docs.o.o/nova/latest/cells.html to
> docs.o.o/nova/latest/user/cells.html.
> 
> If folks think that's a good approach, I will start on the patches
> needed in infra and openstack-manuals (1 and 3).
> 
> Doug
> 

The patches are up using the topic in-tree-redirects:

https://review.openstack.org/#/q/topic:in-tree-redirects

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

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Moving a thread from the openstack-docs list [1] to this list for
broader input.]

[1] http://lists.openstack.org/pipermail/openstack-docs/2017-July/010069.html

Excerpts from 's message of 2017-07-26 07:42:38 -0400:
> Yesterday was a very busy day on IRC, with the discussion about the
> strategy and future maintenance of the documentation for the EOL
> releases coming back to the front.
> 
> I've promised to summarize some of what we discussed, for those who
> weren't there, and sketch out some of the fenceposts along our path forward.
> 
> Summary:
> The main issue, is that when an OpenStack release goes EOL, the branch
> in the main repository goes away, and with it go the docs, which then
> vanish from the public-facing website.
> 
> This has been an open gap for awhile, but only recently became a pain
> point for many operators. I think we can all agree that this is an
> issue, so the "Why should we fix this?" isn't as important as "HOW do we
> fix this?"

Yes, as I said on IRC, I think we have reached a point where enough of
our user base is trailing far enough behind that we need to rethink our
documentation retention policy to make sure we're meeting everyone's
needs.

> This leaves any sites, operators or installations that may be using
> those releases, without any tangible way to research how to install,
> manage or maintain those in-place installations and releases.
> 
> For companies like Canonical, we support OpenStack on Ubuntu LTS
> releases beyond the upstream EOL date of those point releases
> themselves. Other distributions may have a similar gap with the docs
> vanishing before their support of those releases sunsets.
> 
> Ideally, docs should be managed and maintained at the upstream project
> site, not at each disribution's own domain. I'd like to avoid having a
> Canonical version, a Red Hat version, an Oracle version, etc. all with
> the same patches to build local copies staged on our respective domains.
> 
> I've recently put some effort into automating and patching off the older
> versions of the docs based on the github tags, so they build in a local
> tree with mvn/tox, and that tree can be used internally by operators,
> but this should be viewed as a stopgap to a more strategic archiving
> solution for these docs.
> 
> There is an archiving plan[0] that has been discussed, but with the -doc
> team resources being thinned out, there is very little "spare" resources
> to put towards this effort. There's been some discussion[1],[2] to try
> to bring this to the front, but it too suffers from time and resources.
> 
> There are a few key problems/challenges/questions with solving this in a
> repeatable, strategic way:
> 
> * The branches are gone so there's no way to "update" these eol docs,
>   patch them to build, or maintain them going forward for those eol
>   releases.
> 
>   * Should the eol docs be pulled out and put into their own separate
> github repo, where they _can_ be patched and maintained so they
> continue to be buildable and usable by those with the correct
> tools and environment?
>
>   * There's been talk about pulling the docs into a community-
> maintained 'wiki', for ongoing maintenance, but that opens more
> questions too (who should host it? who 'owns' it? who gets write
> vs. read access? etc.)

As Jeremy pointed out on the docs list, this doesn't really help. Moving
the content won't give us more maintainers. I don't think we want to
enable "maintenance" of the docs as such, though. I think we just want
to make them available as they are for users to find. This week we made
some progress there, so that now docs.openstack.org has a landing page
for every series (for example https://docs.openstack.org/austin/).

For the series where docs still existed on the server, we added
links. The earliest release with any docs available was Icehouse.
We have progressively more material as you look at more recent
releases.

> * Where should the docs ultimately "live", until they're truly eol for
>   all parties concerned, and what should that timeline be? 3 years
>   past eol? 5 years? Indefinitely?
> 
>   * We discussed something like: docs.o.o/eol_$release or similar
> indicator to differentiate the 'current' docs from the
> archived/eol docs.
> 
> * Should the docs for eol releases be made available in PDF only
>   format, or indexable/searchable HTML format? There are pros and
>   cons for using either approach, this might need more thought.

I think we want to take a "less is more" approach here. When we had
lots of contributors working on the docs, it made sense to ask them
to do things that I think we can't afford to do any more. So rather
than looking for a new way to do something, let's see if we can
*stop* doing work and achieve more.

My proposal is to put the documentation on docs.openstack.org and
leave it there indefinitely.

Leaving the docs where they are avoids a ton of work to build
archiving systems and f

Re: [openstack-dev] [oslo.db] [ndb] ndb namespace throughout openstack projects

2017-07-27 Thread Octave J. Orgeron


Hi Jay,

Comments below..

I apologize for being a bit verbose, but I know some folks on the list 
are not familiar with NDB, so I do go into some details below.


Thanks,
Octave

On 7/27/2017 11:49 AM, Jay Pipes wrote:

I guess we're really getting into the weeds here.

On 07/27/2017 12:51 PM, Octave J. Orgeron wrote:

Hi Jay,

Comments below..

On 7/26/2017 5:43 PM, Jay Pipes wrote:

On 07/26/2017 07:06 PM, Octave J. Orgeron wrote:

Hi Michael,

On 7/26/2017 4:28 PM, Michael Bayer wrote:


it at all.
thinking out loud

oslo_db.sqlalchemy.types.String(255, mysql_small_rowsize=64)
oslo_db.sqlalchemy.types.String(255, mysql_small_rowsize=sa.TINYTEXT)
oslo_db.sqlalchemy.types.String(255, mysql_small_rowsize=sa.TEXT)


so if you don't have mysql_small_rowsize,  nothing happens.



I think the mysql_small_rowsize is a bit misleading since in one 
case we are changing the size and the others the type. Perhaps:


mysql_alt_size=64
mysql_alt_type=sa.TINYTEXT
mysql_alt_type=sa.TEXT

alt standing for alternate. What do you think?


-1

I think it should be specific to NDB, since that's what the override 
is for. I'd support something like:


 oslo_db.sqlalchemy.types.String(255, mysql_ndb_size=64)

Octave, I understand due to the table row size limitations the 
desire to reduce some column sizes for NDB. What I'm not entirely 
clear on is the reason to change the column *type* specifically for 
NDB. There are definitely cases where different databases have 
column types -- say, PostgreSQL's INET column type -- that don't 
exist in other RDBMS. For those cases, the standard approach in 
SQLAlchemy is to create a sqlalchemy ColumnType concrete class that 
essentially translates the CREATE TABLE statement (and type 
compilation/coercing) to specify the supported column type in the 
RDBMS if it's supported otherwise defaults the column type to 
something coerceable.


When it comes to changing the size or the type for a column for NDB, 
this has to do with the difference in the table row limits. InnoDB 
limits to 65k and NDB limits to 14k. You can't cross those limits in 
either engine because it's used as part of the internal storage 
engine and affects things like replication constraints, memory 
alignment, etc.


Yes, I'm aware of those constraints, though you are incorrect about 
InnoDB.


InnoDB's row size limit is actually not 65K. It is dependent on the 
innodb_page_size value. At the default innodb_page_size value of 16KB, 
the max row size is 8KB. It is MySQL, not InnoDB, that places a max 
row size of 64KB which limits row size when innodb_page_size is set to 
a large value.


The row limit and the page size value are definitely related and if the 
page size isn't configured, you can run into the limit faster:


https://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html#row-size-limits



However, it is important to point out that InnoDB's max row size 
*doesn't* include the size of BLOB-based *data*, only a pointer to 
that data on disk. *Nor* does InnoDB count VARCHAR/VARBINARY columns' 
size in its maximum row size calculations. A VARCHAR(9000) column in 
InnoDB is perfectly acceptable. [1]


NDB, on the other hand, isn't a MySQL storage engine in the way that 
InnoDB is [2]. :) It's a completely different database system that is 
designed for in-memory-only use, though support for TEXT and BLOB 
columns in disk-backed cluster nodes is supported now.


By default these days, NDB will back-end everything to disk. You are 
right that it's in-memory first and sync'd across nodes. NDB storage 
nodes that own the data bits for a given data blob then sync that to 
disk. It's a two phase commit model. Very different from the InnoDB model.




NDB always stores the first 256 bytes of the BLOB/TEXT data plus an 
8-byte pointer to disk table data. This is in contrast to InnoDB which 
just stores a pointer to the data [2]. VARCHAR/VARBINARY data in 
InnoDB is different. While InnoDB will try to fit some amount of the 
VARCHAR data in the row itself before automatically overflowing the 
data to a pointer to a separate data page, NDB, on the other hand, 
treats VARCHAR/VARBINARY is fixed-size columns.


This is the big difference between the two systems and why you are 
changing some columns to the TEXT type.


[1] mysql> use test
Database changed
mysql> show variables like 'innodb_page_size';
+--+---+
| Variable_name| Value |
+--+---+
| innodb_page_size | 16384 |
+--+---+
1 row in set (0.02 sec)

mysql> create table t1 (a VARCHAR(9000));
Query OK, 0 rows affected (0.02 sec)


If you look in the link below, you'll see that if you go over the 65k 
limit with InnoDB, you'll run into the same problem as NDB:


https://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html#row-size-limits

mysql> CREATE TABLE t (a VARCHAR(1), b VARCHAR(1),
   c VARCHAR(1), d VARCHAR(1), e VARCHAR(1),
   f VARCHAR(1), g VARCHAR(6000)) ENGI

Re: [openstack-dev] [relmgt] Non-candidacy for the Queens cycle Release management PTL

2017-07-27 Thread Matthew Thode

On 17-07-27 11:26:18, Steven Dake wrote:
> On Thu, Jul 27, 2017 at 6:58 AM, Doug Hellmann 
> wrote:
> 
> > Excerpts from Sean McGinnis's message of 2017-07-27 08:45:16 -0500:
> > > >
> > > > I have multiple reasons for not running this cycle. First, as part of
> > my
> > > > expanded role at the Foundation my travel commitments increased a bit.
> > > > The Release management PTL role requires regular work: I ended up doing
> > > > a relatively bad job at PTLing this cycle, by being away during a
> > number
> > > > of critical weeks. Fortunately, I could count on the presence of the
> > > > other team members (especially dhellmann and dims) to keep things under
> > > > control!
> > >
> > > Thank you Thierry and team for the great work. Depite what you say, I
> > > don't think anyone has felt the impact, so - great job!
> > >
> > > Sean
> > >
> >
> > +1 to that -- With your guidance we have solidified the processes
> > the team uses so well that we can all share the load. That's exactly
> > the sort of situation we need for all of our cross-project teams.
> >
> > Doug
> >
> >
> +2
> 
> The release management team has managed to automate and nearly fully
> distribute the workload across the various teams working on OpenStack
> projects and their deliverables.
> 
> A huge improvement from where PTLs in Mitaka and prior were manually
> tagging and signing deliverables, handling the release note process, and
> all other sorts of minutia that required extreme care and focus.
> 
> A fine example of cross project team collaboration.
> 
> Regards
> -steve
> 
> 

Agreed on all points, working with Thierry has been a lesson in how to
handle the complexity of working across projects.  Good luck with your
continuing work.

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] [vitrage] New Vitrage releases

2017-07-27 Thread Afek, Ifat (Nokia - IL/Kfar Sava)

Hi,

We have new releases for Vitrage:
vitrage 1.7.0
python-vitrgeclient 1.3.0
vitrage-dashboard 1.3.0

For python-vitrageclient this is the final Pike release, as today is the final 
release date for client libraries. A stable/pike branch was created for 
critical bug fixes. The master branch can be used for Queens development only.
Regarding vitrage and vitrage-dashboard, we can continue working on the master 
branches for now and finish the Pike development.

Best Regards,
Ifat.


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

Re: [openstack-dev] [all][docs] 404s on docs website after the great reorg

On Thu, Jul 27, 2017 at 2:24 PM, Doug Hellmann  wrote:
> Excerpts from Jeremy Stanley's message of 2017-07-27 16:40:08 +:
>> On 2017-07-27 12:23:39 -0400 (-0400), Sean Dague wrote:
>> > In the #openstack-nova channel this morning we were debugging some cells
>> > v2 things, and ran into the fact that the online docs for this -
>> > https://docs.openstack.org/nova/latest/cells.html go to a 404. That's a
>> > previously well known link, people have it in their browser history,
>> > bookmarks, wiki pages, other websites.
>> >
>> > My understanding of big moves like this is that redirects are important.
>> > Things going blackhole like that not only is an inconvenience to users,
>> > but impacts our search engine rankings, and takes a while for them to
>> > all sift out. I know in sites I run I'm still regularly getting in
>> > bounds to paths on the site that haven't been there for 8 years.
>> >
>> > It would be really good if we had a way (manual or automated) to have
>> > 301 redirects, that are fixable by the teams that now own the
>> > documentation (the project teams).
>>
>> We can look at including .htaccess files in the tree I guess? Or
>> some metadata the publish job uses to build them maybe?
>
> That's exactly what I was thinking.
>
> 1. Enable .htaccess files by turning on allowoverride for
>docs.openstack.org.
>
> 2. Add .htaccess files in each tree, as needed (see
>https://review.openstack.org/487932 for an example of how this
>is done with sphinx).
>
> 3. Update the main .htaccess file in openstack-manuals to redirect
>from the old location of docs in a way that passes the full path.
>Right now we redirect to /project/latest/:
>
>   redirectmatch 301 "^/developer/([^/]+)/.*$" /$1/latest/
>
>I think that would change to look something like:
>
>   redirectmatch 301 "^/developer/([^/]+)/(.*)$" /$1/latest/$2
>
>We would only want to do that for projects that actually have
>.htaccess files, so we can put a flag in the project-data files in
>openstack-manuals and generate project-specific redirect rules (we're
>already doing that for some other pages).
>
> Then when someone visits docs.o.o/developer/nova/cells.html it would
> redirect to docs.o.o/nova/latest/cells.html. The nova team then
> need to have a redirect from docs.o.o/nova/latest/cells.html to
> docs.o.o/nova/latest/user/cells.html.
>
> If folks think that's a good approach, I will start on the patches
> needed in infra and openstack-manuals (1 and 3).

Sounds like good plan Doug. Thanks!

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



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

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

Re: [openstack-dev] [relmgt] Non-candidacy for the Queens cycle Release management PTL

2017-07-27 Thread Steven Dake

On Thu, Jul 27, 2017 at 6:58 AM, Doug Hellmann 
wrote:

> Excerpts from Sean McGinnis's message of 2017-07-27 08:45:16 -0500:
> > >
> > > I have multiple reasons for not running this cycle. First, as part of
> my
> > > expanded role at the Foundation my travel commitments increased a bit.
> > > The Release management PTL role requires regular work: I ended up doing
> > > a relatively bad job at PTLing this cycle, by being away during a
> number
> > > of critical weeks. Fortunately, I could count on the presence of the
> > > other team members (especially dhellmann and dims) to keep things under
> > > control!
> >
> > Thank you Thierry and team for the great work. Depite what you say, I
> > don't think anyone has felt the impact, so - great job!
> >
> > Sean
> >
>
> +1 to that -- With your guidance we have solidified the processes
> the team uses so well that we can all share the load. That's exactly
> the sort of situation we need for all of our cross-project teams.
>
> Doug
>
>
+2

The release management team has managed to automate and nearly fully
distribute the workload across the various teams working on OpenStack
projects and their deliverables.

A huge improvement from where PTLs in Mitaka and prior were manually
tagging and signing deliverables, handling the release note process, and
all other sorts of minutia that required extreme care and focus.

A fine example of cross project team collaboration.

Regards
-steve


> __
> OpenStack Development Mailing 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] [all][docs] 404s on docs website after the great reorg

Excerpts from Jeremy Stanley's message of 2017-07-27 16:40:08 +:
> On 2017-07-27 12:23:39 -0400 (-0400), Sean Dague wrote:
> > In the #openstack-nova channel this morning we were debugging some cells
> > v2 things, and ran into the fact that the online docs for this -
> > https://docs.openstack.org/nova/latest/cells.html go to a 404. That's a
> > previously well known link, people have it in their browser history,
> > bookmarks, wiki pages, other websites.
> > 
> > My understanding of big moves like this is that redirects are important.
> > Things going blackhole like that not only is an inconvenience to users,
> > but impacts our search engine rankings, and takes a while for them to
> > all sift out. I know in sites I run I'm still regularly getting in
> > bounds to paths on the site that haven't been there for 8 years.
> > 
> > It would be really good if we had a way (manual or automated) to have
> > 301 redirects, that are fixable by the teams that now own the
> > documentation (the project teams).
> 
> We can look at including .htaccess files in the tree I guess? Or
> some metadata the publish job uses to build them maybe?

That's exactly what I was thinking.

1. Enable .htaccess files by turning on allowoverride for
   docs.openstack.org.

2. Add .htaccess files in each tree, as needed (see
   https://review.openstack.org/487932 for an example of how this
   is done with sphinx).

3. Update the main .htaccess file in openstack-manuals to redirect
   from the old location of docs in a way that passes the full path.
   Right now we redirect to /project/latest/:

  redirectmatch 301 "^/developer/([^/]+)/.*$" /$1/latest/

   I think that would change to look something like:

  redirectmatch 301 "^/developer/([^/]+)/(.*)$" /$1/latest/$2

   We would only want to do that for projects that actually have
   .htaccess files, so we can put a flag in the project-data files in
   openstack-manuals and generate project-specific redirect rules (we're
   already doing that for some other pages).

Then when someone visits docs.o.o/developer/nova/cells.html it would
redirect to docs.o.o/nova/latest/cells.html. The nova team then
need to have a redirect from docs.o.o/nova/latest/cells.html to
docs.o.o/nova/latest/user/cells.html.

If folks think that's a good approach, I will start on the patches
needed in infra and openstack-manuals (1 and 3).

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] [oslo.db] [ndb] ndb namespace throughout openstack projects

2017-07-27 Thread Jay Pipes


I guess we're really getting into the weeds here.

On 07/27/2017 12:51 PM, Octave J. Orgeron wrote:

Hi Jay,

Comments below..

On 7/26/2017 5:43 PM, Jay Pipes wrote:

On 07/26/2017 07:06 PM, Octave J. Orgeron wrote:

Hi Michael,

On 7/26/2017 4:28 PM, Michael Bayer wrote:


it at all.
thinking out loud

oslo_db.sqlalchemy.types.String(255, mysql_small_rowsize=64)
oslo_db.sqlalchemy.types.String(255, mysql_small_rowsize=sa.TINYTEXT)
oslo_db.sqlalchemy.types.String(255, mysql_small_rowsize=sa.TEXT)


so if you don't have mysql_small_rowsize,  nothing happens.



I think the mysql_small_rowsize is a bit misleading since in one case 
we are changing the size and the others the type. Perhaps:


mysql_alt_size=64
mysql_alt_type=sa.TINYTEXT
mysql_alt_type=sa.TEXT

alt standing for alternate. What do you think?


-1

I think it should be specific to NDB, since that's what the override 
is for. I'd support something like:


 oslo_db.sqlalchemy.types.String(255, mysql_ndb_size=64)

Octave, I understand due to the table row size limitations the desire 
to reduce some column sizes for NDB. What I'm not entirely clear on is 
the reason to change the column *type* specifically for NDB. There are 
definitely cases where different databases have column types -- say, 
PostgreSQL's INET column type -- that don't exist in other RDBMS. For 
those cases, the standard approach in SQLAlchemy is to create a 
sqlalchemy ColumnType concrete class that essentially translates the 
CREATE TABLE statement (and type compilation/coercing) to specify the 
supported column type in the RDBMS if it's supported otherwise 
defaults the column type to something coerceable.


When it comes to changing the size or the type for a column for NDB, 
this has to do with the difference in the table row limits. InnoDB 
limits to 65k and NDB limits to 14k. You can't cross those limits in 
either engine because it's used as part of the internal storage engine 
and affects things like replication constraints, memory alignment, etc.


Yes, I'm aware of those constraints, though you are incorrect about InnoDB.

InnoDB's row size limit is actually not 65K. It is dependent on the 
innodb_page_size value. At the default innodb_page_size value of 16KB, 
the max row size is 8KB. It is MySQL, not InnoDB, that places a max row 
size of 64KB which limits row size when innodb_page_size is set to a 
large value.


However, it is important to point out that InnoDB's max row size 
*doesn't* include the size of BLOB-based *data*, only a pointer to that 
data on disk. *Nor* does InnoDB count VARCHAR/VARBINARY columns' size in 
its maximum row size calculations. A VARCHAR(9000) column in InnoDB is 
perfectly acceptable. [1]


NDB, on the other hand, isn't a MySQL storage engine in the way that 
InnoDB is [2]. :) It's a completely different database system that is 
designed for in-memory-only use, though support for TEXT and BLOB 
columns in disk-backed cluster nodes is supported now.


NDB always stores the first 256 bytes of the BLOB/TEXT data plus an 
8-byte pointer to disk table data. This is in contrast to InnoDB which 
just stores a pointer to the data [2]. VARCHAR/VARBINARY data in InnoDB 
is different. While InnoDB will try to fit some amount of the VARCHAR 
data in the row itself before automatically overflowing the data to a 
pointer to a separate data page, NDB, on the other hand, treats 
VARCHAR/VARBINARY is fixed-size columns.


This is the big difference between the two systems and why you are 
changing some columns to the TEXT type.


[1] mysql> use test
Database changed
mysql> show variables like 'innodb_page_size';
+--+---+
| Variable_name| Value |
+--+---+
| innodb_page_size | 16384 |
+--+---+
1 row in set (0.02 sec)

mysql> create table t1 (a VARCHAR(9000));
Query OK, 0 rows affected (0.02 sec)

[2] This is the reason NDB isn't listed under "Alternative Storage 
Engines" in the MySQL documentation...


Because we are dealing with an issue of row length within the table, the 
best way to work around this is to do one of the following.. change the 
size of the column so that it fits, move the column to another table, 
split the table up, or to change it to a different type. The reason why 
this works is that TEXT types are stored as blobs in databases.


Please see my earlier response about the REST API -- at least in Nova -- 
unfortunately exposing certain input field length limitations. It's not 
possible to reduce certain column sizes without a corresponding 
microversion bump in the public API.



All database engines handle BLOBs differently than other types and as
a result they reduce the count against the row length. That's why I
change some of these columns to TEXT types.
As mentioned above, you are changing the column type because of the fact 
that NDB treats VARCHAR as fixed-length CHAR fields and counts the max 
VARCHAR size against the total row size, unlike InnoDB. It's an 
impor

Re: [openstack-dev] [keystone] Queens PTG Planning

2017-07-27 Thread Lance Bragstad

I've added a section to the etherpad [0] for attendees. We need to start
getting an idea of how many people plan on attending the PTG (for
scheduling purposes). Please add your name and IRC nick to the list.

Thanks

[0] https://etherpad.openstack.org/p/keystone-queens-ptg


On 07/05/2017 11:22 AM, Lance Bragstad wrote:
> Hey all,
>
> I've started an etherpad [0] for us to collect topics and ideas for the
> PTG in September. I hope to follow the same planning format as last
> time. Everyone has the opportunity to add topics to the agenda and after
> some time we'll group related topics and start building a formal schedule.
>
> The etherpad has two lists. One for project-specific topics and one for
> cross-project topics. As soon as we firm up the things we need to
> collaborate on with other projects, I'll start coordinating with other
> teams. These were the sessions we had to work around last time due to
> schedules. We can sprinkle the project related topics in to fill the gaps.
>
> Let me know if you have any questions.
>
> Thanks!
>
>
> [0] https://etherpad.openstack.org/p/keystone-queens-ptg
>
>




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

[openstack-dev] [all][api] POST /api-wg/news

2017-07-27 Thread michael mccune


Greetings OpenStack community,

Today's meeting continued the discussion about the newly posted gerrit 
review for the Guided Review Process[0]. There is still some work to be 
done before the process is in shape to announce for the Denver PTG, but 
the group is confident about having the process in place before the 
event. As we would like to host the first guided reviews in Denver, we 
also briefly discussed the sessions planned for the API-WG at the PTG 
which will be held on Monday and Tuesday.


There are no new guidelines for this week, but a few smaller typo fixes 
have been added for review[4][5] and will be merged soon(TM).


We also briefly discussed the version discovery gudelines proposed by 
mordred and he informed us about some great advances in the keystoneauth 
project that will support this work. Tangentially, he also mentioned 
some of the work happening around the os-service-types library and its 
1.0 release. This is really nice work and will help to advance the state 
of the art for using the service catalog effectively.


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and 
service discovery

  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address 
your concerns in an email to the OpenStack developer mailing list[1] 
with the tag "[api]" in the subject. In your email, you should include 
any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [2].


Thanks for reading and see you next week!

# References

[0] https://review.openstack.org/#/c/487847/
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[4] https://review.openstack.org/#/c/478638/
[5] https://review.openstack.org/#/c/487504/


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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] [ndb] ndb namespace throughout openstack projects

2017-07-27 Thread Octave J. Orgeron

Hi Jay,

Comments below..

On 7/26/2017 5:43 PM, Jay Pipes wrote:

On 07/26/2017 07:06 PM, Octave J. Orgeron wrote:

Hi Michael,

On 7/26/2017 4:28 PM, Michael Bayer wrote:

it at all.
thinking out loud

oslo_db.sqlalchemy.types.String(255, mysql_small_rowsize=64)
oslo_db.sqlalchemy.types.String(255, mysql_small_rowsize=sa.TINYTEXT)
oslo_db.sqlalchemy.types.String(255, mysql_small_rowsize=sa.TEXT)

so if you don't have mysql_small_rowsize, nothing happens.

I think the mysql_small_rowsize is a bit misleading since in one case
we are changing the size and the others the type. Perhaps:

mysql_alt_size=64
mysql_alt_type=sa.TINYTEXT
mysql_alt_type=sa.TEXT

alt standing for alternate. What do you think?

-1

I think it should be specific to NDB, since that's what the override
is for. I'd support something like:

oslo_db.sqlalchemy.types.String(255, mysql_ndb_size=64)

Octave, I understand due to the table row size limitations the desire
to reduce some column sizes for NDB. What I'm not entirely clear on is
the reason to change the column *type* specifically for NDB. There are
definitely cases where different databases have column types -- say,
PostgreSQL's INET column type -- that don't exist in other RDBMS. For
those cases, the standard approach in SQLAlchemy is to create a
sqlalchemy ColumnType concrete class that essentially translates the
CREATE TABLE statement (and type compilation/coercing) to specify the
supported column type in the RDBMS if it's supported otherwise
defaults the column type to something coerceable.

When it comes to changing the size or the type for a column for NDB,
this has to do with the difference in the table row limits. InnoDB
limits to 65k and NDB limits to 14k. You can't cross those limits in
either engine because it's used as part of the internal storage engine
and affects things like replication constraints, memory alignment, etc.

Because we are dealing with an issue of row length within the table, the
best way to work around this is to do one of the following.. change the
size of the column so that it fits, move the column to another table,
split the table up, or to change it to a different type. The reason why
this works is that TEXT types are stored as blobs in databases. All
database engines handle BLOBs differently than other types and as a
result they reduce the count against the row length. That's why I change
some of these columns to TEXT types. If you look closely through
services like Neutron, Barbican, Designate, Keystone, etc. you'll see
that they have hit the 65k limit in InnoDB on some tables and have had
to do the same thing. Realistically, any time you are storing something
like SSH keys, SSL certs, output from commands, etc. you should be using
the TEXT types anyways.

FYI, if you were talking about a large enterprise database for a bank or
retail shop, DBAs spend a lot of time designing tables and looking very
closely at the structure to ensure that they don't hit performance
problems, run out of row or table space, etc. They are extremely careful
about the usage of space. In some of the openstack projects, it's very
clear that we are wasting a lot of space and when tables get too wide,
they have to be rearranged and modified to deal with the limits and
constraints. So to put it into context for Nova, if any of the tables
are close to 65k in width, they will need to be modified or restructured
eventually.

Each database has structure limits:

https://www.postgresql.org/about/
https://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html
https://dev.mysql.com/doc/mysql-cluster-excerpt/5.7/en/mysql-cluster-limitations.html
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001029.html
https://docs.oracle.com/cloud/latest/db112/REFRN/limits003.htm#REFRN0043

If you dig through those, you'll see that each database has different
limits on things like columns, rows, sizes, indexes, etc. So this isn't
just an NDB constraint. If you want everything to work across InnoDB,
NDB, PostgreSQL, DB2, etc. we will have to deal with these table issues
eventually.

An example of this can be seen here for how this is done for IPv4 data
in the apiary project:

https://github.com/gmr/apiary/blob/master/apiary/types.py#L49

I'd certainly be open to doing things like this for NDB, but I'd first
need to understand why you chose to convert the column types for the
columns that you did. Any information you can provide about that would
be great.

Best,
-jay

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Un

Re: [openstack-dev] [release] nominating Sean McGinnis for releases-core

2017-07-27 Thread Thierry Carrez

Doug Hellmann wrote:
> Sean has been increasingly active with the release team this cycle, and
> wants to contribute. I think we should go ahead and add him to the
> releases-core group.
> 
> Please respond +1/-1.

+1!

-- 
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] [all] 404s on docs website after the great reorg

On 2017-07-27 12:23:39 -0400 (-0400), Sean Dague wrote:
> In the #openstack-nova channel this morning we were debugging some cells
> v2 things, and ran into the fact that the online docs for this -
> https://docs.openstack.org/nova/latest/cells.html go to a 404. That's a
> previously well known link, people have it in their browser history,
> bookmarks, wiki pages, other websites.
> 
> My understanding of big moves like this is that redirects are important.
> Things going blackhole like that not only is an inconvenience to users,
> but impacts our search engine rankings, and takes a while for them to
> all sift out. I know in sites I run I'm still regularly getting in
> bounds to paths on the site that haven't been there for 8 years.
> 
> It would be really good if we had a way (manual or automated) to have
> 301 redirects, that are fixable by the teams that now own the
> documentation (the project teams).

We can look at including .htaccess files in the tree I guess? Or
some metadata the publish job uses to build them maybe?
-- 
Jeremy Stanley


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

Re: [openstack-dev] [release] nominating Sean McGinnis for releases-core

+1 from me. Welcome to the team Sean!

On Thu, Jul 27, 2017 at 11:14 AM, Doug Hellmann  wrote:
> Sean has been increasingly active with the release team this cycle, and
> wants to contribute. I think we should go ahead and add him to the
> releases-core group.
>
> Please respond +1/-1.
>
> 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



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

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

[openstack-dev] [all] 404s on docs website after the great reorg

2017-07-27 Thread Sean Dague

In the #openstack-nova channel this morning we were debugging some cells
v2 things, and ran into the fact that the online docs for this -
https://docs.openstack.org/nova/latest/cells.html go to a 404. That's a
previously well known link, people have it in their browser history,
bookmarks, wiki pages, other websites.

My understanding of big moves like this is that redirects are important.
Things going blackhole like that not only is an inconvenience to users,
but impacts our search engine rankings, and takes a while for them to
all sift out. I know in sites I run I'm still regularly getting in
bounds to paths on the site that haven't been there for 8 years.

It would be really good if we had a way (manual or automated) to have
301 redirects, that are fixable by the teams that now own the
documentation (the project teams).

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [oslo.db] [ndb] ndb namespace throughout openstack projects

2017-07-27 Thread Octave J. Orgeron


Hi Jay,

There are number of other projects that are not using oslo.db for their 
migrations so that all of the flags and options are passed along. Good 
examples are things like Barbican, Murano, Glance, etc.


Thanks,
Octave

On 7/26/2017 5:26 PM, Jay Pipes wrote:

On 07/26/2017 07:01 PM, Octave J. Orgeron wrote:

Either way though, we'll have to ... still have to deal with any
migrations that don't make proper use of oslo.db.
Could you elaborate on the above? What about the Nova migrations 
aren't making proper use of oslo.db? Could you provide an example for us?


Best,
-jay

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [nova] hardware offload support for openvswitch feature exception

2017-07-27 Thread Moshe Levi

Thanks Matt,
I have create blueprint [1] 
and update the patch [2] with reno 

[1]  - https://blueprints.launchpad.net/nova/+spec/sriov-ovs-offload
 [2] https://review.openstack.org/#/c/398265/ 
-Original Message-
From: Matt Riedemann [mailto:mriede...@gmail.com] 
Sent: Thursday, July 27, 2017 4:56 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] hardware offload support for openvswitch 
feature exception

On 7/26/2017 10:42 PM, Moshe Levi wrote:
> Hi all,
> 
> In the last few week I was working on hardware offload support for 
> openvswitch.
> 
> The idea is to leverage SR-IOV technology with OVS control plane management.
> 
> Just last month the ovs community merged all the required patches to 
> enable this feature [1] should be in OVS-2.8.0.
> 
> I was working on the required patches to enable this in OpenStack.
> 
> On the neutron side the RFE approved [2] and the neutron patch is 
> already merged [3]
> 
> On the OS-VIF side the patch is merged [4]
> 
> On the Third party CI side we have a Mellanox CI which is currently 
> commenting on os-vif [5] ( we will extend it to nova and neutron as 
> well)
> 
> The missing piece is the nova patch [6]
> 
> I just notice that this week is feature freeze in OpenStack and I 
> would like to request an exception for this feature.
> 
> I will appreciate if nova-core reviewers will review it.
> 
> ( Jay , Sean and Jan already review it several times and I think it is 
> close to be merged)
> 
> [1] -
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com%2Fopenvswitch%2Fovs%2Fcommit%2Fbf090264e68d160d0ae70ebc93d59bc
> 09d34cc8b&data=02%7C01%7Cmoshele%40mellanox.com%7C34367f31900d4b4f32ed
> 08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636367605958
> 238772&sdata=m9YqwQa%2BQ5f83wDdlgvxurAr4Hv8Uz7Sxew8M9zQqh0%3D&reserved
> =0
> 
> 
> [2] - 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbug
> s.launchpad.net%2Fneutron%2F%2Bbug%2F1627987&data=02%7C01%7Cmoshele%40
> mellanox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4
> d149256f461b%7C0%7C0%7C636367605958238772&sdata=CJEYZcjl9W1FSO%2FznqnN
> KbAWyZrRuiAOs0RrBeyiUo0%3D&reserved=0
> 
> [3] - 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> iew.openstack.org%2F%23%2Fc%2F275616%2F&data=02%7C01%7Cmoshele%40mella
> nox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4d1492
> 56f461b%7C0%7C0%7C636367605958238772&sdata=JEnx0Xz3xcgyhMP7JJPDA2l5%2F
> pGCVVzzxSuA%2FjKHkLA%3D&reserved=0
> 
> [4] - 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> iew.openstack.org%2F%23%2Fc%2F460278%2F&data=02%7C01%7Cmoshele%40mella
> nox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4d1492
> 56f461b%7C0%7C0%7C636367605958238772&sdata=mASkZcJSSdWk0gZrNJf%2BFSlif
> L88xO6NkYPyeuPCHZg%3D&reserved=0
> 
> [5] -
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F52.1
> 69.200.208%2F25%2F485125%2F6%2Fcheck-os-vif%2FOVS_HW_offload%2Faaf2792
> %2F&data=02%7C01%7Cmoshele%40mellanox.com%7C34367f31900d4b4f32ed08d4d4
> f74ae3%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636367605958238772
> &sdata=zo1dZCVhq1pTMUvda0XnrYBVr2iC2XVeliWbN2Rb0yg%3D&reserved=0
> 
> [6] - 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> iew.openstack.org%2F%23%2Fc%2F398265%2F&data=02%7C01%7Cmoshele%40mella
> nox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4d1492
> 56f461b%7C0%7C0%7C636367605958238772&sdata=9cTQAVBzqUFPTZEI267SoZr%2B0
> %2BSj4OmNnIi7%2FV7dYgw%3D&reserved=0
> 
> 
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> s.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev&data=02
> %7C01%7Cmoshele%40mellanox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca6
> 52971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636367605958238772&sdata=JqCI
> iYYablV%2FflGV0I65oNJeWl7HHSFlYtk%2FvhaZ72g%3D&reserved=0
> 

Given everything else done here and the change in nova is (1) a single change 
and (2) self-contained and (3) relatively uncomplicated, I'm OK with this. 
Please create a blueprint in nova so we can track it as a feature since that's 
what it is.

-- 

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev&data=02%7C01%7Cmoshele%40mellanox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636367605958238772&sdata=JqCIiYYablV%2FflGV0I65oNJeWl7HHSFlYtk%2FvhaZ72

Re: [openstack-dev] [release] nominating Sean McGinnis for releases-core

On 2017-07-27 11:14:51 -0400 (-0400), Doug Hellmann wrote:
> Sean has been increasingly active with the release team this cycle, and
> wants to contribute. I think we should go ahead and add him to the
> releases-core group.
> 
> Please respond +1/-1.

I'm not a core reviewer on release management, but for what it's
worth I'm eager to see him be able to take on more responsibility
there if he's willing. Seems like a great fit!
-- 
Jeremy Stanley


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

Re: [openstack-dev] [oslo.db] [ndb] ndb namespace throughout openstack projects

proposed:

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

On Thu, Jul 27, 2017 at 9:46 AM, Michael Bayer  wrote:
> On Wed, Jul 26, 2017 at 8:06 PM, Jay Pipes  wrote:
>> Isn't that exactly what I'm proposing below? :)
>
> yes, I'm agreeing with you!

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

[openstack-dev] [release] nominating Sean McGinnis for releases-core

Sean has been increasingly active with the release team this cycle, and
wants to contribute. I think we should go ahead and add him to the
releases-core group.

Please respond +1/-1.

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] [Manila] Access rule types for protocols

2017-07-27 Thread Ben Swartzlander

Manila has a long standing design flaw that I'd like to address in 
Queens. We've discussed this as previous PTGs and will cover it in 
detail as the upcoming PTG but because of the potential for impacting 
users I wanted to bring it up here too.


In short, Manila allows potentially incompatible access rules to be 
added to shares. We handle this by allowing the driving to fail to apply 
the rule and reporting that error back to the user by marking the access 
rule as being in an error state.


This history of this design is that at the very beginning of the 
project, we didn't have a strong sense of what kind of access rules 
would be used in practice, or implemented by vendors, and we didn't want 
to design the API to limit what users were allowed to request. In 
retrospect, this attempt at flexibility was misguided because it's now 
very hard for users to know what is supported on any given cloud and we 
have a complete lack of standardization.


Informally, we've settled on the idea that each protocol has exactly 1 
access type that must be supported, and I'd like to formalize that 
notion by changing the API to enforce the agreed upon standard. This 
raises the specter of "backwards incompatibility" because such an API 
change would block requests that were previously allowed. My feeling 
about this specific case is that the requests were going to result in an 
error eventually, so making them result in an error earlier is an 
improvement.


The concern is whether there might be any legitimate cases for using the 
nonstandard access methods that could be broken by the proposed change. 
In particular, I'd like to know if anyone actually uses IP-based access 
for CIFS or User-based access for NFS and what that looks like -- in 
particular which driver and what is the use case for it. My current 
assumption is that these are effectively broken and removing them will 
hurt nobody. If legitimate cases can be found, then we need to find a 
way to support them in a more standardized, discoverable fashion.


-Ben Swartzlander

__
OpenStack Development Mailing 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] [relmgt] Non-candidacy for the Queens cycle Release management PTL

Totally agree Doug. Thanks for your all your efforts and guidance Thierry

On Thu, Jul 27, 2017 at 9:58 AM, Doug Hellmann  wrote:
> Excerpts from Sean McGinnis's message of 2017-07-27 08:45:16 -0500:
>> >
>> > I have multiple reasons for not running this cycle. First, as part of my
>> > expanded role at the Foundation my travel commitments increased a bit.
>> > The Release management PTL role requires regular work: I ended up doing
>> > a relatively bad job at PTLing this cycle, by being away during a number
>> > of critical weeks. Fortunately, I could count on the presence of the
>> > other team members (especially dhellmann and dims) to keep things under
>> > control!
>>
>> Thank you Thierry and team for the great work. Depite what you say, I
>> don't think anyone has felt the impact, so - great job!
>>
>> Sean
>>
>
> +1 to that -- With your guidance we have solidified the processes
> the team uses so well that we can all share the load. That's exactly
> the sort of situation we need for all of our cross-project teams.
>
> 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



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

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

Re: [openstack-dev] [oslo][oslo.db] nominating Jay Pipes for oslo-db-core

+1 from me!

On Thu, Jul 27, 2017 at 10:10 AM, Michael Bayer  wrote:
> Yeah if Jay has the time that's a big +1 from me!
>
> On Thu, Jul 27, 2017 at 10:04 AM, Doug Hellmann  wrote:
>> I have noticed that Jay has been very deeply involved in several
>> recent design discussions about oslo.db, and he obviously has a
>> great deal of experience in the area, so even though he hasn't been
>> actively reviewing patches recently I think he would be a good
>> addition to the team. I have asked him, and he is interested and will
>> try to become more active as well.
>>
>> Please indicate your opinion with +1/-1.
>>
>> 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



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

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

[openstack-dev] [Manila] Bug Squash Day - Wednesday Aug 2

2017-07-27 Thread Ben Swartzlander

We have planned a bug squash day coming up next week! The goal of this 
event is to get together and come up with a list of bugs that need 
squashing and to work together to fix as many as we can. The timing is 
right after feature freeze so if we're successful we can have a very 
strong impact on the RC1 release for Pike.


I encourage everyone in the community whether you're a developer, a 
user, a tester, or a deployer. We need people to help identify and 
prioritize bugs, which is easily as important as fixing the bugs.


Like many Manila events, the event will be virtual, organized on IRC 
with Webex for audio. There is an etherpad [1] with the event details 
which we will use the track the bugs, prioritize them, and assign people.


-Ben Swartzlander

[1] https://etherpad.openstack.org/p/pike-manila-bug-squash


__
OpenStack Development Mailing 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][oslo.db] nominating Jay Pipes for oslo-db-core

Yeah if Jay has the time that's a big +1 from me!

On Thu, Jul 27, 2017 at 10:04 AM, Doug Hellmann  wrote:
> I have noticed that Jay has been very deeply involved in several
> recent design discussions about oslo.db, and he obviously has a
> great deal of experience in the area, so even though he hasn't been
> actively reviewing patches recently I think he would be a good
> addition to the team. I have asked him, and he is interested and will
> try to become more active as well.
>
> Please indicate your opinion with +1/-1.
>
> 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] [all] [oslo.db] [relational database users] heads up for a MariaDB issue that will affect most projects

On Thu, Jul 27, 2017 at 3:23 AM, ChangBo Guo  wrote:
> Thanks for the follow up, maybe we need document the issue and work around
> in some place, in alembic?

So yes, there's a whole bunch implied by this:

1. SQLAlchemy knows how to reflect CHECK constraints.  Since MariaDB
supports these as of 10.2, SQLAlchemy itself would need to learn to
read these for MariaDB; on all MySQL/MariaDB versions right now there
is no logic to do this since CHECK constraints are not persisted.

The usual approach taken in Openstack migration scripts when they have
to navigate around constraints is to use inspector / reflection to
read things about constraints and indexes into the Python application,
make decisions, then emit statements as a result.This approach
would not be possible until SQLAlchemy implements this, or we add
helpers into oslo.db that do something similar.

2. Microsoft SQL Server has this same limitation, e.g. that you can't
drop a column that has a CHECK on it.   Over there, Alembic includes a
feature that generates SQL to detect the name of this constraint and
then drop the constraint of that name.  What is very useful about how
it is done in this case is that it is all within a server-side SQL
script that does the whole locate / drop without any round trips.   If
something similar could be implemented for MySQL/MariaDB, preferably
something that runs without error on all MySQL variants, it would be
just a simple bit of boilerplate that has to run before you drop a
column, and this is the kind of thing we could possibly bundle as a
"mysql_drop_check" flag for the drop_column() operation.

3. if the name of this CHECK constraint is known up front, it's much
easier to just emit "DROP CONSTRAINT xyz".   But it's not clear that
all openstack projects are sending out names for CHECK constraints in
particular the one that sneaks out when the Boolean datatype is used.
 Applying predictable names to the CHECK constraints retroactively of
course means you need to do something like #1 or #2 to find them.

4. *maybe* mariadb's CHECK constraint here already has a predictable
name.   I'd have to get a 10.2 instance running and see what it comes
up with.

>
> 2017-07-24 23:21 GMT+08:00 Michael Bayer :
>>
>> hey good news, the owner of the issue upstream found that the SQL
>> standard agrees with my proposed behavior.   So while this is current
>> MariaDB 10.2 / 10.3 behavior, hopefully it will be resolved in an
>> upcoming release within those series.   not sure of the timing though
>> so we may not be able to duck it.
>>
>> On Mon, Jul 24, 2017 at 11:16 AM, Michael Bayer  wrote:
>> > On Mon, Jul 24, 2017 at 10:37 AM, Doug Hellmann 
>> > wrote:
>> >> Excerpts from Michael Bayer's message of 2017-07-23 16:39:20 -0400:
>> >>> Hey list -
>> >>>
>> >>> It appears that MariaDB as of version 10.2 has made an enhancement
>> >>> that overall is great and fairly historic in the MySQL community,
>> >>> they've made CHECK constraints finally work.   For all of MySQL's
>> >>> existence, you could emit a CREATE TABLE statement that included CHECK
>> >>> constraint, but the CHECK phrase would be silently ignored; there are
>> >>> no actual CHECK constraints in MySQL.
>> >>>
>> >>> Mariadb 10.2 has now made CHECK do something!  However!  the bad news!
>> >>>  They have decided that the CHECK constraint against a single column
>> >>> should not be implicitly dropped if you drop the column [1].   In case
>> >>> you were under the impression your SQLAlchemy / oslo.db project
>> >>> doesn't use CHECK constraints, if you are using the SQLAlchemy Boolean
>> >>> type, or the "ENUM" type without using MySQL's native ENUM feature
>> >>> (less likely), there's a simple CHECK constraint in there.
>> >>>
>> >>> So far the Zun project has reported the first bug on Alembic [2] that
>> >>> they can't emit a DROP COLUMN for a boolean column.In [1] I've
>> >>> made my complete argument for why this decision on the MariaDB side is
>> >>> misguided.   However, be on the lookout for boolean columns that can't
>> >>> be DROPPED on some environments using newer MariaDB.  Workarounds for
>> >>> now include:
>> >>>
>> >>> 1. when using Boolean(), set create_constraint=False
>> >>>
>> >>> 2. when using Boolean(), make sure it has a "name" to give the
>> >>> constraint, so that later you can DROP CONSTRAINT easily
>> >>>
>> >>> 3. if not doing #1 and #2, in order to drop the column you need to use
>> >>> the inspector (e.g. from sqlalchemy import inspect; inspector =
>> >>> inspect(engine)) and locate all the CHECK constraints involving the
>> >>> target column, and then drop them by name.
>> >>
>> >> Item 3 sounds like the description of a helper function we could add to
>> >> oslo.db for use in migration scripts.
>> >
>> > OK let me give a little bit more context, that if MariaDB holds steady
>> > here, I will have to implement #3 within Alembic itself (though yes,
>> > for SQLAlchemy-migrate, still needed :) ). MS SQL Server has the
>> > same

[openstack-dev] [oslo][oslo.db] nominating Jay Pipes for oslo-db-core

I have noticed that Jay has been very deeply involved in several
recent design discussions about oslo.db, and he obviously has a
great deal of experience in the area, so even though he hasn't been
actively reviewing patches recently I think he would be a good
addition to the team. I have asked him, and he is interested and will
try to become more active as well.

Please indicate your opinion with +1/-1.

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] [relmgt] Non-candidacy for the Queens cycle Release management PTL

Excerpts from Sean McGinnis's message of 2017-07-27 08:45:16 -0500:
> > 
> > I have multiple reasons for not running this cycle. First, as part of my
> > expanded role at the Foundation my travel commitments increased a bit.
> > The Release management PTL role requires regular work: I ended up doing
> > a relatively bad job at PTLing this cycle, by being away during a number
> > of critical weeks. Fortunately, I could count on the presence of the
> > other team members (especially dhellmann and dims) to keep things under
> > control!
> 
> Thank you Thierry and team for the great work. Depite what you say, I
> don't think anyone has felt the impact, so - great job!
> 
> Sean
> 

+1 to that -- With your guidance we have solidified the processes
the team uses so well that we can all share the load. That's exactly
the sort of situation we need for all of our cross-project teams.

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] hardware offload support for openvswitch feature exception

2017-07-27 Thread Matt Riedemann


On 7/26/2017 10:42 PM, Moshe Levi wrote:

Hi all,

In the last few week I was working on hardware offload support for 
openvswitch.


The idea is to leverage SR-IOV technology with OVS control plane management.

Just last month the ovs community merged all the required patches to 
enable this feature [1] should be in OVS-2.8.0.


I was working on the required patches to enable this in OpenStack.

On the neutron side the RFE approved [2] and the neutron patch is 
already merged [3]


On the OS-VIF side the patch is merged [4]

On the Third party CI side we have a Mellanox CI which is currently 
commenting on os-vif [5] ( we will extend it to nova and neutron as well)


The missing piece is the nova patch [6]

I just notice that this week is feature freeze in OpenStack and I would 
like to request an exception for this feature.


I will appreciate if nova-core reviewers will review it.

( Jay , Sean and Jan already review it several times and I think it is 
close to be merged)


[1] - 
https://github.com/openvswitch/ovs/commit/bf090264e68d160d0ae70ebc93d59bc09d34cc8b 



[2] - https://bugs.launchpad.net/neutron/+bug/1627987

[3] - https://review.openstack.org/#/c/275616/

[4] - https://review.openstack.org/#/c/460278/

[5] - 
http://52.169.200.208/25/485125/6/check-os-vif/OVS_HW_offload/aaf2792/


[6] - https://review.openstack.org/#/c/398265/



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



Given everything else done here and the change in nova is (1) a single 
change and (2) self-contained and (3) relatively uncomplicated, I'm OK 
with this. Please create a blueprint in nova so we can track it as a 
feature since that's what it is.


--

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] [oslo.db] [ndb] ndb namespace throughout openstack projects

On Wed, Jul 26, 2017 at 8:06 PM, Jay Pipes  wrote:
> Isn't that exactly what I'm proposing below? :)

yes, I'm agreeing with you!

__
OpenStack Development Mailing 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] [relmgt] Non-candidacy for the Queens cycle Release management PTL

2017-07-27 Thread Sean McGinnis

> 
> I have multiple reasons for not running this cycle. First, as part of my
> expanded role at the Foundation my travel commitments increased a bit.
> The Release management PTL role requires regular work: I ended up doing
> a relatively bad job at PTLing this cycle, by being away during a number
> of critical weeks. Fortunately, I could count on the presence of the
> other team members (especially dhellmann and dims) to keep things under
> control!

Thank you Thierry and team for the great work. Depite what you say, I
don't think anyone has felt the impact, so - great job!

Sean

__
OpenStack Development Mailing 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] Canceling sahara meeting 07/27

2017-07-27 Thread Telles Nobrega

Hi Saharans and interested folks,

we won't be having sahara meeting today but some of us are hanging out at
#openstack-sahara if you need anything.

Best regards,
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

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

Re: [openstack-dev] [sahara] Sahara-CI comes alive

2017-07-27 Thread Jeremy Freudberg

Hi Evgeny,

First, it is good to know even with only 50GB RAM and 20VCPU, Sahara
CI can still be deployed.
Actually, that is just the default quota on our cloud and we might be
able to increase it more.

However, that cloud is actually having some storage/disk issues
(failed writes...), so it's probably not a good idea to rush into
deployment right now - sorry.

I am definitely in favor of refactoring and automation! Preparing for
the future is always good.

There are still some internal talks about new dedicated resources
(arising from cooperation between my university and Red Hat) for
Sahara CI. If, hopefully, we get some good news out of that
discussion, automation makes even more sense: we can work on
automation during the time that we are waiting.

On Thu, Jul 27, 2017 at 3:44 AM, Evgeny Sikachov  wrote:
> Hey, guys!
>
> Unfortunately today I need to skip the meeting. But I have a question for
> discussion.
>
> Jeremy helped me with resources for Sahara-CI(a lot of thanks again!). And
> now we have around of 50GB RAM and 20VCPUs. This is enough to implement
> basic sahara-ci.
>
> In https://github.com/openstack/sahara-ci-config we have scripts for
> deploying but these scripts not fully automated. For deployment, I will need
> around 4 hours.
>
> My questions:
> Option 1:
> Do we need to deploy sahara-ci right now or we can refactor scripts for more
> convenient deployment/migration? Refactoring task can take 2 weeks.
>
> Option 2:
> I can deploy sahara-ci now in basic configuration, but if we got a crashing
> of infrastructure I will need to redeploy it manually again
>
> __
> OpenStack Development Mailing 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] [sahara] Sahara-CI comes alive

2017-07-27 Thread Telles Nobrega

Hi Evgeny,

We are without the CI for quite some time now and automation sounds like a
great thing for us to have.
So I would say that we can afford to stay a couple more days without it in
favor of a more automated deployment.

Do all agree with me?

On Thu, Jul 27, 2017 at 4:46 AM Evgeny Sikachov  wrote:

> Hey, guys!
>
> Unfortunately today I need to skip the meeting. But I have a question for
> discussion.
>
> Jeremy helped me with resources for Sahara-CI(a lot of thanks again!). And
> now we have around of 50GB RAM and 20VCPUs. This is enough to implement
> basic sahara-ci.
>
> In https://github.com/openstack/sahara-ci-config we have scripts for
> deploying but these scripts not fully automated. For deployment, I will
> need around 4 hours.
>
> My questions:
> Option 1:
> Do we need to deploy sahara-ci right now or we can refactor scripts for
> more convenient deployment/migration? Refactoring task can take 2 weeks.
>
> Option 2:
> I can deploy sahara-ci now in basic configuration, but if we got a
> crashing of infrastructure I will need to redeploy it manually again
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

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

Re: [openstack-dev] [srv-apl-arch:7353] Re: [nova] Discussions for ivshmem support in OpenStack Nova

2017-07-27 Thread Mooney, Sean K

> -Original Message-
> From: TETSURO NAKAMURA [mailto:nakamura.tets...@lab.ntt.co.jp]
> Sent: Thursday, July 27, 2017 2:13 AM
> To: Daniel P. Berrange ; Mooney, Sean K
> 
> Cc: Jay Pipes ; OpenStack Development Mailing List
> (not for usage questions) ;
> sfinu...@redhat.com; mriede...@gmail.com; 【社内】【ML】srv-apl-arch  apl-a...@lab.ntt.co.jp>
> Subject: Re: [srv-apl-arch:7353] Re: [openstack-dev] [nova] Discussions
> for ivshmem support in OpenStack Nova
> 
> On 2017/07/27 0:58, Daniel P. Berrange wrote:
> > On Wed, Jul 26, 2017 at 11:53:06AM -0400, Jay Pipes wrote:
> >> On 07/26/2017 09:57 AM, Daniel P. Berrange wrote:
> >>> On Wed, Jul 26, 2017 at 09:50:23AM -0400, Jay Pipes wrote:
>  On 07/26/2017 03:06 AM, TETSURO NAKAMURA wrote:
> > Hi Nova team,
> >
> > It has been quite a long time since the last discussion, but let
> > me make sure one thing about the thread below.
> >
> > IIUC, Nova is not welcome ivshmem support because it is no longer
> > supported by DPDK+QEMU.
> >
> > But how would you say if it is supported out of DPDK-tree and can
> > be used from the newest qemu version ?
> >
> > We are now developing SPP, a DPDK-based vswitch, and thinking
> > about trying to implement ivshmem support under our SPP code tree
> > if nova (or at first libvirt community) is acceptable for ivshmem
> configuration.
> >
> > Your advice will be very helpful for our decision-making in our
> project.
> 
>  I think this is a question that the libvirt community would first
>  need to weigh in on since Nova is downstream from libvirt -- at
>  least in the sense of low-level hypervisor support.
> >>>
> >>> Libvirt already supports ivshmem device config
> >>>
> >>> http://libvirt.org/formatdomain.html#elementsShmem
> >>
> >> Sorry, I suppose I should have said QEMU, not libvirt. Daniel, you
> >> were the one that specifically discouraged doing anything on ivshmem
> to Tetsuro:
> >>
> >> http://lists.openstack.org/pipermail/openstack-dev/2017-
> July/120136.h
> >> tml
> >
> > 'ivshmem' was the original device in QEMU and that is indeed still
> > deprecated.
> >
> > There are now two replacements 'ivshmem-plain' and 'ivshmem-doorbell'
> > which can be used instead, which are considered supported by QEMU,
> > though most people will still recommend using 'vhostuser' instead if
> > the use of ivshmem is at all network related.
> >
> > Regards,
> > Daniel
> >
> 
> Thank you very much for the information about current status of ivshmem
> in QEMU.
> I now understand that 'ivshmem', 'ivshmem-plain' and 'ivshmem-doorbell'
> are different solutions, and libvirt already supports the latter two.
> 
> + Mr. Sean Mooney
> Did you mean that you caution against building new solutions ontop of
> 'ivshmem' or ontop of 'ivshmem-plain' and 'ivshmem-doorbell' too?
[Mooney, Sean K] I would caution against building any networking based uscases 
ontop of ivshmem.
The move to using a memdev instead of directly specifying shm args to qemu for 
ivshmem-plain/doorbell
Should allow hugepage memory to be used instead of posix sheared mem which 
would be needed for spp.

That said just because you can use ivshmem-plain/doorbell with hugepages via a 
memdev form the qemu commandline
does not mean it is supported by Libvirt 
https://libvirt.org/formatdomain.html#elementsShmem or that it is the best 
approach,
upstream development has shifted to virtio and vhost-user.
0 copy tx from a vm is already supported with vhost-user and ovs-dpdk.
0 copy rx Is under development which is the main delta in performance between 
ivshmem and vhost-user that remains.
Both of these features could be ported to the spp.

Vhost-user does have some inherent overhead such as the descriptor rings etc 
required to support virtio
Must be created which is required to support the virtio spec which give you 
portability and performance when
Coupled with multi queue and the dpdk vhost pmd in the guest.

If vhost-user is really not sufficient for your usecase I would first suggest 
extending Libvirt to allow
Passing a memdev name as a parameter to the shmem element.
At that point we could discuss how to request openstack to use those new 
element to create the shmem device.

The best approach using what openstack support today for a generic shmem dev 
would be via a Libvirt option in the image metatdata the same
Way that serial ports allocation or vGPU memory is configured. If this device 
was to be used as a nic however
A different approach of creating a new vnic_type of ivsheme_plain and 
ivshmem_doorbell would be more approiate with the
Port binding profile used to transport the memory mapping info similar to how 
we expose info for sriov devices.

The issue with ivshsmem interfaces in a neutron context is its just a pci 
device where bar2 points to a shared memory region
There is no way to pass info such as a mac address to a hypervisor for it to 
enforce so the use of ivshmem deveic

Re: [openstack-dev] [sahara] Proposing Luigi Toscano, Evgeny Sikachev and Jeremy Freudberg for Sahara core team

2017-07-27 Thread Sergey Reshetnyak

1 for all

2017-07-26 22:09 GMT+04:00 Telles Nobrega :

> Hi folks,
>
> With a lot of changes happening along OpenStack we need to update our core
> team.
>
> I'm proposing adding Luigi Toscano, Evgeny Sikachev and Jeremy Freudberg
> to Sahara core team.
>
> The first two, are already sahara-tests core and lately have been doing a
> lot more than test and addition to the whole project core team is well
> deserved.
> Jeremy joined us not too long ago but has been doing outstanding work with
> us and has a great grasp of Sahara and all of its plugins.
>
> Lets vote this,
>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat I 
>
> tenob...@redhat.com
> 
> TRIED. TESTED. TRUSTED. 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] Proposing Luigi Toscano, Evgeny Sikachev and Jeremy Freudberg for Sahara core team

2017-07-27 Thread Sergey Reshetnyak

I mean +1 for all.



2017-07-27 15:07 GMT+04:00 Sergey Reshetnyak :

> 1 for all
>
> 2017-07-26 22:09 GMT+04:00 Telles Nobrega :
>
>> Hi folks,
>>
>> With a lot of changes happening along OpenStack we need to update our
>> core team.
>>
>> I'm proposing adding Luigi Toscano, Evgeny Sikachev and Jeremy Freudberg
>> to Sahara core team.
>>
>> The first two, are already sahara-tests core and lately have been doing a
>> lot more than test and addition to the whole project core team is well
>> deserved.
>> Jeremy joined us not too long ago but has been doing outstanding work
>> with us and has a great grasp of Sahara and all of its plugins.
>>
>> Lets vote this,
>>
>> --
>>
>> TELLES NOBREGA
>>
>> SOFTWARE ENGINEER
>>
>> Red Hat I 
>>
>> tenob...@redhat.com
>> 
>> TRIED. TESTED. TRUSTED. 
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] trying to understand CORS deprecation

Hi, I tried to fix serveral month ago in https://review.openstack.org/#
/c/453723/ , but gived up due to lack of time to fix many tests, will
restore it and continue on it :-)

2017-07-25 0:46 GMT+08:00 Jay Pipes :

> On 07/24/2017 12:43 PM, Sean Dague wrote:
>
>> I'm trying to knock out common deprecation messages which are generating
>> noise in the test runs. There is a deprecation message emitted all the
>> time during test runs in Nova which is:
>>
>> DeprecationWarning: Method 'CORS.set_latent()' has moved to
>> 'method.set_defaults()': CORS.set_latent has been deprecated in favor of
>> oslo_middleware.cors.set_defaults"
>>
>> But from what I can see it's primary caller is the cors middleware
>> itself -
>> https://github.com/openstack/oslo.middleware/blob/1cf39ee5c3
>> 739c18fed78946532438550f56356f/oslo_middleware/cors.py#L133-L137
>>
>>
>> At least I'm having a hard time finding anyone else in this stack
>> calling set_latent. Is this just a circular bug on the cors.py module?
>>
>
>
> FYI: https://bugs.launchpad.net/oslo.middleware/+bug/1642008
>
> It's bothered me for a while but never been able to get to the bottom of
> it.
>
> Best,
> -jay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing 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][security] To firewalld, or not to firewalld

2017-07-27 Thread Mark Mielke

On Thu, Jul 27, 2017 at 2:31 AM, Jean-Philippe Evrard <
jean-phili...@evrard.me> wrote:
>
> For ppl who aren't iptables experts, firewalld module brings a lot of
> readability.
> If we are doing the tasks equivalent with iptables, the readability will
> be brought in by variables (I mean variables to list ports_to_open are
> fairly easy to understand).
>
> I am myself preferring to always use modules, and so, use the firewalld
> module (because it's already upstream, less tasks and therefore less error
> prone).
> However, that would mean that we improve the module itself to grant what
> we need: Real ubuntu and python3 support.
> Maybe it's a crusade that nobody wants to partake in, and using iptables
> would mean a path to least resistance, therefore easier to ship.
> On top of it, if it's more a hassle to use the module due to complex rules
> (do we even need that?), I'd understand the move to iptables management. Is
> there already a role to handle this?
>

I have been thinking about nftables for our use cases. iptables is (slowly)
on its way out. firewalld does provide some abstraction from this, in that
firewalld could provide an interface to translate from iptables to nftables
without application changes. But, I am concerned that firewalld is not
sophisticated enough to meet requirements, and I am hesitant to really
invest in it if it is too simple for requirements.

Just some food for thought I had to offer...
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA][PTG] Planning QA work at the PTG

2017-07-27 Thread Andrea Frittoli

Hello folks,

it's time we start planning the week for the QA team at the PTG in Denver.
Please add your ideas / proposal / comments to the etherpad [0].

We welcome proposed topics from anyone, not only the QA team.

Since we have a community goal in Queens for Tempest plugins, we will
definitely spend some time on that during the PTG.

Andrea Frittoli (andreaf)

[0] https://etherpad.openstack.org/p/qa-queens-ptg
__
OpenStack Development Mailing 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] [relmgt] Non-candidacy for the Queens cycle Release management PTL

2017-07-27 Thread Thierry Carrez

Hi everyone,

I don't intend to run for Release management PTL for Queens. If you're
interested in this role, I encourage you to apply when the nomination
period opens (July 31). You might be interested in reviewing [1], which
describes the still-not-automated parts of release management for
OpenStack. In addition to those team duties, the PTL is expected to run
the release team meeting and send the regular release countdown emails.

[1] http://git.openstack.org/cgit/openstack/releases/tree/PROCESS.rst

I have multiple reasons for not running this cycle. First, as part of my
expanded role at the Foundation my travel commitments increased a bit.
The Release management PTL role requires regular work: I ended up doing
a relatively bad job at PTLing this cycle, by being away during a number
of critical weeks. Fortunately, I could count on the presence of the
other team members (especially dhellmann and dims) to keep things under
control! Second, I believe in expanding the pool of people who can do
this job for OpenStack, and in general in regular rotation of the PTL
roles to avoid burnout.

I'm not going anywhere though, I'll still be part of the team and I
intend to continue to take my fair share of the release management
duties ! Whoever steps up and gets elected will be able to count on a
solid team of seasoned release managers and mentors :)

Regards,

-- 
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] [mistral][summit] Mistral sessions submitted for the Sydney summit

2017-07-27 Thread Renat Akhmerov

Hi,

Here’s the list of talks related to Mistral that we submitted for the summit in 
Sydney:

• What makes Mistral an OpenStack super-star? Right, CloudFlow! - 
https://www.openstack.org/summit/sydney-2017/vote-for-speakers#/19109
• Test your Mistral workflows - 
https://www.openstack.org/summit/sydney-2017/vote-for-speakers#/19196
• Advanced Fault Management with Vitrage and Mistral - 
https://www.openstack.org/summit/sydney-2017/vote-for-speakers#/19508

All of them should be very cool so don’t hesitate to vote for them :)

Thanks

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

[openstack-dev] [tripleo][tripleo-heat-template] how to get interface name from network name in service profile

2017-07-27 Thread Zenghui Shi

Hi,

Could anyone shed some light on how to get the physical interface name (e.g
eth0) from network name (e.g PublicNetwork, ExternalNetwork) in
tripleo-heat-template service profile ?

for example:

I want to add a service profile under puppet/services/time/ptp.pp where it
uses 'PtpInterface' as a parameter to get physical interface name (please
refer to below piece of code), but I'd like to expose a more user friendly
parameter like NetworkName(e.g. provision network, external network etc)
instead of 'PtpInterface' and retrieve the actual physical interface name
from the NetworkName where the physical interface is connected to, is there
any possible way to do this ?


parameters:
[...]
  PtpInterface:  #  ---> change this parameter to PtpNetwork
default: eth0
description: PTP interfaces name.
type: string

resources:
  RoleParametersValue
type: OS::Heat::Value
properties:
  type: json
  value: # ---> add logic to get real interface name from
PtpNetwork
map_replace:
  - map_replace:
- tripleo::profile::base::time::ptp::ptp4l_interface:
PtpInterface
- values: {get_param: [RoleParameters]}
  - values:
  PtpInterface: {get_param: PtpInterface}

outputs:
  role_data:
description: Role ptp using commposable services.
value:
  service_name: ptp
  config_settings:
map_merge:
  - get_attr: [RoleParametersValue, value]
[...]


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

[openstack-dev] [sahara] Sahara-CI comes alive

2017-07-27 Thread Evgeny Sikachov

Hey, guys!

Unfortunately today I need to skip the meeting. But I have a question for
discussion.

Jeremy helped me with resources for Sahara-CI(a lot of thanks again!). And
now we have around of 50GB RAM and 20VCPUs. This is enough to implement
basic sahara-ci.

In https://github.com/openstack/sahara-ci-config we have scripts for
deploying but these scripts not fully automated. For deployment, I will
need around 4 hours.

My questions:
Option 1:
Do we need to deploy sahara-ci right now or we can refactor scripts for
more convenient deployment/migration? Refactoring task can take 2 weeks.

Option 2:
I can deploy sahara-ci now in basic configuration, but if we got a crashing
of infrastructure I will need to redeploy it manually again
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] Proposing Luigi Toscano, Evgeny Sikachev and Jeremy Freudberg for Sahara core team

2017-07-27 Thread Alina Nesterova

+1

Luigi, Evgeny and Jeremy, thanks for all the work you've done!

On Wed, Jul 26, 2017 at 10:09 PM, Telles Nobrega 
wrote:

> Hi folks,
>
> With a lot of changes happening along OpenStack we need to update our core
> team.
>
> I'm proposing adding Luigi Toscano, Evgeny Sikachev and Jeremy Freudberg
> to Sahara core team.
>
> The first two, are already sahara-tests core and lately have been doing a
> lot more than test and addition to the whole project core team is well
> deserved.
> Jeremy joined us not too long ago but has been doing outstanding work with
> us and has a great grasp of Sahara and all of its plugins.
>
> Lets vote this,
>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat I 
>
> tenob...@redhat.com
> 
> TRIED. TESTED. TRUSTED. 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [all] [oslo.db] [relational database users] heads up for a MariaDB issue that will affect most projects