Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

2017-02-01 Thread IWAMOTO Toshihiro
At Wed, 1 Feb 2017 17:37:34 -0700,
Kevin Benton wrote:
> 
> [1  ]
> [1.1  ]
> And who said openstack wasn't growing? ;)
> 
> I think reducing API workers is a nice quick way to bring back some
> stability.
> 
> I have spent a bunch of time digging into the OOM killer events and haven't
> yet figured out why they are being triggered. There is significant swap
> space remaining in all of the cases I have seen so it's likely some memory

We can try increasing watermark_scale_factor instead.
I looked at random 2 oom-killer invocations but free mem were above
watermark. oom-killer were triggered by 16kB contig page alloation by
apparmor_file_alloc_security, so if we can try disabling apparmor that
may also work.


> locking issue or kernel allocations blocking swap. Until we can figure out
> the cause, we effectively have no usable swap space on the test instances
> so we are limited to 8GB.
> 
> On Feb 1, 2017 17:27, "Armando M."  wrote:
> 
> > Hi,
> >
> > [TL;DR]: OpenStack services have steadily increased their memory
> > footprints. We need a concerted way to address the oom-kills experienced in
> > the openstack gate, as we may have reached a ceiling.
> >
> > Now the longer version:
> > 
> >
> > We have been experiencing some instability in the gate lately due to a
> > number of reasons. When everything adds up, this means it's rather
> > difficult to merge anything and knowing we're in feature freeze, that adds
> > to stress. One culprit was identified to be [1].
> >
> > We initially tried to increase the swappiness, but that didn't seem to
> > help. Then we have looked at the resident memory in use. When going back
> > over the past three releases we have noticed that the aggregated memory
> > footprint of some openstack projects has grown steadily. We have the
> > following:
> >
> >- Mitaka
> >   - neutron: 1.40GB
> >   - nova: 1.70GB
> >   - swift: 640MB
> >   - cinder: 730MB
> >   - keystone: 760MB
> >   - horizon: 17MB
> >   - glance: 538MB
> >- Newton
> >- neutron: 1.59GB (+13%)
> >   - nova: 1.67GB (-1%)
> >   - swift: 779MB (+21%)
> >   - cinder: 878MB (+20%)
> >   - keystone: 919MB (+20%)
> >   - horizon: 21MB (+23%)
> >   - glance: 721MB (+34%)
> >- Ocata
> >   - neutron: 1.75GB (+10%)
> >   - nova: 1.95GB (%16%)
> >   - swift: 703MB (-9%)
> >   - cinder: 920MB (4%)
> >   - keystone: 903MB (-1%)
> >   - horizon: 25MB (+20%)
> >   - glance: 740MB (+2%)
> >
> > Numbers are approximated and I only took a couple of samples, but in a
> > nutshell, the majority of the services have seen double digit growth over
> > the past two cycles in terms of the amount or RSS memory they use.
> >
> > Since [1] is observed only since ocata [2], I imagine that's pretty
> > reasonable to assume that memory increase might as well be a determining
> > factor to the oom-kills we see in the gate.
> >
> > Profiling and surgically reducing the memory used by each component in
> > each service is a lengthy process, but I'd rather see some gate relief
> > right away. Reducing the number of API workers helps bring the RSS memory
> > down back to mitaka levels:
> >
> >- neutron: 1.54GB
> >- nova: 1.24GB
> >- swift: 694MB
> >- cinder: 778MB
> >- keystone: 891MB
> >- horizon: 24MB
> >- glance: 490MB
> >
> > However, it may have other side effects, like longer execution times, or
> > increase of timeouts.
> >
> > Where do we go from here? I am not particularly fond of stop-gap [4], but
> > it is the one fix that most widely address the memory increase we have
> > experienced across the board.
> >
> > Thanks,
> > Armando
> >
> > [1] https://bugs.launchpad.net/neutron/+bug/1656386
> > [2] http://logstash.openstack.org/#/dashboard/file/logstash.
> > json?query=message:%5C%22oom-killer%5C%22%20AND%20tags:syslog
> > [3] http://logs.openstack.org/21/427921/1/check/gate-
> > tempest-dsvm-neutron-full-ubuntu-xenial/82084c2/
> > [4] https://review.openstack.org/#/c/427921
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> [1.2  ]
> [2  ]
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [neutron] [release] misleading release notes

2017-02-01 Thread Dean Troyer
On Wed, Feb 1, 2017 at 8:13 PM, Armando M.  wrote:
> I suspect what happens is that someone revises the content at a later date
> and reno associated the last timestamp of the release note with release
> where the change has been made?

I do believe this is the case, reno puts a note in the release that it
find it in, thus editing notes after branching is going to give you
the result you so not want.

I've made a point to do one last relnote cleanup pass before releases
to catch the errors/typos that have slipped through, but OSC doesn't
have near the volume of commits or notes that many projects have...

dt

-- 

Dean Troyer
dtro...@gmail.com

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


Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

2017-02-01 Thread Dolph Mathews
What made most services jump +20% between mitaka and newton? Maybe there is
a common cause that we can tackle.

I'd also be in favor of reducing the number of workers in the gate,
assuming that doesn't also substantially increase the runtime of gate jobs.
Does that environment variable (API_WORKERS) affect keystone and horizon?

On Wed, Feb 1, 2017 at 6:39 PM Kevin Benton  wrote:

> And who said openstack wasn't growing? ;)
>
> I think reducing API workers is a nice quick way to bring back some
> stability.
>
> I have spent a bunch of time digging into the OOM killer events and
> haven't yet figured out why they are being triggered. There is significant
> swap space remaining in all of the cases I have seen so it's likely some
> memory locking issue or kernel allocations blocking swap. Until we can
> figure out the cause, we effectively have no usable swap space on the test
> instances so we are limited to 8GB.
>
> On Feb 1, 2017 17:27, "Armando M."  wrote:
>
> Hi,
>
> [TL;DR]: OpenStack services have steadily increased their memory
> footprints. We need a concerted way to address the oom-kills experienced in
> the openstack gate, as we may have reached a ceiling.
>
> Now the longer version:
> 
>
> We have been experiencing some instability in the gate lately due to a
> number of reasons. When everything adds up, this means it's rather
> difficult to merge anything and knowing we're in feature freeze, that adds
> to stress. One culprit was identified to be [1].
>
> We initially tried to increase the swappiness, but that didn't seem to
> help. Then we have looked at the resident memory in use. When going back
> over the past three releases we have noticed that the aggregated memory
> footprint of some openstack projects has grown steadily. We have the
> following:
>
>- Mitaka
>   - neutron: 1.40GB
>   - nova: 1.70GB
>   - swift: 640MB
>   - cinder: 730MB
>   - keystone: 760MB
>   - horizon: 17MB
>   - glance: 538MB
>- Newton
>- neutron: 1.59GB (+13%)
>   - nova: 1.67GB (-1%)
>   - swift: 779MB (+21%)
>   - cinder: 878MB (+20%)
>   - keystone: 919MB (+20%)
>   - horizon: 21MB (+23%)
>   - glance: 721MB (+34%)
>- Ocata
>   - neutron: 1.75GB (+10%)
>   - nova: 1.95GB (%16%)
>   - swift: 703MB (-9%)
>   - cinder: 920MB (4%)
>   - keystone: 903MB (-1%)
>   - horizon: 25MB (+20%)
>   - glance: 740MB (+2%)
>
> Numbers are approximated and I only took a couple of samples, but in a
> nutshell, the majority of the services have seen double digit growth over
> the past two cycles in terms of the amount or RSS memory they use.
>
> Since [1] is observed only since ocata [2], I imagine that's pretty
> reasonable to assume that memory increase might as well be a determining
> factor to the oom-kills we see in the gate.
>
> Profiling and surgically reducing the memory used by each component in
> each service is a lengthy process, but I'd rather see some gate relief
> right away. Reducing the number of API workers helps bring the RSS memory
> down back to mitaka levels:
>
>- neutron: 1.54GB
>- nova: 1.24GB
>- swift: 694MB
>- cinder: 778MB
>- keystone: 891MB
>- horizon: 24MB
>- glance: 490MB
>
> However, it may have other side effects, like longer execution times, or
> increase of timeouts.
>
> Where do we go from here? I am not particularly fond of stop-gap [4], but
> it is the one fix that most widely address the memory increase we have
> experienced across the board.
>
> Thanks,
> Armando
>
> [1] https://bugs.launchpad.net/neutron/+bug/1656386
> [2]
> http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22oom-killer%5C%22%20AND%20tags:syslog
> [3]
> http://logs.openstack.org/21/427921/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/82084c2/
> [4] https://review.openstack.org/#/c/427921
>
> __
> OpenStack Development Mailing 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
>
-- 
-Dolph
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [oslo][oslo.db] MySQL Cluster support

2017-02-01 Thread Octave J. Orgeron

Hi Folks,

I'm working on adding support for MySQL Cluster to the core OpenStack 
services. This will enable the community to benefit from an 
active/active, auto-sharding, and scale-out MySQL database. My approach 
is to have a single configuration setting in each core OpenStack service 
in the oslo.db configuration section called mysql_storage_engine that 
will enable the logic in the SQL Alchemy or Alembic upgrade scripts to 
handle the differences between InnoDB and NDB storage engines 
respectively. When enabled, this logic will make the required table 
schema changes around:


 * Row character length limits 65k -> 14k
 * Proper SQL ordering of foreign key, constraints, and index operations
 * Interception of savepoint and nested operations

By default this functionality will not be enabled and will have no 
impact on the default InnoDB functionality. These changes have been 
tested on Kilo and Mitaka in previous releases of our OpenStack 
distributions with Tempest. I'm working on updating these patches for 
upstream consumption. We are also working on a 3rd party CI for 
regression testing against MySQL Cluster for the community.


The first change set is for oslo.db and can be reviewed at:

https://review.openstack.org/427970

Thanks,
Octave

--

Oracle 
Octave J. Orgeron | Sr. Principal Architect and Software Engineer
Oracle Linux OpenStack

Certified Oracle Enterprise Architect: Systems Infrastructure 

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment


__
OpenStack Development Mailing 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] [Zun] Propose a change of the Zun core team membership

2017-02-01 Thread Kevin Zhao
Thanks Hongbin and Zun Team,

I'll exert my best efforts to meet the expectations.

Best Regards,
Kevin Zhao


On 31 January 2017 at 03:34, Hongbin Lu  wrote:

> Hi all,
>
> Thanks for the votes. According to the feedback, this proposal is
> approved. Welcome Kevin to the core team.
>
> Best regards,
> Hongbin
>
> -Original Message-
> From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
> Sent: January-29-17 6:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Zun] Propose a change of the Zun core team
> membership
>
> +1 to both.
>
> On Mon, Jan 23, 2017 at 10:56:00PM +, Hongbin Lu wrote:
> > Hi Zun cores,
> >
> > I proposed a change of Zun core team membership as below:
> >
> > + Kevin Zhao (kevin-zhao)
> > - Haiwei Xu (xu-haiwei)
> >
> > Kevin has been working for Zun for a while, and made significant
> contribution. He submitted several non-trivial patches with high quality.
> One of his challenging task is adding support of container interactive
> mode, and it looks he is capable to handle this challenging task (his
> patches are under reviews now). I think he is a good addition to the core
> team. Haiwei is a member of the initial core team. Unfortunately, his
> activity dropped down in the past a few months.
> >
> > According to the OpenStack Governance process [1], we require a minimum
> of 4 +1 votes from Zun core reviewers within a 1 week voting window
> (consider this proposal as a +1 vote from me). A vote of -1 is a veto. If
> we cannot get enough votes or there is a veto vote prior to the end of the
> voting window, this proposal is rejected.
> >
> > [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> >
> > Best regards,
> > Hongbin
> >
>
> > __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [neutron] [release] misleading release notes

2017-02-01 Thread Armando M.
Hi,

There is something puzzling about release notes. I don't see 8.0.0 [1], and
it looks like features released in Mitaka are being advertised as Newton
features [2]. For instance, [3] 'Agent availability zones' shows as a
Newton feature when I am pretty positive that it went in Mitaka [4].

I suspect what happens is that someone revises the content at a later date
and reno associated the last timestamp of the release note with release
where the change has been made?

I don't see other projects' release notes broken this way so we must be
doing something wrong. It would be good to have guidance from the release
team.

Thanks,
Armando

[1] http://docs.openstack.org/releasenotes/neutron/mitaka.html
[2] http://docs.openstack.org/releasenotes/neutron/newton.html#id5
[3] http://docs.openstack.org/releasenotes/neutron/newton.html#id6
[4] https://review.openstack.org/#/c/204436/
__
OpenStack Development Mailing 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] [requirements][neutron] bot bumping patches off gate queue

2017-02-01 Thread Tony Breeds
On Wed, Feb 01, 2017 at 07:49:21AM -0800, Ihar Hrachyshka wrote:
> On Wed, Feb 1, 2017 at 7:42 AM, Armando M.  wrote:
> >
> >
> > On 1 February 2017 at 07:29, Ihar Hrachyshka  wrote:
> >>
> >> Hi all,
> >>
> >> lately I see the requirements bot proposing new rebases for its
> >> patches (and bumping existing patch sets from the gate queue) every
> >> second hour, at least for Neutron [1], which makes it impossible to
> >> land the patches, and which only makes gate pre-release situation
> >> worse. On top of that, the proposed rebases don't really add anything
> >> material to the sync patch, no new version changes and such.
> >>
> >> I think we had some guards against such behavior before, so I wonder
> >> if they were broken or removed lately? Any plans to fix that?
> >>
> >> It would be nice to be able to land the update before RC1 is cut off,
> >> but at this point, it does not seem realistic.
> >>
> >> [1] https://review.openstack.org/#/c/423645/
> >>
> >
> > Let's stop merging until the bot proposal change lands. That ought to stop
> > the spurious rebase!
> >
> > Hard times require hard measures!!
> 
> That's assuming it's triggered by neutron merges. It may as well be
> requirements merges that trigger rebases. Something that I believe
> requirements team will help us to understand.

So it's a combination of both.  The bot runs are triggered on merges to
openstack/requirements but the rebases are (clearly) due to the fact that
neutron has advanced in the mean time.

We knew this was a suboptimal part of the process but until your thread we
assumed it was wasting CPU/gate resources.  You've exposed the developer
cost and that elevates this in priority.

We processes a few requirements feature freeze excetpions which is what caused
the issue you highlight in that review.  I'll see what I can do about finding
someone to fix this before we release Ocata.

The "fix" will be to check if the bot run is a rebase *and* if the current
revision of the change is lacking a vote from jenkins.  Hmmm I guess we should
*also* check if the version in gerrit has +W and avoid the upload in that case
also.


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] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

2017-02-01 Thread Kevin Benton
And who said openstack wasn't growing? ;)

I think reducing API workers is a nice quick way to bring back some
stability.

I have spent a bunch of time digging into the OOM killer events and haven't
yet figured out why they are being triggered. There is significant swap
space remaining in all of the cases I have seen so it's likely some memory
locking issue or kernel allocations blocking swap. Until we can figure out
the cause, we effectively have no usable swap space on the test instances
so we are limited to 8GB.

On Feb 1, 2017 17:27, "Armando M."  wrote:

> Hi,
>
> [TL;DR]: OpenStack services have steadily increased their memory
> footprints. We need a concerted way to address the oom-kills experienced in
> the openstack gate, as we may have reached a ceiling.
>
> Now the longer version:
> 
>
> We have been experiencing some instability in the gate lately due to a
> number of reasons. When everything adds up, this means it's rather
> difficult to merge anything and knowing we're in feature freeze, that adds
> to stress. One culprit was identified to be [1].
>
> We initially tried to increase the swappiness, but that didn't seem to
> help. Then we have looked at the resident memory in use. When going back
> over the past three releases we have noticed that the aggregated memory
> footprint of some openstack projects has grown steadily. We have the
> following:
>
>- Mitaka
>   - neutron: 1.40GB
>   - nova: 1.70GB
>   - swift: 640MB
>   - cinder: 730MB
>   - keystone: 760MB
>   - horizon: 17MB
>   - glance: 538MB
>- Newton
>- neutron: 1.59GB (+13%)
>   - nova: 1.67GB (-1%)
>   - swift: 779MB (+21%)
>   - cinder: 878MB (+20%)
>   - keystone: 919MB (+20%)
>   - horizon: 21MB (+23%)
>   - glance: 721MB (+34%)
>- Ocata
>   - neutron: 1.75GB (+10%)
>   - nova: 1.95GB (%16%)
>   - swift: 703MB (-9%)
>   - cinder: 920MB (4%)
>   - keystone: 903MB (-1%)
>   - horizon: 25MB (+20%)
>   - glance: 740MB (+2%)
>
> Numbers are approximated and I only took a couple of samples, but in a
> nutshell, the majority of the services have seen double digit growth over
> the past two cycles in terms of the amount or RSS memory they use.
>
> Since [1] is observed only since ocata [2], I imagine that's pretty
> reasonable to assume that memory increase might as well be a determining
> factor to the oom-kills we see in the gate.
>
> Profiling and surgically reducing the memory used by each component in
> each service is a lengthy process, but I'd rather see some gate relief
> right away. Reducing the number of API workers helps bring the RSS memory
> down back to mitaka levels:
>
>- neutron: 1.54GB
>- nova: 1.24GB
>- swift: 694MB
>- cinder: 778MB
>- keystone: 891MB
>- horizon: 24MB
>- glance: 490MB
>
> However, it may have other side effects, like longer execution times, or
> increase of timeouts.
>
> Where do we go from here? I am not particularly fond of stop-gap [4], but
> it is the one fix that most widely address the memory increase we have
> experienced across the board.
>
> Thanks,
> Armando
>
> [1] https://bugs.launchpad.net/neutron/+bug/1656386
> [2] http://logstash.openstack.org/#/dashboard/file/logstash.
> json?query=message:%5C%22oom-killer%5C%22%20AND%20tags:syslog
> [3] http://logs.openstack.org/21/427921/1/check/gate-
> tempest-dsvm-neutron-full-ubuntu-xenial/82084c2/
> [4] https://review.openstack.org/#/c/427921
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

2017-02-01 Thread Armando M.
Hi,

[TL;DR]: OpenStack services have steadily increased their memory
footprints. We need a concerted way to address the oom-kills experienced in
the openstack gate, as we may have reached a ceiling.

Now the longer version:


We have been experiencing some instability in the gate lately due to a
number of reasons. When everything adds up, this means it's rather
difficult to merge anything and knowing we're in feature freeze, that adds
to stress. One culprit was identified to be [1].

We initially tried to increase the swappiness, but that didn't seem to
help. Then we have looked at the resident memory in use. When going back
over the past three releases we have noticed that the aggregated memory
footprint of some openstack projects has grown steadily. We have the
following:

   - Mitaka
  - neutron: 1.40GB
  - nova: 1.70GB
  - swift: 640MB
  - cinder: 730MB
  - keystone: 760MB
  - horizon: 17MB
  - glance: 538MB
   - Newton
   - neutron: 1.59GB (+13%)
  - nova: 1.67GB (-1%)
  - swift: 779MB (+21%)
  - cinder: 878MB (+20%)
  - keystone: 919MB (+20%)
  - horizon: 21MB (+23%)
  - glance: 721MB (+34%)
   - Ocata
  - neutron: 1.75GB (+10%)
  - nova: 1.95GB (%16%)
  - swift: 703MB (-9%)
  - cinder: 920MB (4%)
  - keystone: 903MB (-1%)
  - horizon: 25MB (+20%)
  - glance: 740MB (+2%)

Numbers are approximated and I only took a couple of samples, but in a
nutshell, the majority of the services have seen double digit growth over
the past two cycles in terms of the amount or RSS memory they use.

Since [1] is observed only since ocata [2], I imagine that's pretty
reasonable to assume that memory increase might as well be a determining
factor to the oom-kills we see in the gate.

Profiling and surgically reducing the memory used by each component in each
service is a lengthy process, but I'd rather see some gate relief right
away. Reducing the number of API workers helps bring the RSS memory down
back to mitaka levels:

   - neutron: 1.54GB
   - nova: 1.24GB
   - swift: 694MB
   - cinder: 778MB
   - keystone: 891MB
   - horizon: 24MB
   - glance: 490MB

However, it may have other side effects, like longer execution times, or
increase of timeouts.

Where do we go from here? I am not particularly fond of stop-gap [4], but
it is the one fix that most widely address the memory increase we have
experienced across the board.

Thanks,
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1656386
[2]
http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22oom-killer%5C%22%20AND%20tags:syslog
[3]
http://logs.openstack.org/21/427921/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/82084c2/
[4] https://review.openstack.org/#/c/427921
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [kolla] Domains support

2017-02-01 Thread Christian Tardif
Will sure give it a try ! And from a kolla perspective, it means that 
this file should go in /etc/kolla/config/domains/keystone.$DOMAIN.conf 
in order to be pushed to the relevant containers ?


Christian Tardif
christian.tar...@servinfo.ca

SVP, pensez à l’environnement avant d’imprimer ce message.




-- Message d'origine --
De: "Dave Walker" 
À: "OpenStack Development Mailing List (not for usage questions)" 


Envoyé : 2017-02-01 11:39:15
Objet : Re: [openstack-dev] [kolla] Domains support


Hi Christian,

I added the domain support, but I didn't document it as well as I 
should have. Apologies!


This is the config I am using to talk to a windows AD server.  Hope 
this helps.


create a domain specific file:
etc/keystone/domains/keystone.$DOMAIN.conf:

[ldap]
use_pool = true
pool_size = 10
pool_retry_max = 3
pool_retry_delay = 0.1
pool_connection_timeout = -1
pool_connection_lifetime = 600
use_auth_pool = false
auth_pool_size = 100
auth_pool_connection_lifetime = 60
url = ldap://server1:389,ldap://server2:389
user = CN=Linux SSSD Kerberos Service 
Account,CN=Users,DC=example,DC=com

password = password
suffix   = dc=example,dc=com
user_tree_dn = 
OU=Personnel,OU=Users,OU=example,DC=example,DC=com

user_objectclass = person
user_filter  = (memberOf=CN=mail,OU=GPO 
Security,OU=Groups,OU=COMPANY,DC=example,DC=com)

user_id_attribute= sAMAccountName
user_name_attribute  = sAMAccountName
user_description_attribute = displayName
user_mail_attribute  = mail
user_pass_attribute  =
user_enabled_attribute   = userAccountControl
user_enabled_mask= 2
user_enabled_default = 512
user_attribute_ignore= password,tenant_id,tenants
group_tree_dn= OU=GPO 
Security,OU=Groups,OU=COMPANY,DC=example,DC=com

group_name_attribute = name
group_id_attribute   = cn
group_objectclass= group
group_member_attribute   = member

[identity]
driver = keystone.identity.backends.ldap.Identity

[assignment]
driver = keystone.assignment.backends.sql.Assignment

--
Kind Regards,
Dave Walker

On 1 February 2017 at 05:03, Christian Tardif 
 wrote:

Hi,

I'm looking for domains support in Kolla. I've searched, but didn't 
find anything relevant. Could someone point me how to achieve this?


What I'm really looking for, in fact, is a decent way or setting auth 
through LDAP backend while keeping service users (neutron, for 
example) in the SQL backend. I know that this can be achieved with 
domains support (leaving default domain on SQL, and another domain for 
LDAP users. Or maybe there's another of doing this?


Thanks,

Christian Tardif
christian.tar...@servinfo.ca


__
OpenStack Development Mailing 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] [ux] Future of the OpenStack UX team

2017-02-01 Thread Shamail
Hi Thierry,

> On Jan 31, 2017, at 7:10 AM, Thierry Carrez  wrote:
> 
> Shamail wrote:
>>> Sorry for not noticing this thread and replying earlier.
>>> 
>>> I've now reviewed the minutes from the meeting, and I support thingee's 
>>> suggestion of having a UX working group. This way, UX can get the attention 
>>> it rightly deserves. Without the research and guidelines provided by the UX 
>>> team, user-facing projects (such as Docs) will be poorer. I believe that 
>>> it's in Foundations best interests to ensure that UX work is ongoing, and 
>>> adequately supported, in the same way as Marketing and other user outreach 
>>> services. 
>> +1
>>> 
>>> I am happy to work with Foundation (on behalf of the Docs team) to 
>>> determine how this would work in practice.
>> I'm happy to help as well.  The Product working group recently started using 
>> Personas in our user stories and I also participated in the Personas 
>> workshop with the UX team.
> 
> This working group will need a driver/leader/steward to set up at least
> the first meetings and see who would be ready to do what in UX land.
> 
> Any volunteer ?
I'll be glad to schedule the initial discussions/meetings to determine our 
refined scope and to identify participants.  I think the team will have a 
quorum to continue the persona and research work but we will need to find if 
there are people in the community with actual UX design experience that are 
willing to also participate.  Does the TC envision this as a UC or TC governed 
WG?  I'll submit the patches according to your response.
> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


[openstack-dev] [all][elections] PTL Voting is now open

2017-02-01 Thread Kendall Nelson
Hello All!

Elections are underway and will remain open for you to cast your vote until Feb
07, 2017 23:45 UTC.

We are having elections for Ironic, Keystone, Neutron, Quality Assurance
and Stable Branch Maintenance.

If you are a Foundation individual member and had a commit in one of the
program's projects[0] over the Newton-Ocata timeframe (Apr 11, 2016 00:00
UTC to Jan 23, 2017 23:59 UTC) then you are eligible to vote. You should
find your email with a link to the Condorcet page to cast your vote in the
inbox of your gerrit preferred email[1].

What to do if you don't see the email and have a commit in at least one of
the programs having an election:
  * check the trash or spam folders of your gerrit Preferred Email address,
in case it went into trash or spam
  * wait a bit and check again, in case your email server is a bit slow
  * find the sha of at least one commit from the program project repos[0]
and email the election officials. If we can confirm that you are entitled
to vote, we will add you to the voters list for the appropriate election.

Our democratic process is important to the health of OpenStack, please
exercise your right to vote.

Candidate statements/platforms can be found linked to Candidate names on
this page: http://governance.openstack.org/election/#
pike

-ptl-candidates


Happy voting,

- Kendall Nelson (diablo_rojo)

[0] The list of the program projects eligible for electoral status:
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=

jan

-201

7

-elections

[1] Sign into review.openstack.org:
Go to Settings > Contact Information.
Look at the email listed as your Preferred Email.
That is where the ballot has been sent.
__
OpenStack Development Mailing 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] [watcher] meeting time and location change

2017-02-01 Thread Tony Breeds
On Wed, Feb 01, 2017 at 10:18:00PM +1100, Tony Breeds wrote:

> Just talking to myself but the current eavesdrop page shows:
> Page generated on 2017-01-12 15:06:44.58 UTC
> 
> So yeah it looks like the publish job failed.

Strange the publish job didn't run on the watcher update and the subsequent
jobs ran but failed in a way I can't find in the logs.

However a run from yesterday worked and the page is current.

/me leaves well enough alone for now.

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


[openstack-dev] [storlets] Boston OpenStack Summit presentation

2017-02-01 Thread Eran Rom

Dear storleters,
As the deadline approaches I was thinking about the following idea:

End-to-End deep learning with OpenStack Storlets

Imagine that you have a huge dataset from which you could extract  
information using machine learning algorithms. The problem is that  
datasets usually need to go through a long and tedious curing and  
pre-processing before they can be 'presented' to machine learning  
algorithm. With large dataset this can get really painful. In this  
talk we present how storlets can be used to do an end-to-end  
supervised deep learning, thus processing all the data 'in-place'  
saving huge amounts of BW. As an example We show face recognition that  
starts with off-the-camera jpegs. This involves the following steps:


1. find the face bounding box
2. extract the face part
3. resize to a pre-defined resolution
4. change to greyscale
5. transform into a matrix that can be presented to a learning algorithm
6. train the algorithm over a large training set

We show that all steps can be done using storlets from within a  
Jupyter notebook.



Anyone who is interested in taking part please let me know.
Also, this is just an initial suggestion, feel free to suggest other  
examples or ideas.


Best,
Eran



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


Re: [openstack-dev] [ironic] New mascot design

2017-02-01 Thread Julia Kreger
I think Jay has phrased it perfectly.  With the context of the earlier 
discussion and the rules put forth at the beginning of this logo creation 
effort, I feel like the 3.0 version is our only real option for an official 
mascot in line with our team’s spirit. +1 to version 3.0.

Long live pixieboots as stickers on our laptops to remember the earlier times.

-Julia

> On Feb 1, 2017, at 3:38 PM, Jay Faulkner  wrote:
> 
> Of the options presented, I think the new 3.0 version most brings to mind a 
> rocking bear.  It’s still tough to be OK with a new logo, given that pixie 
> boots is beloved by our team partially because Lucas took the time to make us 
> one — but it seems like not accepting a new logo created by the foundation 
> would lead to Ironic getting less marketing and resources, so I’m not keen to 
> go down that path. With that in mind, I’m +1 to version 3.0 of the bear.
> 
> -Jay
> 
>> On Feb 1, 2017, at 12:05 PM, Heidi Joy Tretheway  
>> wrote:
>> 
>> Hi Ironic team,
>> 
>> I’m sorry our second proposal again missed the mark. It wasn’t the 
>> illustrator’s intention to mimic the Bear Surprise painting that gained 
>> popularity in Russia as a meme. Our illustrator created a face-forward bear 
>> with paws shaped as if it had index and ring “fingers" down, like a hand 
>> gesture popular at a heavy metal concert. It was not meant to mimic the 
>> painting of a side-facing bear with paws and all “fingers" up to surprise. 
>> That said, once it’s seen, it’s tough to expect the community to un-see it, 
>> so we’ll take another approach.
>> 
>> The issue with your old mascot is twofold: it doesn’t fit the illustration 
>> style for the entire suite of 60+ mascots, and it contains a human-made 
>> element (drumsticks). As part of our overall guidelines, human-made objects 
>> and symbols were not allowed, and we applied these standards to all projects.
>> 
>> Your team told us you want a heavy metal bear, so we used the Kiss 
>> band-style makeup and the hand gesture to suggest metal without using an 
>> instrument or symbol. We tried to mimic your original logo’s expression. 
>> After releasing v1, we listened to your team’s comment that the first 
>> version was too angry looking, so you’ll see a range of expressions from 
>> fierce to neutral to happy. 
>> 
>> 
>> 
>> I’d love to find a compromise with your team that will be in keeping with 
>> the style of the project logo suite. I’ll watch your ML for additional 
>> concerns about this proposed v3:   
>> 
>> 
>> Our illustration team’s next step is to parse the community feedback from 
>> the Ironic team (note that there is a substantial amount of conflicting 
>> feedback from 21 members of your team) and determine if we have majority 
>> support for a single direction. 
>> 
>> While new project logos are optional, virtually every project asked be 
>> represented in our family of logos. Only logos in this new style will be 
>> used on the project navigator and in other promotional ways. 
>> 
>> Feel free to join me for a quick chat tomorrow at 9:30 a.m. Pacific:
>> Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/5038169769
>> Or iPhone one-tap (US Toll): +16465588656,5038169769# or 
>> +14086380968,5038169769#
>> Or Telephone: Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll) 
>> Meeting ID: 503 816 9769
>> International numbers available: 
>> https://zoom.us/zoomconference?m=E5Gcj6WHnrCsWmjQRQr7KFsXkP9nAIaP
>> 
>> 
>> 
>> 
>>  
>> Heidi Joy Tretheway
>> Senior Marketing Manager, OpenStack Foundation
>> 503 816 9769 | Skype: heidi.tretheway
>> 
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


Re: [openstack-dev] [ironic] New mascot design

2017-02-01 Thread John Villalovos
Of the proposed logos, I do like the latest version the best. It appears
friendly and fun. So I'm +1 on it.

On Wed, Feb 1, 2017 at 12:43 PM, Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> Hi,
>
> +1 to Jay, the 3.0 version looks ok - it is friendly and rocking :)
>
> Cheers,
>
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> On Wed, Feb 1, 2017 at 10:38 PM, Jay Faulkner  wrote:
>
>> Of the options presented, I think the new 3.0 version most brings to mind
>> a rocking bear.  It’s still tough to be OK with a new logo, given that
>> pixie boots is beloved by our team partially because Lucas took the time to
>> make us one — but it seems like not accepting a new logo created by the
>> foundation would lead to Ironic getting less marketing and resources, so
>> I’m not keen to go down that path. With that in mind, I’m +1 to version 3.0
>> of the bear.
>>
>> -Jay
>>
>> > On Feb 1, 2017, at 12:05 PM, Heidi Joy Tretheway <
>> heidi...@openstack.org> wrote:
>> >
>> > Hi Ironic team,
>> >
>> > I’m sorry our second proposal again missed the mark. It wasn’t the
>> illustrator’s intention to mimic the Bear Surprise painting that gained
>> popularity in Russia as a meme. Our illustrator created a face-forward bear
>> with paws shaped as if it had index and ring “fingers" down, like a hand
>> gesture popular at a heavy metal concert. It was not meant to mimic the
>> painting of a side-facing bear with paws and all “fingers" up to surprise.
>> That said, once it’s seen, it’s tough to expect the community to un-see it,
>> so we’ll take another approach.
>> >
>> > The issue with your old mascot is twofold: it doesn’t fit the
>> illustration style for the entire suite of 60+ mascots, and it contains a
>> human-made element (drumsticks). As part of our overall guidelines,
>> human-made objects and symbols were not allowed, and we applied these
>> standards to all projects.
>> >
>> > Your team told us you want a heavy metal bear, so we used the Kiss
>> band-style makeup and the hand gesture to suggest metal without using an
>> instrument or symbol. We tried to mimic your original logo’s expression.
>> After releasing v1, we listened to your team’s comment that the first
>> version was too angry looking, so you’ll see a range of expressions from
>> fierce to neutral to happy.
>> >
>> >
>> > 
>> > I’d love to find a compromise with your team that will be in keeping
>> with the style of the project logo suite. I’ll watch your ML for additional
>> concerns about this proposed v3:
>> > 
>> >
>> > Our illustration team’s next step is to parse the community feedback
>> from the Ironic team (note that there is a substantial amount of
>> conflicting feedback from 21 members of your team) and determine if we have
>> majority support for a single direction.
>> >
>> > While new project logos are optional, virtually every project asked be
>> represented in our family of logos. Only logos in this new style will be
>> used on the project navigator and in other promotional ways.
>> >
>> > Feel free to join me for a quick chat tomorrow at 9:30 a.m. Pacific:
>> > Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/5038169769
>> > Or iPhone one-tap (US Toll): +16465588656,5038169769# or +14086380968,
>> 5038169769#
>> > Or Telephone: Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US
>> Toll)
>> > Meeting ID: 503 816 9769
>> > International numbers available: https://zoom.us/zoomconference
>> ?m=E5Gcj6WHnrCsWmjQRQr7KFsXkP9nAIaP
>> >
>> >
>> >
>> >
>> >
>> > Heidi Joy Tretheway
>> > Senior Marketing Manager, OpenStack Foundation
>> > 503 816 9769 | Skype: heidi.tretheway
>> >
>> >
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] New mascot design

2017-02-01 Thread Pavlo Shchelokovskyy
Hi,

+1 to Jay, the 3.0 version looks ok - it is friendly and rocking :)

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Feb 1, 2017 at 10:38 PM, Jay Faulkner  wrote:

> Of the options presented, I think the new 3.0 version most brings to mind
> a rocking bear.  It’s still tough to be OK with a new logo, given that
> pixie boots is beloved by our team partially because Lucas took the time to
> make us one — but it seems like not accepting a new logo created by the
> foundation would lead to Ironic getting less marketing and resources, so
> I’m not keen to go down that path. With that in mind, I’m +1 to version 3.0
> of the bear.
>
> -Jay
>
> > On Feb 1, 2017, at 12:05 PM, Heidi Joy Tretheway 
> wrote:
> >
> > Hi Ironic team,
> >
> > I’m sorry our second proposal again missed the mark. It wasn’t the
> illustrator’s intention to mimic the Bear Surprise painting that gained
> popularity in Russia as a meme. Our illustrator created a face-forward bear
> with paws shaped as if it had index and ring “fingers" down, like a hand
> gesture popular at a heavy metal concert. It was not meant to mimic the
> painting of a side-facing bear with paws and all “fingers" up to surprise.
> That said, once it’s seen, it’s tough to expect the community to un-see it,
> so we’ll take another approach.
> >
> > The issue with your old mascot is twofold: it doesn’t fit the
> illustration style for the entire suite of 60+ mascots, and it contains a
> human-made element (drumsticks). As part of our overall guidelines,
> human-made objects and symbols were not allowed, and we applied these
> standards to all projects.
> >
> > Your team told us you want a heavy metal bear, so we used the Kiss
> band-style makeup and the hand gesture to suggest metal without using an
> instrument or symbol. We tried to mimic your original logo’s expression.
> After releasing v1, we listened to your team’s comment that the first
> version was too angry looking, so you’ll see a range of expressions from
> fierce to neutral to happy.
> >
> >
> > 
> > I’d love to find a compromise with your team that will be in keeping
> with the style of the project logo suite. I’ll watch your ML for additional
> concerns about this proposed v3:
> > 
> >
> > Our illustration team’s next step is to parse the community feedback
> from the Ironic team (note that there is a substantial amount of
> conflicting feedback from 21 members of your team) and determine if we have
> majority support for a single direction.
> >
> > While new project logos are optional, virtually every project asked be
> represented in our family of logos. Only logos in this new style will be
> used on the project navigator and in other promotional ways.
> >
> > Feel free to join me for a quick chat tomorrow at 9:30 a.m. Pacific:
> > Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/5038169769
> > Or iPhone one-tap (US Toll): +16465588656,5038169769# or +14086380968,
> 5038169769#
> > Or Telephone: Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US
> Toll)
> > Meeting ID: 503 816 9769
> > International numbers available: https://zoom.us/zoomconference?m=
> E5Gcj6WHnrCsWmjQRQr7KFsXkP9nAIaP
> >
> >
> >
> >
> >
> > Heidi Joy Tretheway
> > Senior Marketing Manager, OpenStack Foundation
> > 503 816 9769 | Skype: heidi.tretheway
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] New mascot design

2017-02-01 Thread Jay Faulkner
Of the options presented, I think the new 3.0 version most brings to mind a 
rocking bear.  It’s still tough to be OK with a new logo, given that pixie 
boots is beloved by our team partially because Lucas took the time to make us 
one — but it seems like not accepting a new logo created by the foundation 
would lead to Ironic getting less marketing and resources, so I’m not keen to 
go down that path. With that in mind, I’m +1 to version 3.0 of the bear.

-Jay

> On Feb 1, 2017, at 12:05 PM, Heidi Joy Tretheway  
> wrote:
> 
> Hi Ironic team,
> 
> I’m sorry our second proposal again missed the mark. It wasn’t the 
> illustrator’s intention to mimic the Bear Surprise painting that gained 
> popularity in Russia as a meme. Our illustrator created a face-forward bear 
> with paws shaped as if it had index and ring “fingers" down, like a hand 
> gesture popular at a heavy metal concert. It was not meant to mimic the 
> painting of a side-facing bear with paws and all “fingers" up to surprise. 
> That said, once it’s seen, it’s tough to expect the community to un-see it, 
> so we’ll take another approach.
>  
> The issue with your old mascot is twofold: it doesn’t fit the illustration 
> style for the entire suite of 60+ mascots, and it contains a human-made 
> element (drumsticks). As part of our overall guidelines, human-made objects 
> and symbols were not allowed, and we applied these standards to all projects.
> 
> Your team told us you want a heavy metal bear, so we used the Kiss band-style 
> makeup and the hand gesture to suggest metal without using an instrument or 
> symbol. We tried to mimic your original logo’s expression. After releasing 
> v1, we listened to your team’s comment that the first version was too angry 
> looking, so you’ll see a range of expressions from fierce to neutral to 
> happy. 
> 
> 
> 
> I’d love to find a compromise with your team that will be in keeping with the 
> style of the project logo suite. I’ll watch your ML for additional concerns 
> about this proposed v3:   
> 
>  
> Our illustration team’s next step is to parse the community feedback from the 
> Ironic team (note that there is a substantial amount of conflicting feedback 
> from 21 members of your team) and determine if we have majority support for a 
> single direction. 
> 
> While new project logos are optional, virtually every project asked be 
> represented in our family of logos. Only logos in this new style will be used 
> on the project navigator and in other promotional ways. 
> 
> Feel free to join me for a quick chat tomorrow at 9:30 a.m. Pacific:
> Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/5038169769
> Or iPhone one-tap (US Toll): +16465588656,5038169769# or 
> +14086380968,5038169769#
> Or Telephone: Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll) 
> Meeting ID: 503 816 9769
> International numbers available: 
> https://zoom.us/zoomconference?m=E5Gcj6WHnrCsWmjQRQr7KFsXkP9nAIaP
>  
> 
> 
> 
>   
> Heidi Joy Tretheway
> Senior Marketing Manager, OpenStack Foundation
> 503 816 9769 | Skype: heidi.tretheway
>   
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-02-01 Thread Emilien Macchi
On Wed, Feb 1, 2017 at 2:37 PM, John Trowbridge  wrote:
>
>
> On 01/30/2017 10:56 AM, Emilien Macchi wrote:
>> Sagi, you're now core on TripleO CI repo. Thanks for your hard work on
>> tripleo-quickstart transition, and also helping by keeping CI in good
>> shape, your work is amazing!
>>
>> Congrats!
>>
>> Note: I couldn't add you to tripleo-ci group, but only to tripleo-core
>> (Gerrit permissions), which mean you can +2 everything but we trust
>> you to use it only on tripleo-ci. I'll figure out the Gerrit
>> permissions later.
>>
>
> I also told Sagi that he should also feel free to +2 any
> tripleo-quickstart/extras patches which are aimed at transitioning
> tripleo-ci to use quickstart. I didn't really think about this as an
> extra permission, as any tripleo core has +2 on
> tripleo-quickstart/extras. However, I seem to have surprised the other
> quickstart cores with this. None were opposed to the idea, but just
> wanted to make sure that it was clearly communicated that this is allowed.
>
> If there is some objection to this, we can consider it further. FWIW,
> Sagi has been consistently providing high quality critical reviews for
> tripleo-quickstart/extras for some time now, and was pivotal in the
> setup of the quickstart based OVB job.

+1

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



-- 
Emilien Macchi

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


Re: [openstack-dev] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread Sean Dague
On 02/01/2017 12:24 PM, gordon chung wrote:
> 
> 
> On 01/02/17 12:15 PM, Sean Dague wrote:
>> What were you thinking about the messaging? TC resolution for
>> deprecation of postgresql as a first class backend?
>>
>> If setup tools want to support things, that's fine, just they do need to
>> realize they are owning that support its not coming from upstream.
> 
> possibly start there if we want to proceed with this or maybe it's not a 
> concern.

https://review.openstack.org/#/c/427880/ - resolution posted.

-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] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-02-01 Thread John Trowbridge


On 01/30/2017 10:56 AM, Emilien Macchi wrote:
> Sagi, you're now core on TripleO CI repo. Thanks for your hard work on
> tripleo-quickstart transition, and also helping by keeping CI in good
> shape, your work is amazing!
> 
> Congrats!
> 
> Note: I couldn't add you to tripleo-ci group, but only to tripleo-core
> (Gerrit permissions), which mean you can +2 everything but we trust
> you to use it only on tripleo-ci. I'll figure out the Gerrit
> permissions later.
> 

I also told Sagi that he should also feel free to +2 any
tripleo-quickstart/extras patches which are aimed at transitioning
tripleo-ci to use quickstart. I didn't really think about this as an
extra permission, as any tripleo core has +2 on
tripleo-quickstart/extras. However, I seem to have surprised the other
quickstart cores with this. None were opposed to the idea, but just
wanted to make sure that it was clearly communicated that this is allowed.

If there is some objection to this, we can consider it further. FWIW,
Sagi has been consistently providing high quality critical reviews for
tripleo-quickstart/extras for some time now, and was pivotal in the
setup of the quickstart based OVB job.

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


Re: [openstack-dev] [TripleO][CI] CI freeze and transition to quickstart

2017-02-01 Thread Juan Antonio Osorio
Well, even though it's an experimental job, the TLS-everywhere job
(fakeha-caserver) is quite stable at the moment; I still need to add the
novajoin service to it, to reflect what people will hopefully be using, but
other than that it's been running and doing fine. I would like to bring up
that currently, the oooq OVB jobs are incompatible with what we do with
that job.

Basically, from what I've understood, oooq OVB jobs use the undercloud
provided by the quintupleo stack, while currently in CI we rely on the node
provided by nodepool and install the undercloud there. For the
TLS-everywhere job, we use that undercloud as well, and spin up a very low
memory node to deploy FreeIPA in there, but this wouldn't be possible in
the oooq solution. I would like to discuss alternatives for this.

Any thoughts?

BR

On Wed, Feb 1, 2017 at 1:47 AM, Gabriele Cerami  wrote:

> Hi,
>
> despite CI freeze for substantial change is in order, I recognize
> there's always the need to add or modify slightly the jobs for
> important fixes or to improve debugging.
>
> Unfortunately in these days we are wrapping up the gap in feature
> coverage between tripleo-ci and quickstart, and any of those change is
> increasing the list of features to be added to the implementation,
> making the wrap a moving target.
> Also, I'm seen some more-than-minor changes merged in these days, and
> that is making this job even more difficult.
>
> For those reason, we're going to ask everybody, from this moment on, for
> every change proposed to tripleo-ci, to propose an equivalent change to
> quickstart, or, if it seems too difficult, to open a bug in quickstart,
> pointing at the change in tripleo-ci, with some explanation on why it's
> needed, if it's not already clear in the commit message.
>
> At the end of this week we're going to make the final cut to the list
> of features we're going to transition to quickstart. If a feature, a
> test, an improvement, a small fix is added in tripleo-ci without
> signaling quickstart in any way, the risk is that the change will go
> unnoticed, and will be lost in transition.
>
> thanks for your collaboration.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] OpenStack Summit Boston-CFP closes February 6th

2017-02-01 Thread Erin Disney
Hi Everyone-

Don’t forget: the Call for Presentations for the upcoming OpenStack Summit 
Boston closes next week! 

The submission deadline is February 6, 2017 at 11:59PM PDT (February 7, 2017 at 
6:59 UTC). 

Reminder: Proposed sessions must indicate a format: Panel, presentation or 
lightning talk. Each format has a maximum number of speakers associated. Panels 
are allowed a total of four speakers plus one moderator, whereas presentations 
and lightning talks are limited to two speakers. 

As a reminder, speakers are limited to a maximum of three submissions total. 

Contact speakersupp...@openstack.org  with 
any submission questions. 

BOSTON REGISTRATION 
Attendee registration is now open 
. Purchase your discounted 
early bird passes now. Prices will increase in mid March. 

SPONSORSHIP SALES
Summit sponsorship sales are also open. You can now sign the electronic 
contract here 
.
 If you plan to sponsor both 2017 OpenStack Summits (Boston in May & Sydney in 
November), then check out page 4 of the Boston Summit Sponsorship Prospectus 

 for a special 15% discount on Sydney Summit sponsorship packages. Please note 
this only applies to companies who sponsor both the Boston Summit and Sydney 
Summit. Full details of the sponsorship signing process are outlined here 
. 

If you have any general Summit questions, contact us at sum...@openstack.org 
. 


Erin Disney
OpenStack Marketing
e...@openstack.org 

__
OpenStack Development Mailing 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] [requirements] changing the order of values in upper-constraints.txt

2017-02-01 Thread Doug Hellmann
Excerpts from Andreas Jaeger's message of 2017-02-01 15:37:15 +0100:
> On 2017-02-01 15:27, Doug Hellmann  wrote:
> > [...]
> > Another option was to have the release bot continually propose
> > updates to the same patch, like we do with the global requirements
> > sync job. On any given day, that's going to cause a bunch of resets
> > on the patch, until we merge it. That will be particularly annoying
> > if we release something while the patch is in the gate queue ready
> > to be merged, but even in the check queue it will "waste" test nodes
> > on each reset.
> 
> Note that the proposal jobs can check whether a job is in the gate queue
> and do not propose anything at that time, see
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/common.sh#n69
> - the check_already_approved function.
> 
> Whether you want to use it in this case, is up to you. For these kind of
> jobs that run often, it might be a good idea,
> 
> Andreas

Oh, that's definitely a good option to have. Thanks for pointing that
out!

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] [ironic] New mascot design

2017-02-01 Thread Matt Riedemann

On 1/31/2017 7:28 PM, arkady.kanev...@dell.com wrote:

I think Russian already owns the bear.



^ is my favorite statement of the day. Thank you.

--

Thanks,

Matt Riedemann

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


Re: [openstack-dev] [ironic] New mascot design

2017-02-01 Thread John Villalovos
I prefer our current homegrown logo. I wish we could just keep using that.

On Wed, Feb 1, 2017 at 9:40 AM, Jay Faulkner  wrote:

> I concur with most of the other comments on the thread. I have a strong
> preference for our existing mascot, and don’t think the new one is an
> improvement.
>
> Thanks,
> Jay
>
> > On Jan 31, 2017, at 12:49 PM, Jim Rollenhagen 
> wrote:
> >
> > Hey ironic-ers,
> >
> > The foundation has passed along a new version of our mascot (attached)
> to us, and would like your feedback on it.
> >
> > They're hoping to have all mascot-related things ready in time for the
> PTG, so please do send your thoughts quickly, if you have them. :)
> >
> > // jim
> > ___
> ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [heat] Re-schedule for team meeting

2017-02-01 Thread Rico Lin
Dear Team

We have discussed in the team meeting this week about re-schedule our
current meeting from Wednesday 0800 and 1500 UTC bi-weekly.
As a result from last few releases, it seems we have fewer people attend
0800(and all of the attendees were also attend for 1500 meeting).
For centralized our team discussions and for efficiency, I would like to
propose we move to 1500 UTC weekly.
As for APAC, we still will have IRC channel and ML standby, and we
certainly willing to make extra meeting arrangements if required. I believe
our supports for APAC area remains the same.
If we didn't have any oppositions or further discussion before next weekly
meeting, we will move our meeting next week to 1500 UTC on Wednesday.


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] [craton] Proposing Harry Harrington for Craton core

2017-02-01 Thread Jim Baker
+1 to both recommendations by Sulo.

Let me also add: Harry has proven himself as a strong contributor to Craton
development. I have been especially impressed by how his work has helped
improve the quality and consistency of our coding; often while removing
large chunks of unnecessary code at the same time by being smarter. I look
forward to more great contributions by Harry as a core team member!

On Wed, Feb 1, 2017 at 4:05 AM, Sulochan Acharya 
wrote:

> Hi everyone,
>
> I would like to propose  Harry Harrington @git-harry to Craton core team.
> He has been doing a great job with both reviewing and proposing meaningful
> changes to craton project. I am confident Harry will be great help as
> craton core member.
>
> https://github.com/openstack/craton/commits/master?author=git-harry
>
>
> I am also proposing to remove Sean Roberts from core team at this time.
> Sean has been great help to get Craton started but has been busy with other
> duties lately. We would be delighted to add Sean back in the future when
> his reviewing picks up again.
>
>
> Thanks,
> Sulo
>
> __
> OpenStack Development Mailing 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] gate jobs - papercuts

2017-02-01 Thread Davanum Srinivas
Thanks Melanie! Since the last report 4 hours ago, the
ServersNegativeTestJSON failed 8 more times.

Is the following one of the libvirt ones?

http://logs.openstack.org/24/425924/2/gate/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/f1b9229/logs/testr_results.html.gz
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2

Thanks,
Dims


On Wed, Feb 1, 2017 at 12:29 PM, melanie witt  wrote:
> On Wed, 1 Feb 2017 08:06:41 -0500, Davanum Srinivas wrote:
>>
>> Three more from this morning, at least the first one looks new:
>>
>>
>> http://logs.openstack.org/04/426604/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/708771d/logs/testr_results.html.gz
>> tempest.api.compute.images.test_list_image_filters
>>
>>
>> http://logs.openstack.org/99/420299/3/gate/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/6e8d208/logs/testr_results.html.gz
>>
>> http://logs.openstack.org/23/427223/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/18e635a/logs/testr_results.html.gz
>> tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON
>
>
> The last two are https://launchpad.net/bugs/1660878 being worked on here
> https://review.openstack.org/#/c/427775
>
> -melanie
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
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] [ironic] New mascot design

2017-02-01 Thread Jay Faulkner
I concur with most of the other comments on the thread. I have a strong 
preference for our existing mascot, and don’t think the new one is an 
improvement.

Thanks,
Jay

> On Jan 31, 2017, at 12:49 PM, Jim Rollenhagen  wrote:
> 
> Hey ironic-ers,
> 
> The foundation has passed along a new version of our mascot (attached) to us, 
> and would like your feedback on it.
> 
> They're hoping to have all mascot-related things ready in time for the PTG, 
> so please do send your thoughts quickly, if you have them. :)
> 
> // jim
>  18.39.58.png>__
> OpenStack Development Mailing 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][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread gordon chung


On 01/02/17 12:15 PM, Sean Dague wrote:
> What were you thinking about the messaging? TC resolution for
> deprecation of postgresql as a first class backend?
>
> If setup tools want to support things, that's fine, just they do need to
> realize they are owning that support its not coming from upstream.

possibly start there if we want to proceed with this or maybe it's not a 
concern.

tbh, i'd favour something inline with what mriedem proposed as it seems 
to be the easier path but this is based solely on supporting both 
backends in telemetry projects so maybe it's more difficult for other 
projects and they have backend-specific performance tweaks. i'm working 
under impression there is more to this than just 'drop all postgresql 
gates'.

cheers,
-- 
gord

__
OpenStack Development Mailing 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][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread Sean Dague
On 02/01/2017 12:21 PM, Julien Danjou wrote:
> On Wed, Feb 01 2017, Sean Dague wrote:
> 
>> If setup tools want to support things, that's fine, just they do need to
>> realize they are owning that support its not coming from upstream.
> 
> The problem as I see it right now is that upstream is schizophrenic: it
> seems it does not want to support nor gate on PostgreSQL but (have to)
> fix bug when they arise.
> 
> So what's the call?

I would call it class B support. Upstream(s) can decide to take user
fixes, we're just not going to really test them or consider it supported.

Honestly, it's basically the contract that you get with most software
that doesn't have the high level of CI you get from OpenStack. In a
finite world, you have to pick what gets the class A treatment
(including gating). The rest of it is accept user fixes if there is time.

-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] gate jobs - papercuts

2017-02-01 Thread melanie witt

On Wed, 1 Feb 2017 08:06:41 -0500, Davanum Srinivas wrote:

Three more from this morning, at least the first one looks new:

http://logs.openstack.org/04/426604/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/708771d/logs/testr_results.html.gz
tempest.api.compute.images.test_list_image_filters

http://logs.openstack.org/99/420299/3/gate/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/6e8d208/logs/testr_results.html.gz
http://logs.openstack.org/23/427223/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/18e635a/logs/testr_results.html.gz
tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON


The last two are https://launchpad.net/bugs/1660878 being worked on here 
https://review.openstack.org/#/c/427775


-melanie

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


Re: [openstack-dev] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread Julien Danjou
On Wed, Feb 01 2017, Sean Dague wrote:

> If setup tools want to support things, that's fine, just they do need to
> realize they are owning that support its not coming from upstream.

The problem as I see it right now is that upstream is schizophrenic: it
seems it does not want to support nor gate on PostgreSQL but (have to)
fix bug when they arise.

So what's the call?

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


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


[openstack-dev] [TripleO][Networking] Routed Networking Deployment Specs

2017-02-01 Thread Dan Sneddon
I have published specs [1] [2] [3] [4] and blueprints [5] [6] [7] [8] for
review for Pike that cover the changes required to deploy onto routed (AKA
spine-and-leaf or Clos) networks with TripleO. These need some review, and
there are still some technical decisions that need to be nailed down. I
also need some volunteers to help me implement this, in particular with the
changes required to the TripleO Heat Templates to allow for multiple
subnets per network.

I tried to focus on the problem rather than the solution, but where I
thought there was a clear solution, I provided as much detail as I could.
There are some instances where I presented more than one possible solution.
These specs are quite lengthy at the moment, but I expect that we can trim
them down as we narrow the focus and make final technical decisions as a group.

Please review these specs when you have some time, all feedback is welcome.
This is one of our highest priority features for Pike. Please let me know
if you are interested in helping with this effort.

[1] - https://review.openstack.org/421009  (master blueprint)
[2] - https://review.openstack.org/421010  (routed ctlplane IP)
[3] - https://review.openstack.org/421011  (Ironic Inspector)
[4] - https://review.openstack.org/425464  (THT changes)

[5] -
https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-deployment
[6] -
https://blueprints.launchpad.net/tripleo/+spec/tripleo-predictable-ctlplane-ips
[7] -
https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-ironic-inspector
[8] -
https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-templates
--
Dan Sneddon |  Senior Principal OpenStack Engineer
dsned...@redhat.com |  redhat.com/openstack
dsneddon:irc|  @dxs:twitter


__
OpenStack Development Mailing 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][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread Sean Dague
On 02/01/2017 12:12 PM, gordon chung wrote:
> 
> 
> On 01/02/17 11:42 AM, Monty Taylor wrote:
>> As I mentioned before, I don't think it matters which of the two we pick
>> - although I know _way_ more about MySQL personally and it has a much
>> more proven track record at absurdly large scale - I just argue that we
>> should pick one and then actually design our database interactions based
>> on how that one works.
>>
>> I don't actually expect us to decide to do that, of course. Why would we
>> ever say no to more places for people to express their desire for
>> difference? But I strongly believe it would be in the best interests of
>> OpenStack if we did.
> 
> all for a slimmer openstack.
> 
> so Julien's initial query regarding postgresql. if we only do test one 
> and only one, i don't think it's safe to say we support anything other 
> than that and we should probably be more consistent with this messaging? 
> right now postgresql is not just gated on in places, but can just as 
> easily be configured in dev environments, and is mentioned as supported 
> in our docs[1]. we'd probably have consider all the existing deployments 
> that leverage postgresql and what response to give them on either 
> migrating or some other alternative.
> 
> [1] 
> http://docs.openstack.org/newton/install-guide-rdo/environment-sql-database.html

What were you thinking about the messaging? TC resolution for
deprecation of postgresql as a first class backend?

If setup tools want to support things, that's fine, just they do need to
realize they are owning that support its not coming from upstream.

-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] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread gordon chung


On 01/02/17 11:42 AM, Monty Taylor wrote:
> As I mentioned before, I don't think it matters which of the two we pick
> - although I know _way_ more about MySQL personally and it has a much
> more proven track record at absurdly large scale - I just argue that we
> should pick one and then actually design our database interactions based
> on how that one works.
>
> I don't actually expect us to decide to do that, of course. Why would we
> ever say no to more places for people to express their desire for
> difference? But I strongly believe it would be in the best interests of
> OpenStack if we did.

all for a slimmer openstack.

so Julien's initial query regarding postgresql. if we only do test one 
and only one, i don't think it's safe to say we support anything other 
than that and we should probably be more consistent with this messaging? 
right now postgresql is not just gated on in places, but can just as 
easily be configured in dev environments, and is mentioned as supported 
in our docs[1]. we'd probably have consider all the existing deployments 
that leverage postgresql and what response to give them on either 
migrating or some other alternative.

[1] 
http://docs.openstack.org/newton/install-guide-rdo/environment-sql-database.html

-- 
gord

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


Re: [openstack-dev] [ironic] New mascot design

2017-02-01 Thread Loo, Ruby
Hi,

I don't like the new one. I think Lucas captured it nicely. I prefer our 
PixieBoots.

Jim, do you remember what our choices are? Could we use PixieBoots?

--ruby

From: Lucas Alvares Gomes 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, January 31, 2017 at 5:13 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [ironic] New mascot design

I may be biased to some extent but I don't like it.

The mascot doesn't seem to have any personality. It also looks odd
because he has this straight face while he's doing the sign of horns,
it just doesn't work.

I remember when I first saw a logo related to Ironic in that
presentation that Jay and Josh made in the Atlanta summit (2014),
check it out: https://www.youtube.com/watch?v=2Oi2T2pSGDU=96s

That's a rocker bear. It has a rockstar pose, it has an expression,
the paul stanley star on his face is pretty cool, it's holding a
awesome guitar, etc etc etc... When I think that someone is paying a
professional to create the mascots that's the level of design that I
expect. Now, the proposed bear doesn't even incorporate the main
elements of PixieBoots: 1) It doesn't look like a rockstar and 2) He's
not a drummer [0] (PixeBoots is a drummer bear!).

I have no problem with minimalist logos, I actually like then a lot
but the idea is to capture the essence of something using a simple
design. This one just looks poorly thought out and simpleminded.

[0] 
https://wiki.openstack.org/wiki/Ironic#Pixie_Boots.2C_the_Ironic_drummer_bear

Cheers,
Lucas

On Tue, Jan 31, 2017 at 8:49 PM, Jim Rollenhagen 
> wrote:
Hey ironic-ers,

The foundation has passed along a new version of our mascot (attached) to
us, and would like your feedback on it.

They're hoping to have all mascot-related things ready in time for the PTG,
so please do send your thoughts quickly, if you have them. :)

// jim

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


__
OpenStack Development Mailing 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][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread Monty Taylor
On 02/01/2017 10:06 AM, gordon chung wrote:
> 
> 
> On 01/02/17 10:22 AM, Monty Taylor wrote:
>>
>> I personally continue to be of the opinion that without an explicit
>> vocal and well-staffed champion, supporting postgres is more trouble
>> than it is worth. The vast majority of OpenStack deployments are on
>> MySQL - and what's more, the code is written with MySQL in mind.
>> Postgres and MySQL have different trade offs, different things each are
>> good at and different places in which each has weakness. By attempting
>> to support Postgres AND MySQL, we prevent ourselves from focusing
>> adequate attention on making sure that our support for one of them is
>> top-notch and in keeping with best practices for that database.
> 
> is there actually mysql only code or do you mean that once things pass 
> on gate with mysql, devs are happy? if the former, i understand not 
> wanting to have to hack postgresql to pass gate.
> 
>>
>> So let me state my opinion slightly differently. I think we should
>> support one and only one RDBMS backend for OpenStack, and we should open
>> ourselves up to use advanced techniques for that backend. I don't
>> actually care whether that DB is MySQL or Postgres - but the corpus of
>> existing deployments on MySQL and the existing gate jobs I think make
>> the choice one way or the other simple.
>>
> 
> i just want to point out that the current bug passes in mysql because 
> it's more lax in how it parses sql and allows for some 
> non-deterministism. the postgresql gate arguably caught bad sql which is 
> a good thing? ideally, i'd like to have postgresql tested as well but it 
> may be because most/all telemetry's sql backend hacks were required 
> because of mysql and not postgres.

MySQL has the ability to be stricter in what how it parses and what it
accepts. If that is a thing we value, we could totally do some work to
bump up the MySQL strictness mode and keep it there.

That said - 'bad sql' isn't a construct that exists in a vacuum. SQL is
merely a tool to talk to an engine. So while MySQL may allow some SQL
that Postgres would refuse to parse, the ultimate goal is getting data
in and out of the backend database in a manner that is efficient. That's
important (and the real thing I'm on about with all of this) because
MySQL and Postgres have very different query optimizers and deal with
indexing differently. So a query that's written "well" for one of them
can be terrible in the other and vice veras. That doesn't make either
query "invalid" - it makes that query a bad query for that engine.

For instance, InnoDB with MySQL stores rows in a B+ tree clustered by
primary key. Secondary indexes store references to the primary key,
because the clustered primary key nature makes the primary key index a
covering index so a secondary index can get to the data with two
operations. However, since the secondary index holds the primary key, in
many cases it can be much more efficient to add an artificial autoinc
primary key to the table than to use a natural primary key like a UUID,
otherwise the seconary index is going to take much more memory and scans
will have to swap in and out of buffers more. That's a table design idea
that comes from knowing how the underlying storage engine works and also
how index scans use buffers and caches during query processing. The same
design may not be a good choice in Postgres.

While it's quite awesome that SQL is somewhat of a standard-ish (not
that anyone actually cares about the actual standard, which MySQL
implements, as opposed to what is considered the de-facto standard which
is Oracle's fork that Postgres implements) - the underlying engine
differences make writing code that is portable across database engines
not worth the effort except in small or trivial applications, IMO. For
things that aim for actual massive scale, designing the database to take
advantage of the actual characteristics of the database engine is paramount.

As I mentioned before, I don't think it matters which of the two we pick
- although I know _way_ more about MySQL personally and it has a much
more proven track record at absurdly large scale - I just argue that we
should pick one and then actually design our database interactions based
on how that one works.

I don't actually expect us to decide to do that, of course. Why would we
ever say no to more places for people to express their desire for
difference? But I strongly believe it would be in the best interests of
OpenStack if we did.

> full disclaimer: i use postgres for local dev and mysql for my 
> 'production' (because packstack didn't do postgres). aka i use whatever 
> is easier to install.
> 
> cheers,
> 


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


Re: [openstack-dev] [kolla] Domains support

2017-02-01 Thread Dave Walker
Hi Christian,

I added the domain support, but I didn't document it as well as I should
have. Apologies!

This is the config I am using to talk to a windows AD server.  Hope this
helps.

create a domain specific file:
etc/keystone/domains/keystone.$DOMAIN.conf:

[ldap]
use_pool = true
pool_size = 10
pool_retry_max = 3
pool_retry_delay = 0.1
pool_connection_timeout = -1
pool_connection_lifetime = 600
use_auth_pool = false
auth_pool_size = 100
auth_pool_connection_lifetime = 60
url = ldap://server1:389,ldap://server2:389
user = CN=Linux SSSD Kerberos Service Account,CN=Users,DC=example,DC=com
password = password
suffix   = dc=example,dc=com
user_tree_dn =
OU=Personnel,OU=Users,OU=example,DC=example,DC=com
user_objectclass = person
user_filter  = (memberOf=CN=mail,OU=GPO
Security,OU=Groups,OU=COMPANY,DC=example,DC=com)
user_id_attribute= sAMAccountName
user_name_attribute  = sAMAccountName
user_description_attribute = displayName
user_mail_attribute  = mail
user_pass_attribute  =
user_enabled_attribute   = userAccountControl
user_enabled_mask= 2
user_enabled_default = 512
user_attribute_ignore= password,tenant_id,tenants
group_tree_dn= OU=GPO
Security,OU=Groups,OU=COMPANY,DC=example,DC=com
group_name_attribute = name
group_id_attribute   = cn
group_objectclass= group
group_member_attribute   = member

[identity]
driver = keystone.identity.backends.ldap.Identity

[assignment]
driver = keystone.assignment.backends.sql.Assignment

--
Kind Regards,
Dave Walker

On 1 February 2017 at 05:03, Christian Tardif 
wrote:

> Hi,
>
> I'm looking for domains support in Kolla. I've searched, but didn't find
> anything relevant. Could someone point me how to achieve this?
>
> What I'm really looking for, in fact, is a decent way or setting auth
> through LDAP backend while keeping service users (neutron, for example) in
> the SQL backend. I know that this can be achieved with domains support
> (leaving default domain on SQL, and another domain for LDAP users. Or maybe
> there's another of doing this?
>
> Thanks,
> --
>
>
> *Christian Tardif*christian.tar...@servinfo.ca
>
> __
> OpenStack Development Mailing 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] [keystone] Do we really need two listening ports ?

2017-02-01 Thread Monty Taylor
On 02/01/2017 09:35 AM, Dolph Mathews wrote:
> On Wed, Feb 1, 2017 at 6:59 AM Thomas Goirand  > wrote:
> 
> On 02/01/2017 10:54 AM, Attila Fazekas wrote:
> > Hi all,
> >
> > Typically we have two keystone service listening on two separate ports
> > 35357 and 5000.
> >
> > Historically one of the port had limited functionality, but today I do
> > not see why we want
> > to have two separate service/port from the same code base for similar
> > purposes.
> 
> 
> If you're running v2, you do need two endpoints (admin and public;
> keystone does not really have a use case for an internal endpoint). The
> specific port numbers don't particularly matter (other than 35357 is
> conveniently registered with IANA) and should not be hardcoded or
> assumed by clients (and are not, AFAIK). In the case of v2, it is
> effectively a different service running on each port; there's at least
> one unfortunately subtle difference in behavior between admin and public.
> 
> If you're *only* running v3, you can run a single process and put the
> same endpoint URL in the service catalog, for both the admin and public
> endpoint. Arbitrary ports don't matter (so just use 443).

Yes. Please just use 443. The entire idea from the early days of
OpenStack of these services having their own ports is one of the
craziest and crack-addled ideas that OpenStack ever had and should die a
violent death as soon as humanly possible.

> 
> >
> > Effective we use double amount of memory than it is really required,
> > because both port is served by completely different worker instances,
> > typically from the same physical server.
> >
> > I wonder, would it be difficult to use only a single port or at least
> > the same pool of workers for all keystone(identity, auth..) purposes?
> >
> > Best Regards,
> > Attila
> 
> This has been discussed and agreed a long time ago, but nobody did the
> work.
> 
> 
> A lot of work has gone into freeing keystone from having to run on two
> ports (Adam Young, in particular, deserves a ton of credit here). You
> just need to consume that operational flexibility.
>  
> 
> Please do get rid of the 2nd port. And when you're at it, also get
> rid of the admin and internal endpoint in the service catalog.
> 
> 
> v3 has never presumed anything other than a public endpoint. Admin and
> internal are strictly optional and only exist for backwards
> compatibility with v2 (so, just use v3).
>  
> 
>  
> 
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> -- 
> -Dolph
> 
> 
> __
> OpenStack Development Mailing 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] [acceleration]Team Biweekly Meeting Agenda 2017.02.01

2017-02-01 Thread Zhipeng Huang
Hi Team,

Thanks for participating the meeting today, we had a great session, please
see the minutes here:
https://wiki.openstack.org/wiki/Cyborg/MeetingLogs#2017

Reminder for our PTG f2f session: it'll be a half-day or full-day session
on Wed, not only an hour

On Wed, Feb 1, 2017 at 8:55 PM, Zhipeng Huang  wrote:

> Hi Team,
>
> Please find the initial agenda at https://wiki.openstack.org/
> wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>



-- 
Zhipeng (Howard) Huang

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

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

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


Re: [openstack-dev] [keystone] Do we really need two listening ports ?

2017-02-01 Thread Brant Knudson
On Wed, Feb 1, 2017 at 3:54 AM, Attila Fazekas  wrote:

> Hi all,
>
> Typically we have two keystone service listening on two separate ports
> 35357 and 5000.
>
> Historically one of the port had limited functionality, but today I do not
> see why we want
> to have two separate service/port from the same code base for similar
> purposes.
>
> Effective we use double amount of memory than it is really required,
> because both port is served by completely different worker instances,
> typically from the same physical server.
>
> I wonder, would it be difficult to use only a single port or at least the
> same pool of workers for all keystone(identity, auth..) purposes?
>
> Best Regards,
> Attila
>
>
Keystone is a wsgi application and so can be run in a web server that
forwards requests under /identity to the v2 public and v3 handlers; and
/identity_admin to the v2 admin and v3 handlers. 35357 and 5000 are not a
requirement imposed by keystone.

If you run this way you might find that applications using keystone won't
work correctly in all cases since they make the assumption that they can
build identity endpoints by truncating the URL.

Another popular deployment option is to have the different keystones on
different hosts (like identity.example.com and identity_admin.example.com).

- Brant
__
OpenStack Development Mailing 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][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread gordon chung


On 01/02/17 10:22 AM, Monty Taylor wrote:
>
> I personally continue to be of the opinion that without an explicit
> vocal and well-staffed champion, supporting postgres is more trouble
> than it is worth. The vast majority of OpenStack deployments are on
> MySQL - and what's more, the code is written with MySQL in mind.
> Postgres and MySQL have different trade offs, different things each are
> good at and different places in which each has weakness. By attempting
> to support Postgres AND MySQL, we prevent ourselves from focusing
> adequate attention on making sure that our support for one of them is
> top-notch and in keeping with best practices for that database.

is there actually mysql only code or do you mean that once things pass 
on gate with mysql, devs are happy? if the former, i understand not 
wanting to have to hack postgresql to pass gate.

>
> So let me state my opinion slightly differently. I think we should
> support one and only one RDBMS backend for OpenStack, and we should open
> ourselves up to use advanced techniques for that backend. I don't
> actually care whether that DB is MySQL or Postgres - but the corpus of
> existing deployments on MySQL and the existing gate jobs I think make
> the choice one way or the other simple.
>

i just want to point out that the current bug passes in mysql because 
it's more lax in how it parses sql and allows for some 
non-deterministism. the postgresql gate arguably caught bad sql which is 
a good thing? ideally, i'd like to have postgresql tested as well but it 
may be because most/all telemetry's sql backend hacks were required 
because of mysql and not postgres.

full disclaimer: i use postgres for local dev and mysql for my 
'production' (because packstack didn't do postgres). aka i use whatever 
is easier to install.

cheers,
-- 
gord

__
OpenStack Development Mailing 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] [requirements][neutron] bot bumping patches off gate queue

2017-02-01 Thread Ihar Hrachyshka
On Wed, Feb 1, 2017 at 7:42 AM, Armando M.  wrote:
>
>
> On 1 February 2017 at 07:29, Ihar Hrachyshka  wrote:
>>
>> Hi all,
>>
>> lately I see the requirements bot proposing new rebases for its
>> patches (and bumping existing patch sets from the gate queue) every
>> second hour, at least for Neutron [1], which makes it impossible to
>> land the patches, and which only makes gate pre-release situation
>> worse. On top of that, the proposed rebases don't really add anything
>> material to the sync patch, no new version changes and such.
>>
>> I think we had some guards against such behavior before, so I wonder
>> if they were broken or removed lately? Any plans to fix that?
>>
>> It would be nice to be able to land the update before RC1 is cut off,
>> but at this point, it does not seem realistic.
>>
>> [1] https://review.openstack.org/#/c/423645/
>>
>
> Let's stop merging until the bot proposal change lands. That ought to stop
> the spurious rebase!
>
> Hard times require hard measures!!

That's assuming it's triggered by neutron merges. It may as well be
requirements merges that trigger rebases. Something that I believe
requirements team will help us to understand.

Ihar

__
OpenStack Development Mailing 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] [requirements][neutron] bot bumping patches off gate queue

2017-02-01 Thread Armando M.
On 1 February 2017 at 07:29, Ihar Hrachyshka  wrote:

> Hi all,
>
> lately I see the requirements bot proposing new rebases for its
> patches (and bumping existing patch sets from the gate queue) every
> second hour, at least for Neutron [1], which makes it impossible to
> land the patches, and which only makes gate pre-release situation
> worse. On top of that, the proposed rebases don't really add anything
> material to the sync patch, no new version changes and such.
>
> I think we had some guards against such behavior before, so I wonder
> if they were broken or removed lately? Any plans to fix that?
>
> It would be nice to be able to land the update before RC1 is cut off,
> but at this point, it does not seem realistic.
>
> [1] https://review.openstack.org/#/c/423645/
>
>
Let's stop merging until the bot proposal change lands. That ought to stop
the spurious rebase!

Hard times require hard measures!!


> Thanks for help,
> Ihar
>
> __
> OpenStack Development Mailing 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][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread Chris Friesen

On 02/01/2017 09:18 AM, Sean Dague wrote:

On 02/01/2017 10:12 AM, Matt Riedemann wrote:

On 2/1/2017 8:07 AM, Julien Danjou wrote:
It's not just Nova, it's the entire set of integrated-gate jobs which
dropped the postgresql job. There is a bit more history there, it's in
the ML somewhere, but it's not just like Nova decided to stop running it
in the integrated gate.

At the time it was removed, I said I thought it might be a good idea to
run it on oslo.db changes, or at least in a periodic job queue, but
since we removed it from the integrated-gate set of jobs I wouldn't just
make it gating by itself on nova again.

If it could be worked into an existing job as a wrinkle then that's an
option, i.e. nova has this placement job which was unique in newton
because it ran the optional things at the time for nova like placement
and cells v2, but those are required globally now in master so are less
special. But in Pike we're going to be looking at some new snowflakes
for that job, like cinder v3, service users, etc etc, so maybe postgres
could be worked in there.


The user survey showed almost no one actually using postgresql in
production. I think that it's time to really retire CI on postgresql
entirely. Ad hoc fixes are fine, but all the documentation and basically
all the users are on mysql, and that should be the focus moving forward.


As someone using PostgreSQL in production, that would be unfortunate. :)

Chris


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


Re: [openstack-dev] [keystone] Do we really need two listening ports ?

2017-02-01 Thread Dolph Mathews
On Wed, Feb 1, 2017 at 6:59 AM Thomas Goirand  wrote:

> On 02/01/2017 10:54 AM, Attila Fazekas wrote:
> > Hi all,
> >
> > Typically we have two keystone service listening on two separate ports
> > 35357 and 5000.
> >
> > Historically one of the port had limited functionality, but today I do
> > not see why we want
> > to have two separate service/port from the same code base for similar
> > purposes.
>

If you're running v2, you do need two endpoints (admin and public; keystone
does not really have a use case for an internal endpoint). The specific
port numbers don't particularly matter (other than 35357 is conveniently
registered with IANA) and should not be hardcoded or assumed by clients
(and are not, AFAIK). In the case of v2, it is effectively a different
service running on each port; there's at least one unfortunately subtle
difference in behavior between admin and public.

If you're *only* running v3, you can run a single process and put the same
endpoint URL in the service catalog, for both the admin and public
endpoint. Arbitrary ports don't matter (so just use 443).


> >
> > Effective we use double amount of memory than it is really required,
> > because both port is served by completely different worker instances,
> > typically from the same physical server.
> >
> > I wonder, would it be difficult to use only a single port or at least
> > the same pool of workers for all keystone(identity, auth..) purposes?
> >
> > Best Regards,
> > Attila
>
> This has been discussed and agreed a long time ago, but nobody did the
> work.


A lot of work has gone into freeing keystone from having to run on two
ports (Adam Young, in particular, deserves a ton of credit here). You just
need to consume that operational flexibility.


> Please do get rid of the 2nd port. And when you're at it, also get
> rid of the admin and internal endpoint in the service catalog.


v3 has never presumed anything other than a public endpoint. Admin and
internal are strictly optional and only exist for backwards compatibility
with v2 (so, just use v3).


>


> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
-Dolph
__
OpenStack Development Mailing 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] [requirements][neutron] bot bumping patches off gate queue

2017-02-01 Thread Ihar Hrachyshka
Hi all,

lately I see the requirements bot proposing new rebases for its
patches (and bumping existing patch sets from the gate queue) every
second hour, at least for Neutron [1], which makes it impossible to
land the patches, and which only makes gate pre-release situation
worse. On top of that, the proposed rebases don't really add anything
material to the sync patch, no new version changes and such.

I think we had some guards against such behavior before, so I wonder
if they were broken or removed lately? Any plans to fix that?

It would be nice to be able to land the update before RC1 is cut off,
but at this point, it does not seem realistic.

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

Thanks for help,
Ihar

__
OpenStack Development Mailing 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][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread Monty Taylor
On 02/01/2017 09:12 AM, Matt Riedemann wrote:
> On 2/1/2017 8:07 AM, Julien Danjou wrote:
>> Hi there,
>>
>> So the Ceilometer gate has been broken again by Nova today because of a
>> SQL bug in the placement API with PostgreSQL. This is the second time
>> that something like that happened: last November¹, we also reported a
>> bug in Nova wrt PostgreSQL.
>>
>> Fortunately, Mehdi investigated and sent a fix:
>>
>>   https://review.openstack.org/#/c/427667/
>>
>> So the issue is going to be resolved soon. I had hope this would not
>> happen again, but it seems Nova does not care about PostgreSQL since
>> August².
>>
>> I think I can understand that Nova does not want to support PostgreSQL
>> and therefore does not use it in the gate, however, I don't think it's a
>> rich idea to have other projects (e.g. Ceilometer) doing the gate check
>> for Nova.
>>
>> My questions are simple and can be organized in a tree:
>>
>>Does Nova want to support PostgreSQL?
>>  /  \
>>Yes  No
>>/  \
>>Why is there no gate? Ok, we'll have to remove the
>>  PostgreSQL job in Ceilometer
>>
>>
>> Thanks!
>>
>>
>> ¹ 
>> http://lists.openstack.org/pipermail/openstack-dev/2016-November/107907.html
>>
>>
>> ² 
>> http://lists.openstack.org/pipermail/openstack-dev/2016-August/101892.html
>>
>>
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> It's not just Nova, it's the entire set of integrated-gate jobs which
> dropped the postgresql job. There is a bit more history there, it's in
> the ML somewhere, but it's not just like Nova decided to stop running it
> in the integrated gate.

Yah. Postgres support has historically been one of those things that
occasionally someone says "we should support postgres" - and then
consistently it breaks and nobody cares enough to fix it.

> At the time it was removed, I said I thought it might be a good idea to
> run it on oslo.db changes, or at least in a periodic job queue, but
> since we removed it from the integrated-gate set of jobs I wouldn't just
> make it gating by itself on nova again.
> 
> If it could be worked into an existing job as a wrinkle then that's an
> option, i.e. nova has this placement job which was unique in newton
> because it ran the optional things at the time for nova like placement
> and cells v2, but those are required globally now in master so are less
> special. But in Pike we're going to be looking at some new snowflakes
> for that job, like cinder v3, service users, etc etc, so maybe postgres
> could be worked in there.

I personally continue to be of the opinion that without an explicit
vocal and well-staffed champion, supporting postgres is more trouble
than it is worth. The vast majority of OpenStack deployments are on
MySQL - and what's more, the code is written with MySQL in mind.
Postgres and MySQL have different trade offs, different things each are
good at and different places in which each has weakness. By attempting
to support Postgres AND MySQL, we prevent ourselves from focusing
adequate attention on making sure that our support for one of them is
top-notch and in keeping with best practices for that database.

So let me state my opinion slightly differently. I think we should
support one and only one RDBMS backend for OpenStack, and we should open
ourselves up to use advanced techniques for that backend. I don't
actually care whether that DB is MySQL or Postgres - but the corpus of
existing deployments on MySQL and the existing gate jobs I think make
the choice one way or the other simple.

I agree that ceilometer should not be providing Postgres testing for the
rest of OpenStack.

Monty


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


Re: [openstack-dev] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread Sean Dague
On 02/01/2017 10:12 AM, Matt Riedemann wrote:
> On 2/1/2017 8:07 AM, Julien Danjou wrote:
> It's not just Nova, it's the entire set of integrated-gate jobs which
> dropped the postgresql job. There is a bit more history there, it's in
> the ML somewhere, but it's not just like Nova decided to stop running it
> in the integrated gate.
> 
> At the time it was removed, I said I thought it might be a good idea to
> run it on oslo.db changes, or at least in a periodic job queue, but
> since we removed it from the integrated-gate set of jobs I wouldn't just
> make it gating by itself on nova again.
> 
> If it could be worked into an existing job as a wrinkle then that's an
> option, i.e. nova has this placement job which was unique in newton
> because it ran the optional things at the time for nova like placement
> and cells v2, but those are required globally now in master so are less
> special. But in Pike we're going to be looking at some new snowflakes
> for that job, like cinder v3, service users, etc etc, so maybe postgres
> could be worked in there.

The user survey showed almost no one actually using postgresql in
production. I think that it's time to really retire CI on postgresql
entirely. Ad hoc fixes are fine, but all the documentation and basically
all the users are on mysql, and that should be the focus moving forward.

-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] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread Matt Riedemann

On 2/1/2017 8:07 AM, Julien Danjou wrote:

Hi there,

So the Ceilometer gate has been broken again by Nova today because of a
SQL bug in the placement API with PostgreSQL. This is the second time
that something like that happened: last November¹, we also reported a
bug in Nova wrt PostgreSQL.

Fortunately, Mehdi investigated and sent a fix:

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

So the issue is going to be resolved soon. I had hope this would not
happen again, but it seems Nova does not care about PostgreSQL since
August².

I think I can understand that Nova does not want to support PostgreSQL
and therefore does not use it in the gate, however, I don't think it's a
rich idea to have other projects (e.g. Ceilometer) doing the gate check
for Nova.

My questions are simple and can be organized in a tree:

   Does Nova want to support PostgreSQL?
 /  \
   Yes  No
   /  \
   Why is there no gate? Ok, we'll have to remove the
 PostgreSQL job in Ceilometer


Thanks!


¹  http://lists.openstack.org/pipermail/openstack-dev/2016-November/107907.html

²  http://lists.openstack.org/pipermail/openstack-dev/2016-August/101892.html



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



It's not just Nova, it's the entire set of integrated-gate jobs which 
dropped the postgresql job. There is a bit more history there, it's in 
the ML somewhere, but it's not just like Nova decided to stop running it 
in the integrated gate.


At the time it was removed, I said I thought it might be a good idea to 
run it on oslo.db changes, or at least in a periodic job queue, but 
since we removed it from the integrated-gate set of jobs I wouldn't just 
make it gating by itself on nova again.


If it could be worked into an existing job as a wrinkle then that's an 
option, i.e. nova has this placement job which was unique in newton 
because it ran the optional things at the time for nova like placement 
and cells v2, but those are required globally now in master so are less 
special. But in Pike we're going to be looking at some new snowflakes 
for that job, like cinder v3, service users, etc etc, so maybe postgres 
could be worked in there.


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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] [python3][ptg][goal] planning for python 3 discussions at the PTG

2017-02-01 Thread Julien Danjou
On Wed, Feb 01 2017, Doug Hellmann wrote:

> I've set up an etherpad for planning the python 3 goal work at the PTG
> [1]. We have space set aside for Monday and Tuesday, but I know some
> (all?) of the people involved will have multiple topics they need to
> cover those days so I also think it would be a good idea for us to
> coordinate who can be in the room at different times. There's a section
> of the etherpad for that, so please update it with your info if you are
> planning to help with the porting work (either as a guide or by focusing
> on an individual project).

Just to say, we're still more than happy to help with that effort and be
the guinea pig of whatever we can in Telemetry since we support Python 3
for a while now. However, none of us will be at the PTG since we did not
plan any Telemetry track.

So feel free to reach out to us online like… the rest of the year. ;)

Cheers,
-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


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


Re: [openstack-dev] gate jobs - papercuts

2017-02-01 Thread Andrea Frittoli
I actually ended-up proposing an update to the other bug, as the signature
was much closed [0]

andrea

[0] https://bugs.launchpad.net/nova/+bug/1643911
[1] https://review.openstack.org/427754

On Wed, Feb 1, 2017 at 1:50 PM Andrea Frittoli 
wrote:

> The first one is yet another flavour of libvirtd crash [0]:
>
> >> *** Error in `/usr/sbin/libvirtd': realloc(): invalid next size:
> 0x56108d7a7450 ***
>
> which adds to the list of three libvirt crash signatures listed by Jordan
> in [1].
> I guess this new (?) signature could be incorporated in bug [2] - I can
> update the E-R query for that.
>
> andrea
>
> [0]
> http://logs.openstack.org/04/426604/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/708771d/logs/syslog.txt.gz#_Feb_01_11_47_53
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2017-February/111347.html
>
> [2] https://bugs.launchpad.net/tempest/+bug/1646779
>
>
> On Wed, Feb 1, 2017 at 1:09 PM Davanum Srinivas  wrote:
>
> MattR,
>
> Three more from this morning, at least the first one looks new:
>
>
> http://logs.openstack.org/04/426604/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/708771d/logs/testr_results.html.gz
> tempest.api.compute.images.test_list_image_filters
>
>
> http://logs.openstack.org/99/420299/3/gate/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/6e8d208/logs/testr_results.html.gz
>
> http://logs.openstack.org/23/427223/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/18e635a/logs/testr_results.html.gz
> tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON
>
> Thanks,
> Dims
>
>
> On Tue, Jan 31, 2017 at 10:23 PM, Matt Riedemann 
> wrote:
> > On 1/31/2017 11:49 AM, Davanum Srinivas wrote:
> >>
> >> Folks,
> >>
> >> Here's the list of job failures that failed in the gate queue.
> >> captured with my script[1][2] since around 10:00 AM today. All jobs
> >> failed with just one bad test.
> >>
> >>
> >>
> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/
> >>-
> >>
> tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON
> >>
> >>
> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/
> >>  -
> tempest.api.compute.admin.test_servers.ServersAdminTestJSON
> >>
> >>
> http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/
> >>-
> tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON
> >>
> >>
> http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/
> >>  -
> >>
> tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON
> >>
> >>
> http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/
> >>- keystone.tests.unit.test_v3_auth.TestMFARules
> >>
> >>
> http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/
> >>   - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
> >>
> >>
> http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/
> >>-
> >>
> tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps
> >>
> >> So our gate is now 36 deep with stuff running for little more than 4
> >> hours repeatedly Can folks look deeper please?
> >>
> >> Thanks,
> >> Dims
> >>
> >> [1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e
> >> [2] http://paste.openstack.org/show/597071/
> >>
> >
> > I've identified a regression in nova here:
> >
> > https://bugs.launchpad.net/nova/+bug/1660878
> >
> > --
> >
> > Thanks,
> >
> > Matt Riedemann
> >
> >
> >
> __
> > OpenStack Development Mailing 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 Development Mailing 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-stable-maint] Stable check of openstack/ceilometer failed

2017-02-01 Thread gordon chung
thanks for bringing this up. below are the current statuses.

On 01/02/17 08:30 AM, Ian Cordasco wrote:
>> > Build failed.
>> >
>> > - periodic-ceilometer-docs-mitaka 
>> > http://logs.openstack.org/periodic-stable/periodic-ceilometer-docs-mitaka/3774607/
>> > : SUCCESS in 4m 09s
>> > - periodic-ceilometer-python27-mitaka 
>> > http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-mitaka/ca03c38/
>> > : FAILURE in 4m 09s
> This appears to be a problem with oslo.vmware interactions with spec'd
> mocks. It looks like y'all are mocking out some underlying part of
> oslo.vmware and it's being provided a parameter that it doesn't
> recognize.
>
> It also looks like ceilometer isn't using constraints on mitaka. The
> lack of constraints on mitaka was a problem for Glance's docs job. If
> ceilometer is using constraints on newer versions, perhaps it should
> consider backporting to stable/mitaka.

we'll probably need to backport: https://review.openstack.org/#/c/425005/

>
>> > - periodic-ceilometer-docs-newton 
>> > http://logs.openstack.org/periodic-stable/periodic-ceilometer-docs-newton/49e5570/
>> > : SUCCESS in 3m 08s
>> > - periodic-ceilometer-python27-newton 
>> > http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-newton/2088177/
>> > : FAILURE in 3m 08s
> This also looks like a possible constraints problem. Whatever version
> of gnocchiclient is being installed, the gnocchiclient.utils module
> doesn't have "encode_resource_id" present and so the tests fail.
>
> I suspect this is caused by some newer version of gnocchiclient being
> used than is actually supported for stable/newton.


we're currently trying to backport: 
https://review.openstack.org/#/c/427448/ but we need to handle some 
other gating issues first to get that merged.

hopefully have this merged soon. or my laptop will be snapped in two. so 
if you see a thinkpad in 2, then you know the status. :)

cheers,
-- 
gord
__
OpenStack Development Mailing 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] New driver project status?

2017-02-01 Thread Neil Jerram
Thanks Davanum.  Reading through those now...

On Wed, Feb 1, 2017 at 2:29 PM Davanum Srinivas  wrote:

> Neil,
>
> No, this has not reached a conclusion. There are 4 competing proposals
>
> https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:formal-vote+driver-teams
>
> -- Dims
>
> On Wed, Feb 1, 2017 at 9:21 AM, Neil Jerram  wrote:
> > I believe there was recently a discussion on one of the OpenStack MLs
> about
> > a possible new status for driver projects.  Unfortunately I'm not
> > immediately managing to find it in the archives.
> >
> > Did that discussion reach a conclusion, and - if so - is that documented
> > somewhere?
> >
> > Thanks,
> >  Neil
> >
> >
> >
> __
> > OpenStack Development Mailing 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 Development Mailing 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] [requirements] changing the order of values in upper-constraints.txt

2017-02-01 Thread Andreas Jaeger
On 2017-02-01 15:27, Doug Hellmann  wrote:
> [...]
> Another option was to have the release bot continually propose
> updates to the same patch, like we do with the global requirements
> sync job. On any given day, that's going to cause a bunch of resets
> on the patch, until we merge it. That will be particularly annoying
> if we release something while the patch is in the gate queue ready
> to be merged, but even in the check queue it will "waste" test nodes
> on each reset.

Note that the proposal jobs can check whether a job is in the gate queue
and do not propose anything at that time, see
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/common.sh#n69
- the check_already_approved function.

Whether you want to use it in this case, is up to you. For these kind of
jobs that run often, it might be a good idea,

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


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


[openstack-dev] [python3][ptg][goal] planning for python 3 discussions at the PTG

2017-02-01 Thread Doug Hellmann
I've set up an etherpad for planning the python 3 goal work at the PTG
[1]. We have space set aside for Monday and Tuesday, but I know some
(all?) of the people involved will have multiple topics they need to
cover those days so I also think it would be a good idea for us to
coordinate who can be in the room at different times. There's a section
of the etherpad for that, so please update it with your info if you are
planning to help with the porting work (either as a guide or by focusing
on an individual project).

Thanks,
Doug

[1] https://etherpad.openstack.org/p/ptg-pike-python35

__
OpenStack Development Mailing 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] New driver project status?

2017-02-01 Thread Davanum Srinivas
Neil,

No, this has not reached a conclusion. There are 4 competing proposals
https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:formal-vote+driver-teams

-- Dims

On Wed, Feb 1, 2017 at 9:21 AM, Neil Jerram  wrote:
> I believe there was recently a discussion on one of the OpenStack MLs about
> a possible new status for driver projects.  Unfortunately I'm not
> immediately managing to find it in the archives.
>
> Did that discussion reach a conclusion, and - if so - is that documented
> somewhere?
>
> Thanks,
>  Neil
>
>
> __
> OpenStack Development Mailing 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] [requirements] changing the order of values in upper-constraints.txt

2017-02-01 Thread Doug Hellmann
Excerpts from Tony Breeds's message of 2017-02-01 21:18:54 +1100:
> On Wed, Jan 18, 2017 at 04:34:56PM -0500, Doug Hellmann wrote:
> > When I tried to merge the upper-constraints updates for the library
> > releases we did today, I ran into quite a lot of merge conflicts
> > with the Oslo libraries. I'm exploring options for reducing the
> > likelihood that those sorts of conflicts will occur with a few
> > patches that change how we generate the constraints list.
> 
> Dirk's been doing a great job of dealing with that and there are scripts to
> take the ones generated from the bot and make single series from them n deep.
> That's not very sustainable though.
> 
> 
> 
> > The final option uses a SHA1 hash of the name as the sort key. It
> > wouldn't be easy for a human to update the file by hand, but we
> > could make a tool that does. I don't know how often that case comes
> > up, so I don't know how important it is. See
> > https://review.openstack.org/422245 and https://review.openstack.org/422246
> > for the sample output.
> 
> Thanks Doug.  I like this option.
> 
> We don't need to add a tool as the docs describe how to do this already, which
> basically boils down to run the tool you're patching.
> 
> If that doesn't happen (which is common) the next daily update will just move
> it to the new right place.
> 
> I think we should do this early after we branch requirements
> 
> Yours Tony.

While debugging the issues, although we learned that we're less
likely to have collisions by changing the order, it's not going to
be sufficient to deal with the problem posed when we have an Oslo
release set. Zuul is limited to managing 6 "unrelated" patches when
merging, so when we have more than 6 patches trying to merge it
will throw an error that looks like a conflict, even though there
isn't one.

We discussed (on IRC) a couple of options:

One is to do away with the proposals as part of the release jobs,
and rely on the daily update. I'm not sure I like that, because it
means if the update fails any tests we aren't introducing new
versions of our libraries quickly. Debugging that class of failure
is a job we've had a hard time recruiting people to help with, so
while the current team has been doing a great job staying on top
of it, I worry about what will happen when they get tired of doing
it. We did also discuss changing the frequency of the automatic
updates, but I think I was talked out of that on the grounds that
it takes us a day to get the patch reviewed and merged anyway so
running it more often would introduce delays because we would lose
review votes.

Another option was to have the release bot continually propose
updates to the same patch, like we do with the global requirements
sync job. On any given day, that's going to cause a bunch of resets
on the patch, until we merge it. That will be particularly annoying
if we release something while the patch is in the gate queue ready
to be merged, but even in the check queue it will "waste" test nodes
on each reset.

The third option suggested was to submit the updates in a series.
That allows us to merge them one at a time, and avoids the limit-of-6
issue because the patches are all related in a series. If something
fails, we can remove it from the series by hand and debug it
separately.

I've put this topic on the etherpad for the stable/requirements/release
team meetup at the PTG.

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] New driver project status?

2017-02-01 Thread Neil Jerram
I believe there was recently a discussion on one of the OpenStack MLs about
a possible new status for driver projects.  Unfortunately I'm not
immediately managing to find it in the archives.

Did that discussion reach a conclusion, and - if so - is that documented
somewhere?

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


Re: [openstack-dev] [keystone] Do we really need two listening ports ?

2017-02-01 Thread Sylvain Bauza


Le 01/02/2017 13:58, Thomas Goirand a écrit :
> On 02/01/2017 10:54 AM, Attila Fazekas wrote:
>> Hi all,
>>
>> Typically we have two keystone service listening on two separate ports
>> 35357 and 5000.
>>
>> Historically one of the port had limited functionality, but today I do
>> not see why we want
>> to have two separate service/port from the same code base for similar
>> purposes.
>>
>> Effective we use double amount of memory than it is really required,
>> because both port is served by completely different worker instances,
>> typically from the same physical server.
>>
>> I wonder, would it be difficult to use only a single port or at least
>> the same pool of workers for all keystone(identity, auth..) purposes?
>>
>> Best Regards,
>> Attila
> 
> This has been discussed and agreed a long time ago, but nobody did the
> work. Please do get rid of the 2nd port. And when you're at it, also get
> rid of the admin and internal endpoint in the service catalog.
> 

Only 35357 is declared as a regular IANA service port :
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=openstack

You can do whatever you want with the other port, that's a configuration
option.

-Sylvain

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

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


[openstack-dev] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

2017-02-01 Thread Julien Danjou
Hi there,

So the Ceilometer gate has been broken again by Nova today because of a
SQL bug in the placement API with PostgreSQL. This is the second time
that something like that happened: last November¹, we also reported a
bug in Nova wrt PostgreSQL.

Fortunately, Mehdi investigated and sent a fix:

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

So the issue is going to be resolved soon. I had hope this would not
happen again, but it seems Nova does not care about PostgreSQL since
August².

I think I can understand that Nova does not want to support PostgreSQL
and therefore does not use it in the gate, however, I don't think it's a
rich idea to have other projects (e.g. Ceilometer) doing the gate check
for Nova.

My questions are simple and can be organized in a tree:

   Does Nova want to support PostgreSQL?
 /  \
   Yes  No
   /  \
   Why is there no gate? Ok, we'll have to remove the 
 PostgreSQL job in Ceilometer


Thanks!


¹  http://lists.openstack.org/pipermail/openstack-dev/2016-November/107907.html

²  http://lists.openstack.org/pipermail/openstack-dev/2016-August/101892.html

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


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


Re: [openstack-dev] gate jobs - papercuts

2017-02-01 Thread Andrea Frittoli
The first one is yet another flavour of libvirtd crash [0]:

>> *** Error in `/usr/sbin/libvirtd': realloc(): invalid next size:
0x56108d7a7450 ***

which adds to the list of three libvirt crash signatures listed by Jordan
in [1].
I guess this new (?) signature could be incorporated in bug [2] - I can
update the E-R query for that.

andrea

[0]
http://logs.openstack.org/04/426604/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/708771d/logs/syslog.txt.gz#_Feb_01_11_47_53
[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-February/111347.html

[2] https://bugs.launchpad.net/tempest/+bug/1646779


On Wed, Feb 1, 2017 at 1:09 PM Davanum Srinivas  wrote:

MattR,

Three more from this morning, at least the first one looks new:

http://logs.openstack.org/04/426604/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/708771d/logs/testr_results.html.gz
tempest.api.compute.images.test_list_image_filters

http://logs.openstack.org/99/420299/3/gate/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/6e8d208/logs/testr_results.html.gz
http://logs.openstack.org/23/427223/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/18e635a/logs/testr_results.html.gz
tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON

Thanks,
Dims


On Tue, Jan 31, 2017 at 10:23 PM, Matt Riedemann 
wrote:
> On 1/31/2017 11:49 AM, Davanum Srinivas wrote:
>>
>> Folks,
>>
>> Here's the list of job failures that failed in the gate queue.
>> captured with my script[1][2] since around 10:00 AM today. All jobs
>> failed with just one bad test.
>>
>>
>>
http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/
>>-
>> tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON
>>
>>
http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/
>>  -
tempest.api.compute.admin.test_servers.ServersAdminTestJSON
>>
>>
http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/
>>- tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON
>>
>>
http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/
>>  -
>> tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON
>>
>>
http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/
>>- keystone.tests.unit.test_v3_auth.TestMFARules
>>
>>
http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/
>>   - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
>>
>>
http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/
>>-
>>
tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps
>>
>> So our gate is now 36 deep with stuff running for little more than 4
>> hours repeatedly Can folks look deeper please?
>>
>> Thanks,
>> Dims
>>
>> [1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e
>> [2] http://paste.openstack.org/show/597071/
>>
>
> I've identified a regression in nova here:
>
> https://bugs.launchpad.net/nova/+bug/1660878
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing 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 Development Mailing 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-stable-maint] Stable check of openstack/ceilometer failed

2017-02-01 Thread Ian Cordasco
-Original Message-
From: A mailing list for the OpenStack Stable Branch test reports.

Reply: openstack-dev@lists.openstack.org 
Date: February 1, 2017 at 00:11:20
To: openstack-stable-ma...@lists.openstack.org

Subject:  [Openstack-stable-maint] Stable check of openstack/ceilometer failed

> Build failed.
>
> - periodic-ceilometer-docs-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-ceilometer-docs-mitaka/3774607/
> : SUCCESS in 4m 09s
> - periodic-ceilometer-python27-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-mitaka/ca03c38/
> : FAILURE in 4m 09s

This appears to be a problem with oslo.vmware interactions with spec'd
mocks. It looks like y'all are mocking out some underlying part of
oslo.vmware and it's being provided a parameter that it doesn't
recognize.

It also looks like ceilometer isn't using constraints on mitaka. The
lack of constraints on mitaka was a problem for Glance's docs job. If
ceilometer is using constraints on newer versions, perhaps it should
consider backporting to stable/mitaka.

> - periodic-ceilometer-docs-newton 
> http://logs.openstack.org/periodic-stable/periodic-ceilometer-docs-newton/49e5570/
> : SUCCESS in 3m 08s
> - periodic-ceilometer-python27-newton 
> http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-newton/2088177/
> : FAILURE in 3m 08s

This also looks like a possible constraints problem. Whatever version
of gnocchiclient is being installed, the gnocchiclient.utils module
doesn't have "encode_resource_id" present and so the tests fail.

I suspect this is caused by some newer version of gnocchiclient being
used than is actually supported for stable/newton.

Cheers!
--
Ian Cordasco

__
OpenStack Development Mailing 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] gate jobs - papercuts

2017-02-01 Thread Davanum Srinivas
MattR,

Three more from this morning, at least the first one looks new:

http://logs.openstack.org/04/426604/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/708771d/logs/testr_results.html.gz
tempest.api.compute.images.test_list_image_filters

http://logs.openstack.org/99/420299/3/gate/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/6e8d208/logs/testr_results.html.gz
http://logs.openstack.org/23/427223/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/18e635a/logs/testr_results.html.gz
tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON

Thanks,
Dims


On Tue, Jan 31, 2017 at 10:23 PM, Matt Riedemann  wrote:
> On 1/31/2017 11:49 AM, Davanum Srinivas wrote:
>>
>> Folks,
>>
>> Here's the list of job failures that failed in the gate queue.
>> captured with my script[1][2] since around 10:00 AM today. All jobs
>> failed with just one bad test.
>>
>>
>> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/
>>-
>> tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON
>>
>> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/
>>  - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
>>
>> http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/
>>- tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON
>>
>> http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/
>>  -
>> tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON
>>
>> http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/
>>- keystone.tests.unit.test_v3_auth.TestMFARules
>>
>> http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/
>>   - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
>>
>> http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/
>>-
>> tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps
>>
>> So our gate is now 36 deep with stuff running for little more than 4
>> hours repeatedly Can folks look deeper please?
>>
>> Thanks,
>> Dims
>>
>> [1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e
>> [2] http://paste.openstack.org/show/597071/
>>
>
> I've identified a regression in nova here:
>
> https://bugs.launchpad.net/nova/+bug/1660878
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing 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] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-02-01 Thread Jiří Stránský

On 31.1.2017 19:08, Ben Nemec wrote:



On 01/31/2017 11:03 AM, James Slagle wrote:

On Tue, Jan 31, 2017 at 11:02 AM, Ben Nemec  wrote:

In the spirit of all the core team changes, here are a couple more I'd like
to propose.

Dmitry has been very helpful reviewing in instack-undercloud for a long time
so this is way overdue.  I'm also going to propose that he be able to +2
anything Ironic-related in TripleO since that is his primary area of
expertise.

Alex has ramped up quickly on TripleO and has also been helping out with
instack-undercloud quite a bit.  He's already core for the puppet modules,
and a lot of the changes to instack-undercloud these days are primarily in
the puppet manifest so it's not a huge stretch to add him.

As usual, TripleO cores please vote and/or provide comments.  Thanks.


+1 both



-Ben

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


+1. Dmitry is also one of the top reviewers and committers to
tripleo-docs. I wouldn't be opposed to him having +2 there as well.



Oh, good call.  I forgot to mention that too.  +1 to adding him as docs
core as well.


+1

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


Re: [openstack-dev] [keystone] Do we really need two listening ports ?

2017-02-01 Thread Thomas Goirand
On 02/01/2017 10:54 AM, Attila Fazekas wrote:
> Hi all,
> 
> Typically we have two keystone service listening on two separate ports
> 35357 and 5000.
> 
> Historically one of the port had limited functionality, but today I do
> not see why we want
> to have two separate service/port from the same code base for similar
> purposes.
> 
> Effective we use double amount of memory than it is really required,
> because both port is served by completely different worker instances,
> typically from the same physical server.
> 
> I wonder, would it be difficult to use only a single port or at least
> the same pool of workers for all keystone(identity, auth..) purposes?
> 
> Best Regards,
> Attila

This has been discussed and agreed a long time ago, but nobody did the
work. Please do get rid of the 2nd port. And when you're at it, also get
rid of the admin and internal endpoint in the service catalog.

Cheers,

Thomas Goirand (zigo)


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


[openstack-dev] [acceleration]Team Biweekly Meeting Agenda 2017.02.01

2017-02-01 Thread Zhipeng Huang
Hi Team,

Please find the initial agenda at
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting


-- 
Zhipeng (Howard) Huang

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

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

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


Re: [openstack-dev] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-02-01 Thread Ryan Brady
On Tue, Jan 31, 2017 at 11:02 AM, Ben Nemec  wrote:

> In the spirit of all the core team changes, here are a couple more I'd
> like to propose.
>
> Dmitry has been very helpful reviewing in instack-undercloud for a long
> time so this is way overdue.  I'm also going to propose that he be able to
> +2 anything Ironic-related in TripleO since that is his primary area of
> expertise.
>
> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet modules,
> and a lot of the changes to instack-undercloud these days are primarily in
> the puppet manifest so it's not a huge stretch to add him.
>
> As usual, TripleO cores please vote and/or provide comments.  Thanks.
>
> -Ben
>
> +1
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [containers][magnum] Swarm Mode template

2017-02-01 Thread Kevin Lefevre
On Tue, 2017-01-31 at 21:15 +0100, Spyros Trigazis wrote:
> Hi,
> 
> The hack-ish way is to check if the current master has a different ip
> than the
> swarm_api_api and based on that decide whether to swarm init or join.
> The
> proper way is to have two resource groups (as you said) one for the
> primary
> master and one for the secondary masters. This requires some plumping
> though.
> 
> We decided two have a _v2 driver in /contrib initially. I have a
> prototype working
> based on fedora-25 (docker 1.12.6). I can push and work together on
> it, if you
> want.

Yes I'd be happy to. I think this is something we should push forward
as swarm mode brings a lot more COE-like features (in comparison with
Kubernetes) than swarm legacy.

I'd also like to do the same with CoreOS :) 

> 
> Spyros
> 
> On 31 January 2017 at 20:52, Kevin Lefevre 
> wrote:
> > On Tue, 2017-01-31 at 17:01 +0100, Spyros Trigazis wrote:
> > > Hi.
> > >
> > > I have done it by checking the ip address of the master. The
> > current
> > > state of
> > > the heat drivers doesn't allow the distinction between master > 1
> > or
> > > master=1.
> > >
> > 
> > Please, could you elaborate on this ?
> > 
> > Also what is your opinion about starting a new swarm driver for
> > swarm
> > mode ?
> > 
> > > Spyros
> > >
> > >
> > >
> > > On 31 January 2017 at 16:33, Kevin Lefevre  > om>
> > > wrote:
> > > > Hi, Docker 1.13 has been released with several improvements
> > that
> > > > brings
> > > > swarm mode principles closer to Kubernetes such as docker-
> > compose
> > > > service swarm mode.
> > > >
> > > > I'd like to implement a v2 swarm template. I don't know if it's
> > > > already
> > > > been discussed.
> > > >
> > > > Swarm mode is a bit different but a lot simpler to deploy than
> > > > Swarm
> > > > Legacy.
> > > >
> > > > In Kubernetes you can deploy multiples masters at the same time
> > but
> > > > in
> > > > swarm mode you have to:
> > > > - bootstrap a first docker node
> > > > - run docker swarm init
> > > > - get a token (worker or manager)
> > > > - bootstrap other worker
> > > > - use manager or worker token depending manager count.
> > > >
> > > > I don't know what is the best way to do so in HEAT. I'm sure
> > there
> > > > are
> > > > multiple options (I'm not an expert in HEAT i don't know if
> > they
> > > > are
> > > > feasible) :
> > > >
> > > > - Bootstrap a first server
> > > > - Wait for it to ready, run docker swarm init, get both manager
> > and
> > > > worker tokens
> > > > - if manager count >1, we can bootstrap another resource group
> > for
> > > > extra managers which will use a manager token.
> > > > - Bootstrap the rest of the worker and use a worker token.
> > > >
> > > > The difficulty is to handle multiples master properly, i'd like
> > to
> > > > hear
> > > > your ideas about that.
> > > >
> > > >
> > > > --
> > > > Kevin Lefevre
> > > >
> > > >
> > ___
> > > > ___
> > > > OpenStack Development Mailing List (not for usage questions)
> > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> > unsu
> > > > bscribe
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-d
> > ev
> > > >
> > >
> > >
> > ___
> > __
> > > _
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > subs
> > > cribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > --
> > Kevin Lefevre
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- 
Kevin Lefevre

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


Re: [openstack-dev] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-02-01 Thread Dougal Matthews
+1

On 31 January 2017 at 16:02, Ben Nemec  wrote:

> In the spirit of all the core team changes, here are a couple more I'd
> like to propose.
>
> Dmitry has been very helpful reviewing in instack-undercloud for a long
> time so this is way overdue.  I'm also going to propose that he be able to
> +2 anything Ironic-related in TripleO since that is his primary area of
> expertise.
>
> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet modules,
> and a lot of the changes to instack-undercloud these days are primarily in
> the puppet manifest so it's not a huge stretch to add him.
>
> As usual, TripleO cores please vote and/or provide comments.  Thanks.
>
> -Ben
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [QA][Nova]Libvirt frequent crashes on Ubuntu Xenial

2017-02-01 Thread Jordan Pittier
Hi,
After investigating several gate failures and thanks to logstash, I
found out that Libvirtd often crashes badly on Ubuntu Xenial. I know
of 3 distinct crashes, with the following fingerprints in syslog.txt

* libvirtd: malloc.c:3720: _int_malloc: Assertion `(unsigned long)
(size) >= (unsigned long) (nb)' failed.
13 hits in the last 7 days. Somewhat reported in
https://bugs.launchpad.net/tempest/+bug/1646779

* traps: libvirtd[14731] general protection ip:7f2249691c4e
sp:7ffd2c223d70 error:0 in libc-2.23.so[7f224961+1bf000]
92 hits in the last 7 days. Somewhat reported in
https://bugs.launchpad.net/tempest/+bug/1646779

* *** Error in `/usr/sbin/libvirtd': malloc(): memory corruption:
0x55d6a8375ca0 ***
100 hits in the last 7 days. Somewhat reported in
https://bugs.launchpad.net/nova/+bug/1643911

Now, depending on how quick systemd detects these crashes and restart
libvirtd, not all of these hits lead to a job failure.

My C language skill is very low, and this is too low level for me to
track. But there's definitively something wrong that should be looked
after here. If anyone has some free cycles, that would be interesting
to track.

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


Re: [openstack-dev] [ironic] New mascot design

2017-02-01 Thread Mathieu Mitchell

See below.

On 2017-02-01 2:37 AM, Pavlo Shchelokovskyy wrote:

Hi all,

this new logo actually reminds me of a wide-spread Russian meme



Thanks for teaching us about this meme.

The new logo has a striking similarity with the meme. Is it possible 
that it was an inside joke / reference to that meme?


That alone should be enough to revisit it.

For the record, I still prefer Pixie Boots to all other iterations.



+1 to Lucas.

+1.



Mathieu Mitchell

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


Re: [openstack-dev] [cinder] Cinder with remote LVM proposal

2017-02-01 Thread Marco Marino
Hi Erlon, hi Philipp thank you for your answers.
I will try to explain with a real case:

@Erlon: I have 2 nodes that works as a SAN with targetcli and DRBD for a
raid over network. This cluster can be seen as an "ISCSI node".
Furthermore, I have 2 nodes with openstack-cinder-volume (with pacemaker).
Basically I have N iscsi devices here (from the ISCSI node) and on top of
those there is the cinder-volumes VG.
So, when a new volume in cinder is created, a new loigical volume will be
allocated in the cinder-volumes group. Using my solution I can merge the
cinder-volumes VG in the ISCSI node and move (for example) the
openstack-cinder-volume service on the controller because less power is
needed here.
My ideas:
- When I need to upgrade openstack, I can have problems with
drbd/kernel/targetcli packages that I'd like to avoid during an openstack
upgrade.
- WIth this solution I can think to remove the openstack-cinder-volume
dedicated node (in small environments)
- I thought that this can be a support in the open source world for the
people who built a san with drbd + lvm + targetcli
Anyway, I only tried to propose a new idea

@Philipp: thank you, but at the moment drbd9 has little documentation and
the solution with openstack is really lacking of guides/tutorials/examples
and performance analysis. Actually I'm using drbd 8.4.6 in production and
without a lot of tests and examples I won't switch to the next version.


Thank you
Marco


2017-02-01 12:39 GMT+01:00 Philipp Marek :

> Hi everybody,
>
> > > Hi, I'd like to know if it is possible to use openstack-cinder-volume
> with
> > > a remote LVM. This could be a new feature proposal if the idea is good.
> > > More precisely, I'm thinking a solution where openstack-cinder-volume
> runs
> > > on a dedicated node and LVM on another node (called "storage node").
> On
> > > the storage node I need to have a volume group (normally named
> > > cinder-volumes) and the targetcli package, so the iscsi_ip_address in
> > > cinder.conf should be an address associated with the storage node.
> > > Advantages of this solution are: 1) When I need to upgrade openstack I
> can
> > > leave out the storage node from the process (because it has only LVM
> and
> > > targetcli or another daemon used for iscsi targets). 2) Down on the
> > > cinder-volume node cannot creates problems to the iscsi part exposed to
> > > vms. 3) Support to the open source world in cinder: LVM is the common
> > > solution for cinder in low budget environment but performance are good
> if
> > > the storage node is powerful enough
> > >
> > > In my idea, the "interface" between openstack-cinder-volume and lvm
> can be
> > > SSH. Basically we need to create/remove/manage logical volumes on a
> remote
> > > node and the same for the iscsi targets
> > >
> > > Please, let me know if this can be a valid solution.
> > What you are proposing is almost like to create an LVM storage box. I
> > haven't seen any real benefit from the advantages you listed. For 1), the
> > same problems you can have upgrading the services within the same node
> will
> > happen if the LVM services are not in the same host. For, 2), now you
> have
> > 2 nodes to manage instead of 1, which double the changes of having
> > problems. And for 3), I really didn't get the advantage related to the
> > solution you are proposing.
> >
> > If you have real deployments cases where this could help (or if there are
> > other people interested), please list it here so people can see more
> > concrete benefits of using this solution.
>
> please let me suggest to look at the DRBD Cinder driver that's already
> upstream.
> Basically, this allows to use one or more storage boxes, and to export
> their storage (via LV and DRBD) to the Compute nodes.
>
> If you're using the DRBD protocol instead of iSCSI (and configure the DRBD
> Cinder driver to store 2 copies of the data), you'll even benefit from
> redundancy - you can maintain one of the storage nodes while the other is
> serving data, and (as soon as the data is synchronized up again) then do
> your maintenance on the other storage node.
>
>
> See here for more details:
> http://www.drbd.org/en/doc/users-guide-90/ch-openstack
>
> __
> OpenStack Development Mailing 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] [cinder] Cinder with remote LVM proposal

2017-02-01 Thread Philipp Marek
Hi everybody,

> > Hi, I'd like to know if it is possible to use openstack-cinder-volume with
> > a remote LVM. This could be a new feature proposal if the idea is good.
> > More precisely, I'm thinking a solution where openstack-cinder-volume runs
> > on a dedicated node and LVM on another node (called "storage node").  On
> > the storage node I need to have a volume group (normally named
> > cinder-volumes) and the targetcli package, so the iscsi_ip_address in
> > cinder.conf should be an address associated with the storage node.
> > Advantages of this solution are: 1) When I need to upgrade openstack I can
> > leave out the storage node from the process (because it has only LVM and
> > targetcli or another daemon used for iscsi targets). 2) Down on the
> > cinder-volume node cannot creates problems to the iscsi part exposed to
> > vms. 3) Support to the open source world in cinder: LVM is the common
> > solution for cinder in low budget environment but performance are good if
> > the storage node is powerful enough
> >
> > In my idea, the "interface" between openstack-cinder-volume and lvm can be
> > SSH. Basically we need to create/remove/manage logical volumes on a remote
> > node and the same for the iscsi targets
> >
> > Please, let me know if this can be a valid solution.
> What you are proposing is almost like to create an LVM storage box. I
> haven't seen any real benefit from the advantages you listed. For 1), the
> same problems you can have upgrading the services within the same node will
> happen if the LVM services are not in the same host. For, 2), now you have
> 2 nodes to manage instead of 1, which double the changes of having
> problems. And for 3), I really didn't get the advantage related to the
> solution you are proposing.
> 
> If you have real deployments cases where this could help (or if there are
> other people interested), please list it here so people can see more
> concrete benefits of using this solution.

please let me suggest to look at the DRBD Cinder driver that's already 
upstream.
Basically, this allows to use one or more storage boxes, and to export 
their storage (via LV and DRBD) to the Compute nodes.

If you're using the DRBD protocol instead of iSCSI (and configure the DRBD 
Cinder driver to store 2 copies of the data), you'll even benefit from 
redundancy - you can maintain one of the storage nodes while the other is 
serving data, and (as soon as the data is synchronized up again) then do 
your maintenance on the other storage node.


See here for more details:
http://www.drbd.org/en/doc/users-guide-90/ch-openstack

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


Re: [openstack-dev] [cinder] Cinder with remote LVM proposal

2017-02-01 Thread Erlon Cruz
Hi Marco,

What you are proposing is almost like to create an LVM storage box. I
haven't seen any real benefit from the advantages you listed. For 1), the
same problems you can have upgrading the services within the same node will
happen if the LVM services are not in the same host. For, 2), now you have
2 nodes to manage instead of 1, which double the changes of having
problems. And for 3), I really didn't get the advantage related to the
solution you are proposing.

If you have real deployments cases where this could help (or if there are
other people interested), please list it here so people can see more
concrete benefits of using this solution.

Erlon

On Wed, Feb 1, 2017 at 8:48 AM, Marco Marino  wrote:

> Hi, I'd like to know if it is possible to use openstack-cinder-volume with
> a remote LVM. This could be a new feature proposal if the idea is good.
> More precisely, I'm thinking a solution where openstack-cinder-volume runs
> on a dedicated node and LVM on another node (called "storage node").  On
> the storage node I need to have a volume group (normally named
> cinder-volumes) and the targetcli package, so the iscsi_ip_address in
> cinder.conf should be an address associated with the storage node.
> Advantages of this solution are: 1) When I need to upgrade openstack I can
> leave out the storage node from the process (because it has only LVM and
> targetcli or another daemon used for iscsi targets). 2) Down on the
> cinder-volume node cannot creates problems to the iscsi part exposed to
> vms. 3) Support to the open source world in cinder: LVM is the common
> solution for cinder in low budget environment but performance are good if
> the storage node is powerful enough
>
> In my idea, the "interface" between openstack-cinder-volume and lvm can be
> SSH. Basically we need to create/remove/manage logical volumes on a remote
> node and the same for the iscsi targets
>
> Please, let me know if this can be a valid solution.
>
> Thank you
> Marco
>
> __
> OpenStack Development Mailing 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] [watcher] meeting time and location change

2017-02-01 Thread Tony Breeds
On Wed, Feb 01, 2017 at 09:20:21PM +1100, Tony Breeds wrote:
> On Wed, Feb 01, 2017 at 10:49:28AM +0100, Antoine Cabot wrote:
> > Thx Tony, I did this last week ;-)
> > https://review.openstack.org/#/c/425107/
> > Antoine
> 
> Thanks!
> 
> Hmm okay that's strange as the view I get seems t have stale data.

Just talking to myself but the current eavesdrop page shows:
Page generated on 2017-01-12 15:06:44.58 UTC

So yeah it looks like the publish job failed.

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


[openstack-dev] [craton] Proposing Harry Harrington for Craton core

2017-02-01 Thread Sulochan Acharya
Hi everyone,

I would like to propose  Harry Harrington @git-harry to Craton core team.
He has been doing a great job with both reviewing and proposing meaningful
changes to craton project. I am confident Harry will be great help as
craton core member.

https://github.com/openstack/craton/commits/master?author=git-harry


I am also proposing to remove Sean Roberts from core team at this time.
Sean has been great help to get Craton started but has been busy with other
duties lately. We would be delighted to add Sean back in the future when
his reviewing picks up again.


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


Re: [openstack-dev] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-02-01 Thread Carlos Camacho Gonzalez
+1!

On Wed, Feb 1, 2017 at 9:57 AM, Julie Pichon  wrote:

> On 31 January 2017 at 16:02, Ben Nemec  wrote:
> > In the spirit of all the core team changes, here are a couple more I'd
> like
> > to propose.
> >
> > Dmitry has been very helpful reviewing in instack-undercloud for a long
> time
> > so this is way overdue.  I'm also going to propose that he be able to +2
> > anything Ironic-related in TripleO since that is his primary area of
> > expertise.
> >
> > Alex has ramped up quickly on TripleO and has also been helping out with
> > instack-undercloud quite a bit.  He's already core for the puppet
> modules,
> > and a lot of the changes to instack-undercloud these days are primarily
> in
> > the puppet manifest so it's not a huge stretch to add him.
> >
> > As usual, TripleO cores please vote and/or provide comments.  Thanks.
>
> +1!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [cinder] Cinder with remote LVM proposal

2017-02-01 Thread Marco Marino
Hi, I'd like to know if it is possible to use openstack-cinder-volume with
a remote LVM. This could be a new feature proposal if the idea is good.
More precisely, I'm thinking a solution where openstack-cinder-volume runs
on a dedicated node and LVM on another node (called "storage node").  On
the storage node I need to have a volume group (normally named
cinder-volumes) and the targetcli package, so the iscsi_ip_address in
cinder.conf should be an address associated with the storage node.
Advantages of this solution are: 1) When I need to upgrade openstack I can
leave out the storage node from the process (because it has only LVM and
targetcli or another daemon used for iscsi targets). 2) Down on the
cinder-volume node cannot creates problems to the iscsi part exposed to
vms. 3) Support to the open source world in cinder: LVM is the common
solution for cinder in low budget environment but performance are good if
the storage node is powerful enough

In my idea, the "interface" between openstack-cinder-volume and lvm can be
SSH. Basically we need to create/remove/manage logical volumes on a remote
node and the same for the iscsi targets

Please, let me know if this can be a valid solution.

Thank you
Marco
__
OpenStack Development Mailing 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] [watcher] meeting time and location change

2017-02-01 Thread Tony Breeds
On Wed, Feb 01, 2017 at 10:49:28AM +0100, Antoine Cabot wrote:
> Thx Tony, I did this last week ;-)
> https://review.openstack.org/#/c/425107/
> Antoine

Thanks!

Hmm okay that's strange as the view I get seems t have stale data.

I'll check the publish jobs

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] [requirements] changing the order of values in upper-constraints.txt

2017-02-01 Thread Tony Breeds
On Wed, Jan 18, 2017 at 04:34:56PM -0500, Doug Hellmann wrote:
> When I tried to merge the upper-constraints updates for the library
> releases we did today, I ran into quite a lot of merge conflicts
> with the Oslo libraries. I'm exploring options for reducing the
> likelihood that those sorts of conflicts will occur with a few
> patches that change how we generate the constraints list.

Dirk's been doing a great job of dealing with that and there are scripts to
take the ones generated from the bot and make single series from them n deep.
That's not very sustainable though.



> The final option uses a SHA1 hash of the name as the sort key. It
> wouldn't be easy for a human to update the file by hand, but we
> could make a tool that does. I don't know how often that case comes
> up, so I don't know how important it is. See
> https://review.openstack.org/422245 and https://review.openstack.org/422246
> for the sample output.

Thanks Doug.  I like this option.

We don't need to add a tool as the docs describe how to do this already, which
basically boils down to run the tool you're patching.

If that doesn't happen (which is common) the next daily update will just move
it to the new right place.

I think we should do this early after we branch requirements

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


[openstack-dev] [keystone] Do we really need two listening ports ?

2017-02-01 Thread Attila Fazekas
Hi all,

Typically we have two keystone service listening on two separate ports
35357 and 5000.

Historically one of the port had limited functionality, but today I do not
see why we want
to have two separate service/port from the same code base for similar
purposes.

Effective we use double amount of memory than it is really required,
because both port is served by completely different worker instances,
typically from the same physical server.

I wonder, would it be difficult to use only a single port or at least the
same pool of workers for all keystone(identity, auth..) purposes?

Best Regards,
Attila
__
OpenStack Development Mailing 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] [watcher] meeting time and location change

2017-02-01 Thread Antoine Cabot
Thx Tony, I did this last week ;-)
https://review.openstack.org/#/c/425107/
Antoine

On Wed, Feb 1, 2017 at 10:25 AM, Tony Breeds  wrote:
> On Wed, Feb 01, 2017 at 10:06:37AM +0100, Antoine Cabot wrote:
>> Hi Watcher team,
>>
>> I changed time & location of our weekly meeting on odd weeks. Today,
>> it will be at 13:00 UTC on #openstack-meeting-alt.
>
> Care to submit a review to openstack-infra/irc-meetings so that
> http://eavesdrop.openstack.org/#Watcher_Team_Meeting will match the new
> schedule?
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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


Re: [openstack-dev] [watcher] meeting time and location change

2017-02-01 Thread Tony Breeds
On Wed, Feb 01, 2017 at 10:06:37AM +0100, Antoine Cabot wrote:
> Hi Watcher team,
> 
> I changed time & location of our weekly meeting on odd weeks. Today,
> it will be at 13:00 UTC on #openstack-meeting-alt.

Care to submit a review to openstack-infra/irc-meetings so that
http://eavesdrop.openstack.org/#Watcher_Team_Meeting will match the new
schedule?

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


[openstack-dev] [watcher] meeting time and location change

2017-02-01 Thread Antoine Cabot
Hi Watcher team,

I changed time & location of our weekly meeting on odd weeks. Today,
it will be at 13:00 UTC on #openstack-meeting-alt.

Thanks,

Antoine

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


Re: [openstack-dev] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-02-01 Thread Julie Pichon
On 31 January 2017 at 16:02, Ben Nemec  wrote:
> In the spirit of all the core team changes, here are a couple more I'd like
> to propose.
>
> Dmitry has been very helpful reviewing in instack-undercloud for a long time
> so this is way overdue.  I'm also going to propose that he be able to +2
> anything Ironic-related in TripleO since that is his primary area of
> expertise.
>
> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet modules,
> and a lot of the changes to instack-undercloud these days are primarily in
> the puppet manifest so it's not a huge stretch to add him.
>
> As usual, TripleO cores please vote and/or provide comments.  Thanks.

+1!

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


[openstack-dev] [storlets]

2017-02-01 Thread Eran Rom

Hi all,
I will create the stable/ocata branch tomorrow my end of day.
Would be great if we can land the python functional tests.

Thanks!
Eran


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


Re: [openstack-dev] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-02-01 Thread Michele Baldessari
+1

On Tue, Jan 31, 2017 at 10:02:06AM -0600, Ben Nemec wrote:
> In the spirit of all the core team changes, here are a couple more I'd like
> to propose.
> 
> Dmitry has been very helpful reviewing in instack-undercloud for a long time
> so this is way overdue.  I'm also going to propose that he be able to +2
> anything Ironic-related in TripleO since that is his primary area of
> expertise.
> 
> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet modules,
> and a lot of the changes to instack-undercloud these days are primarily in
> the puppet manifest so it's not a huge stretch to add him.
> 
> As usual, TripleO cores please vote and/or provide comments.  Thanks.
> 
> -Ben
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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