Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Import path looks OK
https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23


Are u suggesting something else?

On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton  wrote:

> That location was recently changed in the Neutron side.[1] It sounds like
> sfc has to be updated.
>
> 1. https://github.com/openstack/neutron/commit/
> 4ec456d31501f09c68b5c23c488878da32dce75e
>
> On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar  com> wrote:
>
>> Hi Igor,
>>
>>This is weird. I just did a fresh clone and executed *"tox" *command.
>> I am getting same error. Am I missing anything here ? There is no private
>> change here.  Below is the link for entire log.
>>
>>  http://paste.openstack.org/show/601870/
>>
>> On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
>> igor.duarte.card...@intel.com> wrote:
>>
>>> Hi Vikash,
>>>
>>> Please stick to pastebin for complete logs.
>>>
>>>
>>>
>>> Check your migration files:
>>>
>>>
>>>
>>> FAILED: Contract HEAD file does not match migration timeline head,
>>> expected: 48072cb59133
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Igor.
>>>
>>>
>>>
>>> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
>>> *Sent:* Tuesday, March 7, 2017 5:03 PM
>>> *To:* openstack-dev 
>>> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due
>>> to "import error: vlanmanager"
>>>
>>>
>>>
>>> Complete log:
>>>
>>>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
>>> py35 installdeps: -r/home/vikash/guess_vk/python
>>> -dev/networking-sfc/requirements.txt, -r/home/vikash/guess_vk/python
>>> -dev/networking-sfc/test-requirements.txt
>>> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
>>> py35 installed: /home/vikash/guess_vk/python-d
>>> ev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
>>> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
>>> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==
>>> 0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulso
>>> up4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==
>>> 0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.
>>> 2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,
>>> dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==
>>> 0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,
>>> greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,
>>> imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.
>>> 15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.
>>> 0,keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.
>>> 0,logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,
>>> MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,
>>> mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
>>> git+https://github.com/openstack/networking-sfc.git@c51052e3
>>> 748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e git+
>>> https://github.com/openstack/neutron.git@41be555eddb0f99
>>> 47fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,ope
>>> nstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.
>>> 0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,os
>>> lo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.
>>> 12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo
>>> .messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.
>>> 19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.
>>> serialization==2.17.0,oslo.service==1.19.0,oslo.utils==3.
>>> 22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.10.0,
>>> oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.
>>> 2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,
>>> pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,
>>> prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.
>>> 3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==
>>> 2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,
>>> pyparsing==2.2.0,python-cinderclient==1.11.0,python-
>>> dateutil==2.6.0,python-designateclient==2.6.0,python-editor=
>>> =1.0.3,python-glanceclient==2.6.0,python-keystoneclient==3.
>>> 10.0,python-mimeparse==1.6.0,python-neutronclient==6.1.0,
>>> python-novaclient==7.1.0,python-openstackclient==3.8.1,pytho
>>> n-subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,
>>> repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,requ
>>> estsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.1,Routes=
>>> =2.4.1,ryu==4.12,simplejson==3.10.0,six==1.10.0,snowballste
>>> mmer==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.17,sqlalchemy-
>>> migrate==0.11.0,sqlparse==0.2.3,statsd==3.2.1,stevedore==1.
>>> 21.0,tempest-lib==1.0.0,Tempita==0.5.2,tenacity==3.7.
>>> 1,testrepository==0.0.20,testresources==2.0.1,testscenarios=
>>> =0.5.0,testtools==2.2.0,tinyrpc==0.5,traceback2==1.4.0,
>>> unittest2==1.1.0,waitress==1.0.2,warlock==1.2.0,WebOb==1.6.
>>> 

[openstack-dev] [magnum] [ocata] after installation, magnum is not found

[Yu Wei]

Hi guys,

After installing openstack ocata magnum, magnum is not found.

However, magnum-api and magnum-conduct are running well.

How could I fix such problem? Is this bug in ocata?


[root@controller bin]# systemctl status openstack-magnum-api.service   
openstack-magnum-conductor.service
● openstack-magnum-api.service - OpenStack Magnum API Service
   Loaded: loaded (/usr/lib/systemd/system/openstack-magnum-api.service; 
enabled; vendor preset: disabled)
   Active: active (running) since Thu 2017-03-09 11:51:33 CST; 13min ago
 Main PID: 16195 (magnum-api)
   CGroup: /system.slice/openstack-magnum-api.service
   └─16195 /usr/bin/python2 /usr/bin/magnum-api

Mar 09 11:51:33 controller systemd[1]: Started OpenStack Magnum API Service.
Mar 09 11:51:33 controller systemd[1]: Starting OpenStack Magnum API Service...
Mar 09 11:51:34 controller magnum-api[16195]: 2017-03-09 11:51:34.646 16195 
WARNING oslo_reports.guru_meditation_report [-] Guru meditation now registers 
SIGUSR1 and SIGUSR2 by default for...rate reports.
Mar 09 11:51:34 controller magnum-api[16195]: 2017-03-09 11:51:34.647 16195 
INFO magnum.api.app [-] Full WSGI config used: /etc/magnum/api-paste.ini
Mar 09 11:51:34 controller magnum-api[16195]: 2017-03-09 11:51:34.751 16195 
WARNING keystonemiddleware.auth_token [-] AuthToken middleware is set with 
keystone_authtoken.service_token_role...this to True.
Mar 09 11:51:34 controller magnum-api[16195]: 2017-03-09 11:51:34.762 16195 
INFO magnum.cmd.api [-] Starting server in PID 16195
Mar 09 11:51:34 controller magnum-api[16195]: 2017-03-09 11:51:34.767 16195 
INFO magnum.cmd.api [-] Serving on http://192.168.111.20:9511
Mar 09 11:51:34 controller magnum-api[16195]: 2017-03-09 11:51:34.767 16195 
INFO magnum.cmd.api [-] Server will handle each request in a new process up to 
2 concurrent processes
Mar 09 11:51:34 controller magnum-api[16195]: 2017-03-09 11:51:34.768 16195 
INFO werkzeug [-]  * Running on http://192.168.111.20:9511/

● openstack-magnum-conductor.service - Openstack Magnum Conductor Service
   Loaded: loaded (/usr/lib/systemd/system/openstack-magnum-conductor.service; 
enabled; vendor preset: disabled)
   Active: active (running) since Thu 2017-03-09 11:51:33 CST; 13min ago
 Main PID: 16200 (magnum-conducto)
   CGroup: /system.slice/openstack-magnum-conductor.service
   └─16200 /usr/bin/python2 /usr/bin/magnum-conductor

Mar 09 11:51:33 controller systemd[1]: Started Openstack Magnum Conductor 
Service.
Mar 09 11:51:33 controller systemd[1]: Starting Openstack Magnum Conductor 
Service...
Mar 09 11:51:34 controller magnum-conductor[16200]: 2017-03-09 11:51:34.640 
16200 WARNING oslo_reports.guru_meditation_report [-] Guru meditation now 
registers SIGUSR1 and SIGUSR2 by defau...rate reports.
Mar 09 11:51:34 controller magnum-conductor[16200]: 2017-03-09 11:51:34.640 
16200 INFO magnum.cmd.conductor [-] Starting server in PID 16200
Mar 09 11:51:34 controller magnum-conductor[16200]: 
/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py:200: 
FutureWarning: The access_policy argument is changing its default value to 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] question about oslo_utils and oslo_versonedobjects

[zengchen]

I'm contributing on Karbor (https://wiki.openstack.org/wiki/Karbor). 
Recently, I find a bug in the following codes.


def resume_operation(self, operation_id, **kwargs):
end_time = kwargs.get('end_time_for_run')
now = datetime.utcnow()
if not isinstance(end_time, datetime) or now > end_time:
return


'end_time_for_run' comes from DB with following definition.
class ScheduledOperationState():
fields = {
'end_time_for_run': fields.DateTimeField(nullable=True),
}
when 'now' compares to 'end_time', it will raise an exception as I described 
before.


I mean now that timeutils.untcnow and datetime.utcnow will return a time without
a timezone info attached by default, why not  change DateTimeField to keep it
coincidence with them. I should be a good optimize in the point of view of easy 
of use.
Certainly, I can change the codes as you described.


Really appreciate your reply.


Best Wishes!
zeng chen



At 2017-03-09 10:43:23, "Jay Pipes"  wrote:
>On 03/08/2017 09:07 PM, zengchen wrote:
>> Hi, jay
>> Thanks for your reply. Do you means it is no need to do that optimization?
>> In my opinion, It is better if do some change. Thanks again.
>
>I'm not quite following you. I don't believe there's any need to change 
>anything nor any need to optimize anything.
>
>Can you elaborate on what issue you are facing?
>
>Best,
>-jay
>
>> At 2017-03-08 00:57:51, "Jay Pipes"  wrote:
>>>On 03/07/2017 01:34 AM, zengchen wrote:
 Hi, guys:
  I find a non-coincidence definition in Oslo,

  oslo_utils.timeutils.utcnow is defined like this:
  def utcnow(with_timezone=False):

 oslo_versonedobjects.fields.DateTimeField is defined like this
 classDateTimeField(AutoTypedField): def__init__(self, tzinfo_aware=True,
 **kwargs):

 a = utcnow()
 class ABC(VersionedObject):
 fields = {
 created_at = fields.DateTimeField()
 }
 b = ABC(), and fill it by db record.

 If I compare a and b.created_at,  it will raise an exception like this:
'TypeError: can't compare offset-naive and offset-aware datetimes'
 because a's value is like this:
 datetime.datetime(2017, 3, 7, 2, 34, 50, 859002)
 b.created_at 's value is like this:
  datetime.datetime(2017, 3, 7, 2, 35, 27,
 400786,*tzinfo=*)

Can these two kinds of time's definition be coincident? For example:
def utcnow(with_timezone=*False*):

class DateTimeField(AutoTypedField):
 def __init__(self, tzinfo_aware=*False*, **kwargs):
>>>
>>>Hi Zeng,
>>>
>>>Yes, you will want to use utcnow(with_timezone=True) and the default
>>>ovo.fields.DateTimeField definition *or* use utcnow() and a
>>>ovo.fields.DateTimeField(tzinfo_aware=False) definition.
>>>
>>>Best,
>>>-jay
>>>
>>>__
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>__
>OpenStack Development Mailing 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] ImportError: No module named neutron_lib

[Sam]

Sorry, it's oslo_db, I'm wrong

2017-03-09 14:22 GMT+08:00 Sam :

> I found this:
>
> from oslo_config import ...
> from oslo_db import ...
> from neutron_lib import ...
>
> actually these libraries is oslo.config, oslo.db, neutron.lib
>
> Why not write like this: from oslo.config import ... ?
>
> And for local package, its: from neutron.api import ...
>
> WHY ?
>
> 2017-03-08 5:28 GMT+08:00 Tony Breeds :
>
>> On Tue, Mar 07, 2017 at 04:04:55PM +0800, Sam wrote:
>> > Is this?
>> >
>> > https://pypi.python.org/pypi/neutron-lib
>>
>> Make sure you're installing with upper-constratints otehrwise you'll get
>> components that rely on features for newer releases
>>
>> Assuming you're installing with pip something like[1]
>>
>> wget 'http://tarballs.openstack.org/neutron/neutron-8.4.0-py2.py3
>> -none-any.whl'
>> wget 'http://git.openstack.org/cgit/openstack/requirements/plain/
>> upper-constraints.txt?h=stable/mitaka'
>>
>> pip install -c upper-constratints.txt ./neutron-8.4.0-py2.py3-none-a
>> ny.whl
>>
>> Should get you a stable/mitaka neutron with appropriate versions of all
>> libraries in use.
>>
>> Yours Tony.
>>
>> [1] You may be able to pass the URLs directly to pip but I haven't tested
>> that for wheels
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] ImportError: No module named neutron_lib

[Sam]

I found this:

from oslo_config import ...
from oslo_db import ...
from neutron_lib import ...

actually these libraries is oslo.config, oslo.db, neutron.lib

Why not write like this: from oslo.config import ... ?

And for local package, its: from neutron.api import ...

WHY ?

2017-03-08 5:28 GMT+08:00 Tony Breeds :

> On Tue, Mar 07, 2017 at 04:04:55PM +0800, Sam wrote:
> > Is this?
> >
> > https://pypi.python.org/pypi/neutron-lib
>
> Make sure you're installing with upper-constratints otehrwise you'll get
> components that rely on features for newer releases
>
> Assuming you're installing with pip something like[1]
>
> wget 'http://tarballs.openstack.org/neutron/neutron-8.4.0-py2.
> py3-none-any.whl'
> wget 'http://git.openstack.org/cgit/openstack/requirements/
> plain/upper-constraints.txt?h=stable/mitaka'
>
> pip install -c upper-constratints.txt ./neutron-8.4.0-py2.py3-none-any.whl
>
> Should get you a stable/mitaka neutron with appropriate versions of all
> libraries in use.
>
> Yours Tony.
>
> [1] You may be able to pass the URLs directly to pip but I haven't tested
> that for wheels
>
> __
> OpenStack Development Mailing 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] pycrypto is dead, long live pycryptodome... or cryptography...

[Matthew Thode]

On 03/08/2017 05:38 PM, Amrith Kumar wrote:
> Sounds like a good candidate for a cross-project release goal.
> 
> A non-controversial situation, the work is a no-op for most, a specific
> deliverable for a few, and a mechanism to close the loop and make sure it
> gets done in a specific timeframe?
> 
> Thanks for surfacing it Matthew.
> 
> -amrith

Heh, thanks, I suspect a few things are fairly cross project for
requirements.  Moving to new webob / eventlet / sqlalchemy for instance.

Is there a specific process we go through to do these?

-- 
Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [oslo] question about oslo_utils and oslo_versonedobjects

[Jay Pipes]

On 03/08/2017 09:07 PM, zengchen wrote:

Hi, jay
Thanks for your reply. Do you means it is no need to do that optimization?
In my opinion, It is better if do some change. Thanks again.


I'm not quite following you. I don't believe there's any need to change 
anything nor any need to optimize anything.


Can you elaborate on what issue you are facing?

Best,
-jay


At 2017-03-08 00:57:51, "Jay Pipes"  wrote:

On 03/07/2017 01:34 AM, zengchen wrote:

Hi, guys:
 I find a non-coincidence definition in Oslo,

 oslo_utils.timeutils.utcnow is defined like this:
 def utcnow(with_timezone=False):

oslo_versonedobjects.fields.DateTimeField is defined like this
classDateTimeField(AutoTypedField): def__init__(self, tzinfo_aware=True,
**kwargs):

a = utcnow()
class ABC(VersionedObject):
fields = {
created_at = fields.DateTimeField()
}
b = ABC(), and fill it by db record.

If I compare a and b.created_at,  it will raise an exception like this:
   'TypeError: can't compare offset-naive and offset-aware datetimes'
because a's value is like this:
datetime.datetime(2017, 3, 7, 2, 34, 50, 859002)
b.created_at 's value is like this:
 datetime.datetime(2017, 3, 7, 2, 35, 27,
400786,*tzinfo=*)

   Can these two kinds of time's definition be coincident? For example:
   def utcnow(with_timezone=*False*):

   class DateTimeField(AutoTypedField):
def __init__(self, tzinfo_aware=*False*, **kwargs):


Hi Zeng,

Yes, you will want to use utcnow(with_timezone=True) and the default
ovo.fields.DateTimeField definition *or* use utcnow() and a
ovo.fields.DateTimeField(tzinfo_aware=False) definition.

Best,
-jay

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




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



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

Re: [openstack-dev] [oslo] question about oslo_utils and oslo_versonedobjects

[zengchen]

Hi, jayThanks for your reply. Do you means it is no need to do that 
optimization?In my opinion, It is better if do some change. Thanks again.

Best Wishes
zeng chen


At 2017-03-08 00:57:51, "Jay Pipes"  wrote:
>On 03/07/2017 01:34 AM, zengchen wrote:
>> Hi, guys:
>>  I find a non-coincidence definition in Oslo,
>>
>>  oslo_utils.timeutils.utcnow is defined like this:
>>  def utcnow(with_timezone=False):
>>
>> oslo_versonedobjects.fields.DateTimeField is defined like this
>> classDateTimeField(AutoTypedField): def__init__(self, tzinfo_aware=True,
>> **kwargs):
>>
>> a = utcnow()
>> class ABC(VersionedObject):
>> fields = {
>> created_at = fields.DateTimeField()
>> }
>> b = ABC(), and fill it by db record.
>>
>> If I compare a and b.created_at,  it will raise an exception like this:
>>'TypeError: can't compare offset-naive and offset-aware datetimes'
>> because a's value is like this:
>> datetime.datetime(2017, 3, 7, 2, 34, 50, 859002)
>> b.created_at 's value is like this:
>>  datetime.datetime(2017, 3, 7, 2, 35, 27,
>> 400786,*tzinfo=*)
>>
>>Can these two kinds of time's definition be coincident? For example:
>>def utcnow(with_timezone=*False*):
>>
>>class DateTimeField(AutoTypedField):
>> def __init__(self, tzinfo_aware=*False*, **kwargs):
>
>Hi Zeng,
>
>Yes, you will want to use utcnow(with_timezone=True) and the default 
>ovo.fields.DateTimeField definition *or* use utcnow() and a 
>ovo.fields.DateTimeField(tzinfo_aware=False) definition.
>
>Best,
>-jay
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] Meeting Thursday Mar 9th at 9:00 UTC

[Ghanshyam Mann]

Thanks Luz,

We will discuss the same in today meeting. Saw your report on etherpad too.

-gmann

On Thu, Mar 9, 2017 at 7:22 AM, Cazares, Luz  wrote:

> Hey gmann
>
>
>
> I did bug triage last weeks (27th Feb – 3rd March).
>
>
>
> So far 7 new bugs arrived:
>
> 3 confirmed (2 low, 1 medium)
>
> #1669455 tempest run --regex '\[.*\bsmoke\b.*\]' 
> --blacklist-file=/home/jenkins/tempest/skip.txt
> not able to run smoke tests
> 
>
> #1668690 Tempest test_server_actions missing evacuate server test (and
> client) 
>
> #1668407 os-assisted-volume-snapshots client is not available
> 
>
> 1 in-progress
>
> #1667354 Volume v2 capabilities & scheduler-stats service clients makes
> v1 APIs call 
>
> 2 incomplete
>
> #1667443 API endpoints become
> inaccessible after tempest run
> 
>
> #1671256 test_get_volume_absolute_limits
> fails with no admin credentials
> 
>
> 1 reviewing – not sure if it is a valid bug or working as
> designed – Related to resource_cleanup vs teardown (clean after each test
> case).
>
> #1670693 Tests in
> tempest.api.network.test_routers.RoutersTest don't clean up network
> resources 
>
>
>
> Please let me know if comments or questions
>
>
>
>
>
> *From: *Ghanshyam Mann 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Wednesday, March 8, 2017 at 1:09 AM
> *To: *"openstack-dev@lists.openstack.org"  openstack.org>
> *Subject: *[openstack-dev] [QA] Meeting Thursday Mar 9th at 9:00 UTC
>
>
>
> Hello everyone,
>
> Please reminder that the weekly OpenStack QA team IRC meeting will be
> Thursday, Mar 9th at 9:00 UTC in the #openstack-meeting channel.
>
> The agenda for the meeting can be found here:
>
> https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#
> Agenda_for_March_9th_2017_.280900_UTC.29
>
> Anyone is welcome to add an item to the agenda.
>
> -gmann
>
> __
> OpenStack Development Mailing 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] [Murano] Newton version of Murano fails trying to auto-import a Liberty version of io.murano.applications.zip

[Stan Lagun]

It is probably that the package io.murano.applications is not present in
the app catalog. io.murano and io.murano.applications are the packages that
are bundled with Murano and usually should be preinstalled. You can obtain
them here:
https://github.com/openstack/murano/tree/stable/newton/meta

Regards,
Stan

On March 7, 2017 at 11:24:48 AM, Waines, Greg (greg.wai...@windriver.com)
wrote:

I am running a NEWTON version of Murano.



When I try to import a package that is using io.murano.applications classes
(e.g. SingleServerApplication),

it seems to try to auto-import the liberty version of
io.murano.applications.zip … and fails.



Is this a bug ?   Is it suppose to be using NEWTON version of
io.murano.applciations.zip ?  Actually can’t find NEWTON version, is the
URL wrong ?



[wrsroot@controller-0 newDemo(keystone_tenant1)]$ murano package-import
com.wrs.titanium.murano.examples.afwDemo

Error Got non-ok status(404) while connecting to
http://apps.openstack.org/api/v1/murano_repo/liberty/apps/io.murano.applications.zip
occurred while parsing package io.murano.applications, required by
com.wrs.titanium.murano.examples.afwDemo package

Inspecting required images

Importing package com.wrs.titanium.murano.examples.afwDemo

+--+-+--+-++---+-+-+

| ID   | Name| FQN
| Author  | Active | Is
Public | Type| Version |

+--+-+--+-++---+-+-+

| e7a08d26300e4812b9a5d0f91b2ad430 | APP FW Titanium Murano Demo App |
com.wrs.titanium.murano.examples.afwDemo | Greg Waines, Wind River | True   |
  | Application | |

+--+-+--+-++---+-+-+

[wrsroot@controller-0 newDemo(keystone_tenant1)]$



let me know,

Greg.






__
OpenStack Development Mailing 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][Heat] Selectively disabling deployment resources

[Zane Bitter]

On 08/03/17 10:05, James Slagle wrote:

On Tue, Mar 7, 2017 at 7:24 PM, Zane Bitter  wrote:

On 07/03/17 14:34, James Slagle wrote:


I've been working on this spec for TripleO:
https://review.openstack.org/#/c/431745/

which allows users to selectively disable Heat deployment resources
for a given server (or server in the case of a *DeloymentGroup
resource).



I'm not completely clear on what this means. You can selectively disable
resources with conditionals. But I think you mean that you want to
selectively disable *changes* to resources?


Yes, that's right. The reason I can't use conditionals is that I still
want the SoftwareDeploymentGroup resources to be updated, but I may
want to selectively exclude servers from the group that is passed in
via the servers property. E.g., instead of updating the deployment
metadata for *all* computes, I may want to exclude a single compute
that is temporarily unreachable, without that failing the whole
stack-update.


Have you seen the filter function?

http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/hot/functions.py#n1279


I started by taking an approach that would be specific to TripleO.
Basically mapping all the deployment resources to a nested stack
containing the logic to selectively disable servers from the
deployment (using yaql) based on a provided parameter value. Here's
the main patch: https://review.openstack.org/#/c/442681/

After considering that complexity, particularly the yaql expression,
I'm wondering if it would be better to add this support natively to
Heat.

I was looking at the restricted_actions key in the resource_registry
and was thinking this might be a reasonable place to add such support.
It would require some changes to how restricted_actions work.

One change would be a method for specifying that restricted_actions
should not fail the stack operation if an action would have otherwise
been triggered. Currently the behavior is to raise an exception and
mark the stack failed if an action needs to be taken but has been
marked restricted. That would need to be tweaked to allow specifying
that that we don't want the stack to fail. One thought would be to
change the allowed values of restricted_actions to:

replace_fail
replace_ignore
update_fail
update_ignore
replace
update

where replace and update were synonyms for replace_fail/update_fail to
maintain backwards compatibility.



Anything that involves the resource definition in the template changing but
Heat not modifying the resource is problematic, because that messes with
Heat's internal bookkeeping.


I don't think this case would violate that principle. The template +
environment files would match what Heat has done. After an update, the
2 would be in sync as to what servers the updated Deployment resource
was triggered.


I'm afraid I can't agree; it isn't that straightforward. Also, if you 
want to implement a generic mechanism that applies to every kind of 
resource (like restricted_actions do) then it isn't enough for it to 
work in one particular use case.



Another change would be to add logic to the Deployment resources
themselves to consider if any restricted_actions have been set on an
Server resources before triggering an updated deployment for a given
server.



Why not just a property, "no_new_deployments_please: true"?


That would actually work and be pretty straightforward I think. We
could have a map parameter with server names and the property that the
user could use to set the value.


The tricky part, since this would presumably be implemented in the 
software deployment API itself, would be how to keep the Heat 
SoftwareDeployment resource in sync with what's actually happening, so 
that the Right Thing happens again when you start doing new deployments.


cheers,
Zane.


The reason why I was initially not considering this route was because
it doesn't allow the user to disable only some deployments for a given
server. It's all or nothing. However, it's much simpler than a totally
flexible option, and it addresses 2 of the largest use cases of this
feature. I'll look into this route a bit more.




__
OpenStack Development Mailing 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] pycrypto is dead, long live pycryptodome... or cryptography...

[Amrith Kumar]

Sounds like a good candidate for a cross-project release goal.

A non-controversial situation, the work is a no-op for most, a specific
deliverable for a few, and a mechanism to close the loop and make sure it
gets done in a specific timeframe?

Thanks for surfacing it Matthew.

-amrith

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: Wednesday, March 8, 2017 2:30 PM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [requirements] pycrypto is dead, long live
pycryptodome... or cryptography...

Ack thanks Matthew!

On Wed, Mar 8, 2017 at 2:24 PM, Matthew Thode 
wrote:
> I'm aware, iirc it was brought up when pysaml2 had to be fixed due to 
> a CVE.  This thread is more looking for a long term fix.
>
> On 03/08/2017 01:11 PM, Davanum Srinivas wrote:
>> Matthew,
>>
>> Please see the last time i took inventory:
>> https://review.openstack.org/#/q/pycryptodome+owner:dims-v
>>
>> Thanks,
>> Dims
>>
>> On Wed, Mar 8, 2017 at 2:03 PM, Matthew Thode 
wrote:
>>> So, pycrypto upstream is dead and has been for a while, we should 
>>> look at moving off of it for both bugfix and security reasons.
>>>
>>> Currently it's used by the following.
>>>
>>> barbican, cinder, trove, glance, heat, keystoneauth, 
>>> keystonemiddleware, kolla, openstack-ansible, and a couple of other
smaller places.
>>>
>>> Development of it was forked into pycryptodome, which is supposed to 
>>> be a drop in replacement.  The problem is that due to 
>>> co-installability requirements we can't have half of packages out 
>>> there using pycrypto and the other half using pycryptodome.  We'd 
>>> need to hard switch everyone as both packages install into the same
namespace.
>>>
>>> Another alternative would be to use something like cryptography 
>>> instead, though it is not a drop in replacement, the migration would 
>>> be able to be done piecemeal.
>>>
>>> I'd be interested in hearing about migration plans, especially from 
>>> the affected projects.
>>>
>>> --
>>> Matthew Thode (prometheanfire)
>>>
>>>
>>> 
>>> __ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
>  OpenStack Development Mailing 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

[openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

[Evan Bollig PhD]

I am on Ocata with Shibboleth auth enabled. I noticed that Federated
users with the admin role no longer have authorization to use the
Admin** panels in Horizon related to Nova, Cinder and Neutron. All
regular Identity and Project tabs function, and there are no problems
with authorization for local admin users.

-
These Admin tabs work: Hypervisors, Host Aggregates, Flavors, Images,
Defaults, Metadata, System Information

These result in logout: Instances, Volumes, Networks, Routers, Floating IPs

This is not present: Overview
-

The policies are vanilla from the CentOS/RDO openstack-dashboard RPMs:
openstack-dashboard-11.0.0-1.el7.noarch
python-django-horizon-11.0.0-1.el7.noarch
python2-keystonemiddleware-4.14.0-1.el7.noarch
python2-keystoneclient-3.10.0-1.el7.noarch
openstack-keystone-11.0.0-1.el7.noarch
python2-keystoneauth1-2.18.0-1.el7.noarch
python-keystone-11.0.0-1.el7.noarch

The errors I see in logs are similar to:

==> /var/log/horizon/horizon.log <==
2017-03-07 18:24:54,961 13745 ERROR horizon.exceptions Unauthorized:
Traceback (most recent call last):
  File 
"/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/floating_ips/views.py",
line 53, in get_tenant_list
tenants, has_more = api.keystone.tenant_list(request)
  File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
line 351, in tenant_list
manager = VERSIONS.get_project_manager(request, admin=admin)
  File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
line 61, in get_project_manager
manager = keystoneclient(*args, **kwargs).projects
  File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
line 170, in keystoneclient
raise exceptions.NotAuthorized
NotAuthorized

Cheers,
-E
--
Evan F. Bollig, PhD
Scientific Computing Consultant, Application Developer | Scientific
Computing Solutions (SCS)
Minnesota Supercomputing Institute | msi.umn.edu
University of Minnesota | umn.edu
boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556

__
OpenStack Development Mailing 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] pycrypto is dead, long live pycryptodome... or cryptography...

[Thomas Herve]

On Wed, Mar 8, 2017 at 8:03 PM, Matthew Thode  wrote:
> So, pycrypto upstream is dead and has been for a while, we should look
> at moving off of it for both bugfix and security reasons.
>
> Currently it's used by the following.
>
> barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,
> kolla, openstack-ansible, and a couple of other smaller places.

Heat keeps it mostly for (old) backward compatibility. We can possibly
remove it now, especially if it helps global requirements.

-- 
Thomas

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

Re: [openstack-dev] [requirements] pycrypto is dead, long live pycryptodome... or cryptography...

[Brant Knudson]

On Wed, Mar 8, 2017 at 1:03 PM, Matthew Thode 
wrote:

> So, pycrypto upstream is dead and has been for a while, we should look
> at moving off of it for both bugfix and security reasons.
>
> Currently it's used by the following.
>
> barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,
> kolla, openstack-ansible, and a couple of other smaller places.
>
>
keystoneauth didn't actually use pycrypto even though it was in
test-requirements.txt, so I posted a change to remove it:
https://review.openstack.org/#/c/443318/

 - Brant


> Development of it was forked into pycryptodome, which is supposed to be
> a drop in replacement.  The problem is that due to co-installability
> requirements we can't have half of packages out there using pycrypto and
> the other half using pycryptodome.  We'd need to hard switch everyone as
> both packages install into the same namespace.
>
> Another alternative would be to use something like cryptography instead,
> though it is not a drop in replacement, the migration would be able to
> be done piecemeal.
>
> I'd be interested in hearing about migration plans, especially from the
> affected projects.
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
- 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] [QA] Meeting Thursday Mar 9th at 9:00 UTC

[Cazares, Luz]

Hey gmann

I did bug triage last weeks (27th Feb – 3rd March).

So far 7 new bugs arrived:
3 confirmed (2 low, 1 medium)
#1669455 tempest run --regex '\[.*\bsmoke\b.*\]' 
--blacklist-file=/home/jenkins/tempest/skip.txt not able to run smoke 
tests
#1668690 Tempest test_server_actions missing evacuate server test (and 
client)
#1668407 os-assisted-volume-snapshots client is not 
available
1 in-progress
#1667354 Volume v2 capabilities & scheduler-stats service clients makes v1 APIs 
call
2 incomplete
#1667443 API endpoints become inaccessible 
after tempest run
#1671256 test_get_volume_absolute_limits fails 
with no admin credentials
1 reviewing – not sure if it is a valid bug or working as 
designed – Related to resource_cleanup vs teardown (clean after each test case).
#1670693 Tests in 
tempest.api.network.test_routers.RoutersTest don't clean up network 
resources

Please let me know if comments or questions


From: Ghanshyam Mann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, March 8, 2017 at 1:09 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [QA] Meeting Thursday Mar 9th at 9:00 UTC


Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, 
Mar 9th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_March_9th_2017_.280900_UTC.29

Anyone is welcome to add an item to the agenda.
-gmann
__
OpenStack Development Mailing 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] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Kevin Benton]

That location was recently changed in the Neutron side.[1] It sounds like
sfc has to be updated.

1.
https://github.com/openstack/neutron/commit/4ec456d31501f09c68b5c23c488878da32dce75e

On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar <
vikash.ku...@oneconvergence.com> wrote:

> Hi Igor,
>
>This is weird. I just did a fresh clone and executed *"tox" *command.
> I am getting same error. Am I missing anything here ? There is no private
> change here.  Below is the link for entire log.
>
>  http://paste.openstack.org/show/601870/
>
> On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
> igor.duarte.card...@intel.com> wrote:
>
>> Hi Vikash,
>>
>> Please stick to pastebin for complete logs.
>>
>>
>>
>> Check your migration files:
>>
>>
>>
>> FAILED: Contract HEAD file does not match migration timeline head,
>> expected: 48072cb59133
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
>> *Sent:* Tuesday, March 7, 2017 5:03 PM
>> *To:* openstack-dev 
>> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
>> "import error: vlanmanager"
>>
>>
>>
>> Complete log:
>>
>>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
>> py35 installdeps: -r/home/vikash/guess_vk/python
>> -dev/networking-sfc/requirements.txt, -r/home/vikash/guess_vk/python
>> -dev/networking-sfc/test-requirements.txt
>> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
>> py35 installed: /home/vikash/guess_vk/python-d
>> ev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
>> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
>> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==
>> 0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulso
>> up4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2=
>> =0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==
>> 1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13
>> .1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners
>> ==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.
>> 0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.
>> 4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==
>> 1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth
>> 1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,
>> linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.
>> 1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,
>> monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
>> git+https://github.com/openstack/networking-sfc.git@c51052e3
>> 748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e git+
>> https://github.com/openstack/neutron.git@41be555eddb0f99
>> 47fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,ope
>> nstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.
>> 0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,
>> oslo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==
>> 2.12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,
>> oslo.messaging==5.18.0,oslo.middleware==3.23.1,oslo.
>> policy==1.19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,
>> oslo.serialization==2.17.0,oslo.service==1.19.0,oslo.
>> utils==3.22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.
>> 10.0,oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==
>> 2.1.2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,
>> pecan==1.2.1,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,posit
>> ional==1.1.1,prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,
>> pyasn1==0.2.3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.
>> 1,Pygments==2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==
>> 0.7.10,pyparsing==2.2.0,python-cinderclient==1.11.0,
>> python-dateutil==2.6.0,python-designateclient==2.6.0,python-
>> editor==1.0.3,python-glanceclient==2.6.0,python-keystoneclie
>> nt==3.10.0,python-mimeparse==1.6.0,python-neutronclient==6.
>> 1.0,python-novaclient==7.1.0,python-openstackclient==3.8.1,
>> python-subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.
>> 1.2,repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,re
>> questsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.1,
>> Routes==2.4.1,ryu==4.12,simplejson==3.10.0,six==1.10.0,
>> snowballstemmer==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.17,
>> sqlalchemy-migrate==0.11.0,sqlparse==0.2.3,statsd==3.2.1,ste
>> vedore==1.21.0,tempest-lib==1.0.0,Tempita==0.5.2,tenacity==
>> 3.7.1,testrepository==0.0.20,testresources==2.0.1,testscenar
>> ios==0.5.0,testtools==2.2.0,tinyrpc==0.5,traceback2==1.4.
>> 0,unittest2==1.1.0,waitress==1.0.2,warlock==1.2.0,WebOb==1.
>> 6.3,WebTest==2.0.26,wrapt==1.10.8
>> py35 runtests: PYTHONHASHSEED='177840'
>> py35 runtests: commands[0] | find . -type f -name *.py[c|o] -delete
>> py35 runtests: commands[1] | find . -type d -name __pycache__ -delete
>> py35 runtests: commands[2] | /home/vikash/guess_vk/python-d
>> ev/networking-sfc/tools/ostestr_compat_shim.sh
>> 

Re: [openstack-dev] [kolla] Proposing duonghq for core

[Steven Dake (stdake)]

+1!

-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, March 8, 2017 at 1:41 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] Proposing duonghq for core

Hello,

I'd like to start voting to include Duong (duonghq) in Kolla and
Kolla-ansible core teams. Voting will be open for 2 weeks (ends at
21st of March).

Consider this my +1 vote.

Cheers,
Michal

__
OpenStack Development Mailing 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][glance][horizon][keystone][nova][qa][swift] Feedback needed: Removal of legacy per-project vanity domain redirects

[Monty Taylor]

On 03/08/2017 10:31 AM, Daniel P. Berrange wrote:
> On Wed, Mar 08, 2017 at 09:12:59AM -0600, Monty Taylor wrote:
>> Hey all,
>>
>> We have a set of old vanity redirect URLs from back when we made a URL
>> for each project:
>>
>> cinder.openstack.org
>> glance.openstack.org
>> horizon.openstack.org
>> keystone.openstack.org
>> nova.openstack.org
>> qa.openstack.org
>> swift.openstack.org
>>
>> They are being served from an old server we'd like to retire. Obviously,
>> moving a set of http redirects is trivial, but these domains have been
>> deprecated for about 4 now, so we figured we'd clean house if we can.
>>
>> We know that the swift team has previously expressed that there are
>> links out in the wild pointing to swift.o.o/content that still work and
>> that they don't want to break anyone, which is fine. (although if the
>> swift team has changed their minds, that's also welcome)
>>
>> for the rest of you, can we kill these rather than transfer them?
> 
> Does the server have any access log that could provide stats on whether
> any of the subdomains are a receiving a meaningful amount of traffic ?
> Easy to justify removing them if they're not seeing any real traffic.
>
> If there's any referrer logs present, that might highlight which places
> still have outdated links that need updating to kill off remaining
> traffic.

Yes. The majority of the hits are from search engines, fwiw. :)

However, we're also changing the current redirect from temporary to
permanent, so we're hoping that'll get the search engines to fall over
to the other thing.

I agree, doing that for a while, especially after having gotten the
redirect changed and landing the patches to remove references from our
docs should give us better info on where we stand currently.


__
OpenStack Development Mailing 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][glance][horizon][keystone][nova][qa][swift] Feedback needed: Removal of legacy per-project vanity domain redirects

[John Dickinson]

On 8 Mar 2017, at 11:04, Andreas Jaeger wrote:

> On 2017-03-08 17:23, Brian Rosmaita wrote:
>> On 3/8/17 10:12 AM, Monty Taylor wrote:
>>> Hey all,
>>>
>>> We have a set of old vanity redirect URLs from back when we made a URL
>>> for each project:
>>>
>>> cinder.openstack.org
>>> glance.openstack.org
>>> horizon.openstack.org
>>> keystone.openstack.org
>>> nova.openstack.org
>>> qa.openstack.org
>>> swift.openstack.org
>>>
>>> They are being served from an old server we'd like to retire. Obviously,
>>> moving a set of http redirects is trivial, but these domains have been
>>> deprecated for about 4 now, so we figured we'd clean house if we can.
>>>
>>> We know that the swift team has previously expressed that there are
>>> links out in the wild pointing to swift.o.o/content that still work and
>>> that they don't want to break anyone, which is fine. (although if the
>>> swift team has changed their minds, that's also welcome)
>>>
>>> for the rest of you, can we kill these rather than transfer them?
>>
>> My concern is that glance.openstack.org is easy to remember and type, so
>> I imagine there are links out there that we have no control over using
>> that URL.  So what are the consequences of it 404'ing or "site cannot be
>> reached" in a browser?
>>
>> glance.o.o currently redirects to docs.o.o/developer/glance
>>
>> If glance.o.o failed for me, I'd next try openstack.org (or
>> www.openstack.org).  Those would give me a page with a top bar of links,
>> one of which is DOCS.  If I took that link, I'd get the docs home page.
>>
>> There's a search bar there; typing in 'glance' gets me
>> docs.o.o/developer/glance as the first hit.
>>
>> If instead I scroll past the search bar, I have to scroll down to
>> "Project-Specific Guides" and follow "Services & Libraries" ->
>> "Openstack Services" -> "image service (glance) -> docs.o.o/developer/glance
>>
>> Which sounds kind of bad ... until I type "glance docs" into google.
>> Right now the first hit is docs.o.o/developer/glance.  And all the kids
>> these days use the google.  So by trying to be clever and hack the URL,
>> I could get lost, but if I just google 'glance docs', I find what I'm
>> looking for right away.
>>
>> So I'm willing to go with the majority on this, with the caveat that if
>> one or two teams keep the redirect, it's going to be confusing to end
>> users if the redirect doesn't work for other projects.
>
> Very few people know about these URLs at all and there are only a few
> places that use it in openstack (I just send a few patches for those).
> If you google for "openstack glance", you won't get this URL at all,

On the other hand, "swift.openstack.org" is the first result when searching for 
"openstack swift", and although it's very hard to find backlinks, my quick 
looking at a few search engines do suggest that there are quite a few pages 
that reference the swift vanity subdomain.

I've already approved Monty's patch to swift, but I think that's a separate 
issue from keeping the redirects active. I *am* concerned with the things Brian 
brings up. It's hard to find these docs when starting from the docs landing 
page. These dev docs have great info, and removing an easy to type/remember url 
seems to be counter to helping our users. Personally, I type 
"swift.openstack.org" all the time, just because it's short and easy to 
remember and I don't remember the one it redirects to.


--John





>
> 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


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

Re: [openstack-dev] [requirements] pycrypto is dead, long live pycryptodome... or cryptography...

[Douglas Mendizabal]

One of my goals for Barbican for this cycle is to migrate our code to use 
pyca/cryptography exclusively.  We currently depend on both because at one 
point we needed things that were not available in early releases of 
cryptography.

- Douglas Mendizábal (redrobot)

> On Mar 8, 2017, at 1:11 PM, Davanum Srinivas  wrote:
> 
> Matthew,
> 
> Please see the last time i took inventory:
> https://review.openstack.org/#/q/pycryptodome+owner:dims-v
> 
> Thanks,
> Dims
> 
> On Wed, Mar 8, 2017 at 2:03 PM, Matthew Thode  
> wrote:
>> So, pycrypto upstream is dead and has been for a while, we should look
>> at moving off of it for both bugfix and security reasons.
>> 
>> Currently it's used by the following.
>> 
>> barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,
>> kolla, openstack-ansible, and a couple of other smaller places.
>> 
>> Development of it was forked into pycryptodome, which is supposed to be
>> a drop in replacement.  The problem is that due to co-installability
>> requirements we can't have half of packages out there using pycrypto and
>> the other half using pycryptodome.  We'd need to hard switch everyone as
>> both packages install into the same namespace.
>> 
>> Another alternative would be to use something like cryptography instead,
>> though it is not a drop in replacement, the migration would be able to
>> be done piecemeal.
>> 
>> I'd be interested in hearing about migration plans, especially from the
>> affected projects.
>> 
>> --
>> Matthew Thode (prometheanfire)
>> 
>> 
>> __
>> OpenStack Development Mailing 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] pycrypto is dead, long live pycryptodome... or cryptography...

[Davanum Srinivas]

Ack thanks Matthew!

On Wed, Mar 8, 2017 at 2:24 PM, Matthew Thode  wrote:
> I'm aware, iirc it was brought up when pysaml2 had to be fixed due to a
> CVE.  This thread is more looking for a long term fix.
>
> On 03/08/2017 01:11 PM, Davanum Srinivas wrote:
>> Matthew,
>>
>> Please see the last time i took inventory:
>> https://review.openstack.org/#/q/pycryptodome+owner:dims-v
>>
>> Thanks,
>> Dims
>>
>> On Wed, Mar 8, 2017 at 2:03 PM, Matthew Thode  
>> wrote:
>>> So, pycrypto upstream is dead and has been for a while, we should look
>>> at moving off of it for both bugfix and security reasons.
>>>
>>> Currently it's used by the following.
>>>
>>> barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,
>>> kolla, openstack-ansible, and a couple of other smaller places.
>>>
>>> Development of it was forked into pycryptodome, which is supposed to be
>>> a drop in replacement.  The problem is that due to co-installability
>>> requirements we can't have half of packages out there using pycrypto and
>>> the other half using pycryptodome.  We'd need to hard switch everyone as
>>> both packages install into the same namespace.
>>>
>>> Another alternative would be to use something like cryptography instead,
>>> though it is not a drop in replacement, the migration would be able to
>>> be done piecemeal.
>>>
>>> I'd be interested in hearing about migration plans, especially from the
>>> affected projects.
>>>
>>> --
>>> Matthew Thode (prometheanfire)
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
> OpenStack Development Mailing 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] pycrypto is dead, long live pycryptodome... or cryptography...

[Matthew Thode]

I'm aware, iirc it was brought up when pysaml2 had to be fixed due to a
CVE.  This thread is more looking for a long term fix.

On 03/08/2017 01:11 PM, Davanum Srinivas wrote:
> Matthew,
> 
> Please see the last time i took inventory:
> https://review.openstack.org/#/q/pycryptodome+owner:dims-v
> 
> Thanks,
> Dims
> 
> On Wed, Mar 8, 2017 at 2:03 PM, Matthew Thode  
> wrote:
>> So, pycrypto upstream is dead and has been for a while, we should look
>> at moving off of it for both bugfix and security reasons.
>>
>> Currently it's used by the following.
>>
>> barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,
>> kolla, openstack-ansible, and a couple of other smaller places.
>>
>> Development of it was forked into pycryptodome, which is supposed to be
>> a drop in replacement.  The problem is that due to co-installability
>> requirements we can't have half of packages out there using pycrypto and
>> the other half using pycryptodome.  We'd need to hard switch everyone as
>> both packages install into the same namespace.
>>
>> Another alternative would be to use something like cryptography instead,
>> though it is not a drop in replacement, the migration would be able to
>> be done piecemeal.
>>
>> I'd be interested in hearing about migration plans, especially from the
>> affected projects.
>>
>> --
>> Matthew Thode (prometheanfire)
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 


-- 
Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed: Removal of legacy per-project vanity domain redirects

[Steve Martinelli]

On Wed, Mar 8, 2017 at 2:04 PM, Andreas Jaeger  wrote:
>
> Very few people know about these URLs at all and there are only a few
> places that use it in openstack (I just send a few patches for those).
>

++

I had no idea they existed...
__
OpenStack Development Mailing 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] [kolla] kolla-ansible 4.0.0.0rc2 (ocata)

[no-reply]

Hello everyone,

A new release candidate for kolla-ansible for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/kolla-ansible/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:

http://git.openstack.org/cgit/openstack/kolla-ansible/log/?h=stable/ocata

Release notes for kolla-ansible can be found at:

http://docs.openstack.org/releasenotes/kolla-ansible/



__
OpenStack Development Mailing 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][tripleo] initial discussion for a new periodic pipeline

[Jeremy Stanley]

On 2017-03-07 10:12:58 -0500 (-0500), Wesley Hayutin wrote:
> The TripleO team would like to initiate a conversation about the
> possibility of creating a new pipeline in Openstack Infra to allow
> a set of jobs to run periodically every four hours
[...]

The request doesn't strike me as contentious/controversial. Why not
just propose your addition to the zuul/layout.yaml file in the
openstack-infra/project-config repo and hash out any resulting
concerns via code review?
-- 
Jeremy Stanley

__
OpenStack Development Mailing 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] Proposing duonghq for core

[Kwasniewska, Alicja]

+1

From: Mauricio Lima >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, March 8, 2017 at 5:34 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla] Proposing duonghq for core

+1

2017-03-08 7:34 GMT-03:00 Christian Berendt 
>:
+1

> On 8 Mar 2017, at 07:41, Michał Jastrzębski 
> > wrote:
>
> Hello,
>
> I'd like to start voting to include Duong (duonghq) in Kolla and
> Kolla-ansible core teams. Voting will be open for 2 weeks (ends at
> 21st of March).
>
> Consider this my +1 vote.
>
> Cheers,
> Michal
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139


__
OpenStack Development Mailing 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][Heat] Selectively disabling deployment resources

[James Slagle]

On Wed, Mar 8, 2017 at 4:08 AM, Steven Hardy  wrote:
> On Tue, Mar 07, 2017 at 02:34:50PM -0500, James Slagle wrote:
>> I've been working on this spec for TripleO:
>> https://review.openstack.org/#/c/431745/
>>
>> which allows users to selectively disable Heat deployment resources
>> for a given server (or server in the case of a *DeloymentGroup
>> resource).
>>
>> Some of the main use cases in TripleO for such a feature are scaling
>> out compute nodes where you do not need to rerun Puppet (or make any
>> changes at all) on non-compute nodes, or to exclude nodes from hanging
>> a stack-update if you know they are unreachable or degraded for some
>> reason. There are others, but those are 2 of the major use cases.
>
> Thanks for raising this, I know it's been a pain point for some users of
> TripleO.
>
> However I think we're conflating two different issues here:
>
> 1. Don't re-run puppet (or yum update) when no other changes have happened
>
> 2. Disable deployment resources when changes have happened

Yea, possibly, but (1) doesn't really solve the use cases in the spec.
It'd certainly be a small improvement, but it's not really what users
are asking for.

(2) is much more difficult to reason about because we in fact have to
execute puppet to fully determine if changes have happened.

I don't really think these two are conflated. For some purposes, the
2nd is just a more abstract definition of the first. For better or
worse, part of the reason people are asking for this feature is
because they don't want to undo manual changes. While that's not
something we should really spend a lot of time solving for, the fact
is that OpenStack architecture allows for horizontally scaling compute
nodes without have to touch every other single node in your deployment
but TripleO can't take advantage of that.

So, just giving users a way to opt out of the generated unique
identifier triggering the puppet applys and other deployments,
wouldn't help them if they unintentionally changed some other hiera
data that triggers a deployment.

Plus, we have some deployments that are going to execute every time
outside of unique identifiers being generated (hosts-config.yaml).

> (1) is actually very simple, and is the default behavior of Heat
> (SoftwareDeployment resources never update unless either the config
> referenced or the input_values change).  We just need to provide an option
> to disable the DeployIdentifier/UpdateIdentifier timestamps from being
> generated in tripleoclient.
>
> (2) is harder, because the whole point of SoftwareDeploymentGroup is to run
> the exact same configuration on a group of servers, with no exceptions.
>
> As Zane mentions (2) is related to the way ResourceGroup works, but the
> problem here isn't ResourceGroup per-se, as it would in theory be pretty
> easy to reimplement SoftwareDeploymentGroup to generate it's nested stack
> without inheriting from ResourceGroup (which may be needed if you want a
> flag to make existing Deployments in the group immutable).
>
> I'd suggest we solve (1) and do some testing, it may be enough to solve the
> "don't change computes on scale-out" case at least?

Possibly, as long as no other deployments are triggered. I think of
the use case more as:

add a compute node(s), don't touch any existing nodes to minimize risk

as opposed to:

add a compute node(s), don't re-run puppet on any existing nodes as I
know that it's not needed

For the scale out case, the desire to minimize risk is a big part of
why other nodes don't need to be touched.

>
> One way to potentially solve (2) would be to unroll the
> SoftwareDeploymentGroup resources and instead generate the Deployment
> resources via jinja2 - this would enable completely removing them on update
> if that's what is desired, similar to what we already do for upgrades to
> e.g not upgrade any compute nodes.

Thanks, I hadn't considered that approach, but will look into it. I'd
guess you'd still need a parameter or map data fed into the jinja2
templating, so that it would not generate the deployment resources
based on what was desired to be disabled. Or, this could use
conditionals perhaps.



-- 
-- James Slagle
--

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

Re: [openstack-dev] [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed: Removal of legacy per-project vanity domain redirects

[Daniel P. Berrange]

On Wed, Mar 08, 2017 at 09:12:59AM -0600, Monty Taylor wrote:
> Hey all,
> 
> We have a set of old vanity redirect URLs from back when we made a URL
> for each project:
> 
> cinder.openstack.org
> glance.openstack.org
> horizon.openstack.org
> keystone.openstack.org
> nova.openstack.org
> qa.openstack.org
> swift.openstack.org
> 
> They are being served from an old server we'd like to retire. Obviously,
> moving a set of http redirects is trivial, but these domains have been
> deprecated for about 4 now, so we figured we'd clean house if we can.
> 
> We know that the swift team has previously expressed that there are
> links out in the wild pointing to swift.o.o/content that still work and
> that they don't want to break anyone, which is fine. (although if the
> swift team has changed their minds, that's also welcome)
> 
> for the rest of you, can we kill these rather than transfer them?

Does the server have any access log that could provide stats on whether
any of the subdomains are a receiving a meaningful amount of traffic ?
Easy to justify removing them if they're not seeing any real traffic.

If there's any referrer logs present, that might highlight which places
still have outdated links that need updating to kill off remaining
traffic.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

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

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

[David Moreau Simard]

The App Catalog, to me, sounds sort of like a weird message that
OpenStack somehow requires applications to be
packaged/installed/deployed differently.
If anything, perhaps we should spend more effort on advertising that
OpenStack provides bare metal or virtual compute resources and that
apps will work just like any other places.

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Wed, Mar 8, 2017 at 9:41 AM, Jay Pipes  wrote:
> On 03/06/2017 06:26 AM, Thierry Carrez wrote:
>>
>> Hello everyone,
>>
>> The App Catalog was created early 2015 as a marketplace of pre-packaged
>> applications that you can deploy using Murano. Initially a demo by
>> Mirantis, it was converted into an open upstream project team, and
>> deployed as a "beta" as apps.openstack.org.
>>
>> Since then it grew additional categories (Glance images, Heat & Tosca
>> templates), but otherwise did not pick up a lot of steam. The website
>> (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
>> heat templates and 94 murano packages (~30% of which are just thin
>> wrappers around Docker containers). Traffic stats show around 100 visits
>> per week, 75% of which only read the index page.
>>
>> In parallel, Docker developed a pretty successful containerized
>> application marketplace (the Docker Hub), with hundreds of thousands of
>> regularly-updated apps. Keeping the App Catalog around (including its
>> thinly-wrapped Docker container Murano packages) make us look like we
>> are unsuccessfully trying to compete with that ecosystem, while
>> OpenStack is in fact completely complementary.
>>
>> In the past we have retired projects that were dead upstream. The App
>> Catalog is not in this case: it has an active maintenance team, which
>> has been successfully maintaining the framework and accepting
>> applications. If we end up retiring the App Catalog, it would clearly
>> not be a reflection on that team performance, which has been stellar
>> despite limited resources. It would be because the beta was arguably not
>> successful in building an active marketplace of applications, and
>> because its continuous existence is not a great fit from a strategy
>> perspective. Such removal would be a first for our community, but I
>> think it's now time to consider it.
>>
>> Before we discuss or decide anything at the TC level, I'd like to
>> collect everyone thoughts (and questions) on this. Please feel free to
>> reply to this thread (or reach out to me privately if you prefer). Thanks
>> !
>
>
> Mirantis' position is that the App Catalog was a good idea, but we agree
> with you that other application repositories like DockerHub and Quay.io are
> both more useful and more actively used.
>
> The OpenStack App Catalog does indeed seem to unnecessarily compete with
> those application repositories, and we would support its retirement if that
> is what the community would like to do. We'll provide resources and help in
> winding anything down if needed.
>
> Best,
> -jay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed: Removal of legacy per-project vanity domain redirects

[Lance Bragstad]

>From a keystone-perspective, I'm fine killing keystone.openstack.org.
Unless another team member with more context/history has a reason to keep
it around.

On Wed, Mar 8, 2017 at 9:12 AM, Monty Taylor  wrote:

> Hey all,
>
> We have a set of old vanity redirect URLs from back when we made a URL
> for each project:
>
> cinder.openstack.org
> glance.openstack.org
> horizon.openstack.org
> keystone.openstack.org
> nova.openstack.org
> qa.openstack.org
> swift.openstack.org
>
> They are being served from an old server we'd like to retire. Obviously,
> moving a set of http redirects is trivial, but these domains have been
> deprecated for about 4 now, so we figured we'd clean house if we can.
>
> We know that the swift team has previously expressed that there are
> links out in the wild pointing to swift.o.o/content that still work and
> that they don't want to break anyone, which is fine. (although if the
> swift team has changed their minds, that's also welcome)
>
> for the rest of you, can we kill these rather than transfer them?
>
> Thanks!
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [infra] Depends-on tag effect

[Hirofumi Ichihara]

On 2017/03/08 23:59, Andreas Jaeger wrote:

On 2017-03-08 15:40, ZZelle wrote:

Hi,

iiuc, neutron uses a released version of neutron-lib not neutron-lib
master ... So the change should depends on a change in requirements repo
incrementing neutron-lib version

This is documented also at - together with some other caveats:

https://docs.openstack.org/infra/manual/developers.html#limitations-and-caveats

Thank you for the pointer. I understand.

Hirofumi




Note a depends-on requirements won't work either - you really need to
release it. Or you need to change the test to pull neutron-lib from source,

Andreas

On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara
> wrote:

 Hi,

 I thought that we can post neutron patch depending on neutron-lib
 patch under review.
 However, I saw it doesn't work[1, 2]. In the patches, neutron
 patch[1] has Depends-on tag with neutron-lib patch[2] but the pep8
 and unit test fails because the test doesn't use the neutron-lib patch.

 Please correct me if it's my misunderstanding.

 [1]: https://review.openstack.org/#/c/424340/
 
 [2]: https://review.openstack.org/#/c/424868/
 

 Thanks,
 Hirofumi



 __
 OpenStack Development Mailing 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][placement-api] Is there any document about openstack-placement-api for installation and configure?

[Chris Dent]

On Wed, 8 Mar 2017, Yu Wei wrote:


When I tried to configure placement-api, I met following problems,

AH01630: client denied by server configuration: /usr/bin/nova-placement-api


That can be fixed by doing (somewhere in your apache config):


Require all granted


but rather than doing that you may wish to move nova-placement-api
to a less global directory and grant access to that directory.
Providing wide access to /usr/bin is not a great idea.

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

Re: [openstack-dev] [nova][placement-api] Is there any document about openstack-placement-api for installation and configure?

[Yu Wei]

@Chris, Thanks for replying.

When I tried to configure placement-api, I met following problems,

AH01630: client denied by server configuration: /usr/bin/nova-placement-api

I will read the links you pointed out.

Thanks again,

Jared


On 2017年03月08日 23:07, Chris Dent wrote:
On Wed, 8 Mar 2017, Yu Wei wrote:

I'm new to openstack.
I tried to install openstack-ocata.
As placement-api is required since Ocata, is there any detailed document
about how to install and configure placement-api?

There are two different things which might be useful to you. Some
nova "in-tree" docs about placement:

https://docs.openstack.org/developer/nova/placement.html
https://docs.openstack.org/developer/nova/placement_dev.html

and some in progress documents about installing placement:

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

That latter has some errors that are in the process of being fixed,
so make sure you read the associated comments.




__
OpenStack Development Mailing 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][Heat] Selectively disabling deployment resources

[James Slagle]

On Tue, Mar 7, 2017 at 7:24 PM, Zane Bitter  wrote:
> On 07/03/17 14:34, James Slagle wrote:
>>
>> I've been working on this spec for TripleO:
>> https://review.openstack.org/#/c/431745/
>>
>> which allows users to selectively disable Heat deployment resources
>> for a given server (or server in the case of a *DeloymentGroup
>> resource).
>
>
> I'm not completely clear on what this means. You can selectively disable
> resources with conditionals. But I think you mean that you want to
> selectively disable *changes* to resources?

Yes, that's right. The reason I can't use conditionals is that I still
want the SoftwareDeploymentGroup resources to be updated, but I may
want to selectively exclude servers from the group that is passed in
via the servers property. E.g., instead of updating the deployment
metadata for *all* computes, I may want to exclude a single compute
that is temporarily unreachable, without that failing the whole
stack-update.

>> I started by taking an approach that would be specific to TripleO.
>> Basically mapping all the deployment resources to a nested stack
>> containing the logic to selectively disable servers from the
>> deployment (using yaql) based on a provided parameter value. Here's
>> the main patch: https://review.openstack.org/#/c/442681/
>>
>> After considering that complexity, particularly the yaql expression,
>> I'm wondering if it would be better to add this support natively to
>> Heat.
>>
>> I was looking at the restricted_actions key in the resource_registry
>> and was thinking this might be a reasonable place to add such support.
>> It would require some changes to how restricted_actions work.
>>
>> One change would be a method for specifying that restricted_actions
>> should not fail the stack operation if an action would have otherwise
>> been triggered. Currently the behavior is to raise an exception and
>> mark the stack failed if an action needs to be taken but has been
>> marked restricted. That would need to be tweaked to allow specifying
>> that that we don't want the stack to fail. One thought would be to
>> change the allowed values of restricted_actions to:
>>
>> replace_fail
>> replace_ignore
>> update_fail
>> update_ignore
>> replace
>> update
>>
>> where replace and update were synonyms for replace_fail/update_fail to
>> maintain backwards compatibility.
>
>
> Anything that involves the resource definition in the template changing but
> Heat not modifying the resource is problematic, because that messes with
> Heat's internal bookkeeping.

I don't think this case would violate that principle. The template +
environment files would match what Heat has done. After an update, the
2 would be in sync as to what servers the updated Deployment resource
was triggered.

>
>> Another change would be to add logic to the Deployment resources
>> themselves to consider if any restricted_actions have been set on an
>> Server resources before triggering an updated deployment for a given
>> server.
>
>
> Why not just a property, "no_new_deployments_please: true"?

That would actually work and be pretty straightforward I think. We
could have a map parameter with server names and the property that the
user could use to set the value.

The reason why I was initially not considering this route was because
it doesn't allow the user to disable only some deployments for a given
server. It's all or nothing. However, it's much simpler than a totally
flexible option, and it addresses 2 of the largest use cases of this
feature. I'll look into this route a bit more.

-- 
-- James Slagle
--

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

[openstack-dev] [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed: Removal of legacy per-project vanity domain redirects

[Monty Taylor]

Hey all,

We have a set of old vanity redirect URLs from back when we made a URL
for each project:

cinder.openstack.org
glance.openstack.org
horizon.openstack.org
keystone.openstack.org
nova.openstack.org
qa.openstack.org
swift.openstack.org

They are being served from an old server we'd like to retire. Obviously,
moving a set of http redirects is trivial, but these domains have been
deprecated for about 4 now, so we figured we'd clean house if we can.

We know that the swift team has previously expressed that there are
links out in the wild pointing to swift.o.o/content that still work and
that they don't want to break anyone, which is fine. (although if the
swift team has changed their minds, that's also welcome)

for the rest of you, can we kill these rather than transfer them?

Thanks!
Monty

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

[openstack-dev] [ironic] Pike PTG report

[Dmitry Tantsur]

Hi all!

I've finished my Pike PTG report. It is spread over four blog posts:

http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-1.html
http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-2.html
http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-3.html
http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-4.html

It was a lot of typing, please pardon mistakes. The whole text (in RST format) 
for archiving purposes is copy-pasted in the end of this message.


Please feel free to respond here or in the blog comments.

Cheers,
Dmitry


Ongoing work and status updates
---

Etherpad: https://etherpad.openstack.org/p/ironic-pike-ptg-ongoing-work.

We spent the first half of Wednesday discussing this. There was a lot of
incomplete work left from Ocata, and some major ongoing work that we did not
even plan to finish in Ocata.

Boot-from-volume


Got some progress, most of the Ironic patches are up. Desperately needs review
and testing, though. The Nova part is also lagging behind, and should be
brought to the Nova team attention.

**Actions**
**mgoddard** and **dtantsur** volunteered to help with testing, while
**mjturek**, **hsiina** and **crushil** volunteered to do some coding.
**Goals for Pike**
finish the first (iSCSI using iPXE) case and the Nova part.

Networking
~~

A lot of progress here during Ocata, completed bonding and attach/detach API.

VLAN-aware instances should work. However, it requires an expensive ToR switch,
supporting VLAN/VLAN and VLAN/VXLAN rewriting, and, of course ML2 plugin
support. Also, reusing an existing segmentation ID requires more work: we have
no current way to put the right ID in the configdrive.

**Actions**
**vsaienko**, **armando** and **kevinbenton** are looking into the Neutron
part of the configdrive problem.

Routed networks support require Ironic to be aware of which physical network(s)
each node is connected to.

**Goals for Pike**
* model physical networks on Ironic ports,
* update VIF attach logic to no longer attach things to wrong physnets.

We discussed introducing notifications from Neutron to Ironic about events
of interest for us. We are going to use the same model as between Neutron and
Nova: create a Neutron plugin that filters out interesting events and posts
to a new Ironic API endpoint.

**Goals for Pike**
have this notification system in place.

Finally, we agreed that we need to work on a reference architecture document,
describing the best practices of deploying Ironic, especially around
multi-tenant networking setup.

**Actions**
**jroll** to kickstart this document, **JayF** and **mariojv** to help.

Rolling upgrades


Missed Ocata by a small margin. The code is up and needs reviewing. The CI
is waiting for the multinode job to start working (should be close as well).

**Goals for Pike**
rolling upgrade Ocata -> Pike.

Driver composition reform
~

Most of the code landed in Ocata already. Some client changes landed in Pike,
some are still on review. As we released Ocata with the driver composition
changes being experimental, we are not ready to deprecate old-style drivers in
Pike. Documentation is also still lacking.

**Goals for Pike**
* make new-style dynamic drivers the recommend way of writing and using
  drivers,
* fill in missing documentation,
* *recommend* vendors to have hardware types for their hardware, as well
  as 3rdparty CI support for it.
**Important decisions**
* no new classic drivers are accepted in-tree (please check when accepting
  specifications),
* no new interfaces additions for classic drivers(``volume_interface`` is
  the last accepted from them),
* remove the SSH drivers by Pike final (probably around M3).

Ironic Inspector HA
~~~

Preliminary work (switch to a real state machine) done in Ocata. Splitting the
service into API and conductor/engine parts correlates with the WSGI
cross-project goal.

We also had a deeper discussion about ironic-inspector architecture earlier
that week, where we were `looking
`_ into
potential future work to make ironic-inspector both HA and multi-tenancy
friendly. It was suggested to split *discovery* process (simple process to
detect MACs and/or power credentials) and *inspection* process (full process
when a MAC is known).

**Goals for Pike**
* switch locking to ``tooz`` (with Redis probably being the default
  backend for now),
* split away API process with WSGI support,
* leader election using ``tooz`` for periodic tasks,
* stop messing with ``iptables`` and start directly managing ``dnsmasq``
  instead (similarly to how Neutron does it),
* try using ``dnsmasq`` in active/active configuration with
  non-intersecting IP addresses pools from the same subnet.
**Actions**
also **sambetts** 

Re: [openstack-dev] [nova][placement-api] Is there any document about openstack-placement-api for installation and configure?

[Chris Dent]

On Wed, 8 Mar 2017, Yu Wei wrote:


I'm new to openstack.
I tried to install openstack-ocata.
As placement-api is required since Ocata, is there any detailed document
about how to install and configure placement-api?


There are two different things which might be useful to you. Some
nova "in-tree" docs about placement:

https://docs.openstack.org/developer/nova/placement.html
https://docs.openstack.org/developer/nova/placement_dev.html

and some in progress documents about installing placement:

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

That latter has some errors that are in the process of being fixed,
so make sure you read the associated comments.

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

[openstack-dev] [nova][placement-api] Is there any document about openstack-placement-api for installation and configure?

[Yu Wei]

Hi Guys,
I'm new to openstack.
I tried to install openstack-ocata.
As placement-api is required since Ocata, is there any detailed document 
about how to install and configure placement-api?

Thanks,
Jared

__
OpenStack Development Mailing 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] [infra] Depends-on tag effect

[Andreas Jaeger]

On 2017-03-08 15:40, ZZelle wrote:
> Hi,
> 
> iiuc, neutron uses a released version of neutron-lib not neutron-lib
> master ... So the change should depends on a change in requirements repo
> incrementing neutron-lib version

This is documented also at - together with some other caveats:

https://docs.openstack.org/infra/manual/developers.html#limitations-and-caveats


Note a depends-on requirements won't work either - you really need to
release it. Or you need to change the test to pull neutron-lib from source,

Andreas
> 
> On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara
>  > wrote:
> 
> Hi,
> 
> I thought that we can post neutron patch depending on neutron-lib
> patch under review.
> However, I saw it doesn't work[1, 2]. In the patches, neutron
> patch[1] has Depends-on tag with neutron-lib patch[2] but the pep8
> and unit test fails because the test doesn't use the neutron-lib patch.
> 
> Please correct me if it's my misunderstanding.
> 
> [1]: https://review.openstack.org/#/c/424340/
> 
> [2]: https://review.openstack.org/#/c/424868/
> 
> 
> Thanks,
> Hirofumi
> 
> 
> 
> __
> OpenStack Development Mailing 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
> 


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


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

Re: [openstack-dev] [neutron] [infra] Depends-on tag effect

[ZZelle]

Hi,

iiuc, neutron uses a released version of neutron-lib not neutron-lib master
... So the change should depends on a change in requirements repo
incrementing neutron-lib version

On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara <
ichihara.hirof...@lab.ntt.co.jp> wrote:

> Hi,
>
> I thought that we can post neutron patch depending on neutron-lib patch
> under review.
> However, I saw it doesn't work[1, 2]. In the patches, neutron patch[1] has
> Depends-on tag with neutron-lib patch[2] but the pep8 and unit test fails
> because the test doesn't use the neutron-lib patch.
>
> Please correct me if it's my misunderstanding.
>
> [1]: https://review.openstack.org/#/c/424340/
> [2]: https://review.openstack.org/#/c/424868/
>
> Thanks,
> Hirofumi
>
>
>
> __
> OpenStack Development Mailing 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] [tc][appcat] The future of the App Catalog

[Jay Pipes]

On 03/06/2017 06:26 AM, Thierry Carrez wrote:

Hello everyone,

The App Catalog was created early 2015 as a marketplace of pre-packaged
applications that you can deploy using Murano. Initially a demo by
Mirantis, it was converted into an open upstream project team, and
deployed as a "beta" as apps.openstack.org.

Since then it grew additional categories (Glance images, Heat & Tosca
templates), but otherwise did not pick up a lot of steam. The website
(still labeled "beta") features 45 glance images, 6 Tosca templates, 13
heat templates and 94 murano packages (~30% of which are just thin
wrappers around Docker containers). Traffic stats show around 100 visits
per week, 75% of which only read the index page.

In parallel, Docker developed a pretty successful containerized
application marketplace (the Docker Hub), with hundreds of thousands of
regularly-updated apps. Keeping the App Catalog around (including its
thinly-wrapped Docker container Murano packages) make us look like we
are unsuccessfully trying to compete with that ecosystem, while
OpenStack is in fact completely complementary.

In the past we have retired projects that were dead upstream. The App
Catalog is not in this case: it has an active maintenance team, which
has been successfully maintaining the framework and accepting
applications. If we end up retiring the App Catalog, it would clearly
not be a reflection on that team performance, which has been stellar
despite limited resources. It would be because the beta was arguably not
successful in building an active marketplace of applications, and
because its continuous existence is not a great fit from a strategy
perspective. Such removal would be a first for our community, but I
think it's now time to consider it.

Before we discuss or decide anything at the TC level, I'd like to
collect everyone thoughts (and questions) on this. Please feel free to
reply to this thread (or reach out to me privately if you prefer). Thanks !


Mirantis' position is that the App Catalog was a good idea, but we agree 
with you that other application repositories like DockerHub and Quay.io 
are both more useful and more actively used.


The OpenStack App Catalog does indeed seem to unnecessarily compete with 
those application repositories, and we would support its retirement if 
that is what the community would like to do. We'll provide resources and 
help in winding anything down if needed.


Best,
-jay

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

Re: [openstack-dev] [nova] Question to clarify versioned notifications

[Matt Riedemann]

On 3/8/2017 4:19 AM, Balazs Gibizer wrote:


Honestly, If searchlight needs to be adapted to the versioned
notifications then the smallest thing to change is to handle the removed
prefix from the event_type. The biggest difference is the format and the
content of the payload. In the legacy notifications the payload was a
simply json dict in the versioned notification the payload is a json
serialized ovo. Which means quite a different data structure. E.g. extra
keys, deeper nesting, etc.

Cheers,
gibi



Heh, yeah, I agree. Thanks for the confirmation and details. I was just 
making sure I had this all straight since I was jumping around from 
specs and docs and code quite a bit yesterday piecing this together and 
wanted to make sure I had it straight. Plus you don't apparently work 20 
hours a day gibi so I couldn't ask you in IRC. :)


--

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

[openstack-dev] [neutron] [infra] Depends-on tag effect

[Hirofumi Ichihara]

Hi,

I thought that we can post neutron patch depending on neutron-lib patch  
under review.
However, I saw it doesn't work[1, 2]. In the patches, neutron patch[1]  
has Depends-on tag with neutron-lib patch[2] but the pep8 and unit test  
fails because the test doesn't use the neutron-lib patch.


Please correct me if it's my misunderstanding.

[1]: https://review.openstack.org/#/c/424340/
[2]: https://review.openstack.org/#/c/424868/

Thanks,
Hirofumi



__
OpenStack Development Mailing 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] OpenStack client default ironic API version

[Mario Villaplana]

We want to deprecate ironic CLI soon, but I would prefer if that were
discussed on a separate thread if possible, aside from concerns about
versioning in ironic CLI. Feature parity should exist in Pike, then we
can issue a warning in Queens and deprecate the cycle after. More
information is on L56:
https://etherpad.openstack.org/p/ironic-pike-ptg-operations

I'm a bit torn on whether to use the API version coded in the OSC
plugin or not. On one hand, it'd be good to be able to test out new
features as soon as they're available. On the other hand, it's
possible that the client won't know how to parse certain items after a
microversion bump. I think I prefer using the hard-coded version to
avoid breakage, but we'd have to be disciplined about updating the
client when the API version is bumped (if needed). Opinions on this
are welcome. In either case, I think the deprecation warning could
land without specifying that.

I'll certainly make an RFE when I update the patch later this week,
great suggestion.

I can make a spec, but it might be mostly empty except for the client
impact section. Also, this is a < 40 line change. :)

Mario

On Tue, Mar 7, 2017 at 10:59 AM, Loo, Ruby  wrote:
> On 2017-03-06, 3:46 PM, "Mario Villaplana"  wrote:
>
> Hi ironic,
>
> At the PTG, an issue regarding the default version of the ironic API
> used in our python-openstackclient plugin was discussed. [0] In short,
> the issue is that we default to a very old API version when the user
> doesn't otherwise specify it. This limits discoverability of new
> features and makes the client more difficult to use for deployments
> running the latest version of the code.
>
> We came to the following consensus:
>
> 1. For a deprecation period, we should log a warning whenever the user
> doesn't specify an API version, informing them of this change.
>
> 2. After the deprecation period:
>
> a) OSC baremetal plugin will default to the latest available version
>
> I think OSC and ironic CLI have the same behaviour -- are we only interested 
> in OSC or are we interested in both, except that we also want to at some 
> point soon perhaps, deprecate ironic CLI?
>
> Also, by 'latest available version', the OSC plugin knows (or thinks it 
> knows) what the latest version is [1]. Will you be using that, or 'latest'?
>
> b) Specifying just macroversion will default to latest microversion
> within that macroversion (example: --os-baremetal-api-version=1 would
> default to 1.31 if 1.31 is the last microversion with 1 macroversion,
> even if we have API 2.2 supported)
>
> I have a patch up for review with the deprecation warning:
> https://review.openstack.org/442153
>
> Do you have an RFE? I'd like a spec for this too please.
>
> Please comment on that patch with any concerns.
>
> We also still have yet to decide what a suitable deprecation period is
> for this change, as far as I'm aware. Please respond to this email
> with any suggestions on the deprecation period.
>
> Thanks,
> Mario
>
>
> [0] https://etherpad.openstack.org/p/ironic-pike-ptg-operations L30
>
> Thank YOU!
>
> --ruby
>
> [1] 
> https://github.com/openstack/python-ironicclient/blob/f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L29
>
> __
> OpenStack Development Mailing 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] [kolla][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud archive ocata repo bust

[Corey Bryant]

On Tue, Mar 7, 2017 at 10:28 PM, Jeffrey Zhang 
wrote:

> Kolla deploy ubuntu gate is red now. here is the related bug[0].
>
> libvirt failed to access the console.log file when booting instance. After
> made some debugging, i got following.
>
>
Jeffrey,  This is likely fixed in ocata-proposed and should be promoted to
ocata-updates soon after testing completes.
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1667033.

Corey


# how console.log works
> nova create a empty console.log with nova:nova ( this is another bug
> workaround actually[1]), then libvirt ( running with root ) will change the
> file owner to qemu process user/group ( configured by dynamic_ownership ).
> Now qemu process can write logs into this file.
>
> # what's wrong now
> libvirt 2.5.0 stop change the file owner, then qemu/libvirt failed to write
> logs into console.log file
>
> # other test
>
> * ubuntu + fallback libvirt 1.3.x works [2]
> * ubuntu + libvirt 2.5.0 + chang the qemu process user/group to
>   nova:nova works, too.[3]
> * centos + libvirt 2.0.0 works, never saw such issue in centos.
>
> # conclusion
> I guess there are something wrong in libvirt 2.5.0 with dynamic_ownership
>
>
> [0] https://bugs.launchpad.net/kolla-ansible/+bug/1668654
> [1] https://github.com/openstack/nova/blob/master/
> nova/virt/libvirt/driver.py#L2922,L2952
> [2] https://review.openstack.org/442673
> [3] https://review.openstack.org/442850
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing 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] [trove] today weekly meeting

[Amrith Kumar]

While I try to schedule my life to not conflict with the weekly Trove
meeting, it appears that Wednesday afternoon at 1pm is a particularly
popular time for people to want to meet me.

 

This week, and next week are no exception. While I'd tried to avoid these
conflicts, I've managed to be unable to do it (again).

 

Nikhil (slicknik) has kindly agreed to run the meeting today, same place,
same time as always.

 

Thanks Nikhil.

 

-amrith

__
OpenStack Development Mailing 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] No team meeting today, resume next Wed

[Harm Sluiman]

Thanks for the update. Unfortunately I could not attend and can't seem to find 
a summary or anything about what took place.  A pointer  would be appreciated 
please ;-)

Thanks for your time
Harm Sluiman
harm.slui...@gmail.com


> On Mar 8, 2017, at 7:22 AM, Zhipeng Huang  wrote:
> 
> Hi team,
> 
> As agreed per our PTG/VTG session, we will have the team meeting two weeks 
> after to give people enough time to prepare the BPs we discussed.
> 
> Therefore there will be no team meeting today, and the next meeting is on 
> next Wed.
> __
> OpenStack Development Mailing 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] [telemetry][requirements] ceilometer grenade gate failure

[gordon chung]

On 07/03/17 11:16 PM, Tony Breeds wrote:
> Sure.
>
> I've approved it but it's blocked behind 
> https://review.openstack.org/#/c/442886/1

awesome! thanks Tony!

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] [tc][appcat][murano][app-catalog] The future of the App Catalog

[Ian Cordasco]

-Original Message-
From: Christopher Aedo 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: March 7, 2017 at 22:11:22
To: OpenStack Development Mailing List (not for usage questions)

Subject:  Re: [openstack-dev] [tc][appcat][murano][app-catalog] The
future of the App Catalog

> On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez wrote:
> > Hello everyone,
> >
> > The App Catalog was created early 2015 as a marketplace of pre-packaged
> > applications that you can deploy using Murano. Initially a demo by
> > Mirantis, it was converted into an open upstream project team, and
> > deployed as a "beta" as apps.openstack.org.
> >
> > Since then it grew additional categories (Glance images, Heat & Tosca
> > templates), but otherwise did not pick up a lot of steam. The website
> > (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
> > heat templates and 94 murano packages (~30% of which are just thin
> > wrappers around Docker containers). Traffic stats show around 100 visits
> > per week, 75% of which only read the index page.
> >
> > In parallel, Docker developed a pretty successful containerized
> > application marketplace (the Docker Hub), with hundreds of thousands of
> > regularly-updated apps. Keeping the App Catalog around (including its
> > thinly-wrapped Docker container Murano packages) make us look like we
> > are unsuccessfully trying to compete with that ecosystem, while
> > OpenStack is in fact completely complementary.
>
> Without something like Murano "thinly wrapping" docker apps, how would
> you propose current users of OpenStack clouds deploy docker apps? Or
> any other app for that matter? It seems a little unfair to talk about
> murano apps this way when no reasonable alternative exists for easily
> deploying docker apps. When I look back at the recent history of how
> we've handled containers (nova-docker, magnum, kubernetes, etc) it
> does not seem like we're making it easy for the folks who want to
> deploy a container on their cloud...
>
> Please understand I am not pleading to keep the Community App Catalog
> alive in perpetuity. This just sounds like an unfair point of
> comparison. One of the biggest challenges we've faced with the app
> catalog since day one is that there is no such thing as a simple
> definition of an "OpenStack Application". OpenStack is an IaaS before
> anything else, and to my knowledge there is no universally accepted
> application deployment mechanism for OpenStack clouds. Heat doesn't
> solve that problem as its very operator focused, and while being very
> popular and used heavily, it's not used as a way to share generic
> templates suitable for deploying apps across different clouds. Murano
> is not widely adopted (last time I checked it's not available on any
> public clouds, though I hear it is actually used on a several
> university clouds, and it's also used on a few private clouds I'm
> aware of.)
>
> As a place to find things that run on OpenStack clouds, the app
> catalog did a reasonable job. If anything, the experiment showed that
> there is no community looking for a place to share OpenStack-specific
> applications. There are definitely communities for PaaS layers (cloud
> foundry, mesosphere, docker, kubernetes), but I don't see any
> community for openstack-native applications that can be deployed on
> any cloud, nor a commonly accepted way to deploy them.
>
> > In the past we have retired projects that were dead upstream. The App
> > Catalog is not in this case: it has an active maintenance team, which
> > has been successfully maintaining the framework and accepting
> > applications. If we end up retiring the App Catalog, it would clearly
> > not be a reflection on that team performance, which has been stellar
> > despite limited resources. It would be because the beta was arguably not
> > successful in building an active marketplace of applications, and
> > because its continuous existence is not a great fit from a strategy
> > perspective. Such removal would be a first for our community, but I
> > think it's now time to consider it.
> >
> > Before we discuss or decide anything at the TC level, I'd like to
> > collect everyone thoughts (and questions) on this. Please feel free to
> > reply to this thread (or reach out to me privately if you prefer). Thanks !
>
> As the former PTL I am obviously a little bit biased. Even though my
> focus has shifted and I've stepped away from the app catalog, I had
> been spending a lot of time trying to figure out how to make
> applications an easy to run thing on OpenStack. I've also been trying
> to find a community of people who are looking for that, and it doesn't
> seem like they've materialized; possibly because that community
> doesn't exist? Or else we just haven't been able to figure out where
> they're hiding ;)
>
> The one consideration that is pretty important 

Re: [openstack-dev] [release][tripleo][fuel][kolla][ansible] Ocata Release countdown for R+2 Week, 6-10 March

[Doug Hellmann]

Excerpts from Vladimir Kuklin's message of 2017-03-08 01:20:21 +0300:
> Doug
> 
> I have proposed the change for Fuel RC2 [0], but it has W-1 set as I am
> waiting for the final tests result. If everything goes alright, I will
> check the Worfklow off and this RC2 can be the cut as the release.

I've approved the RC2 tag and prepared
https://review.openstack.org/443116 with the final release tag. Please
+1 if that looks OK. I will approve it tomorrow.

Doug

> 
> [0] https://review.openstack.org/#/c/442775/
> 
> On Tue, Mar 7, 2017 at 3:39 AM, Jeffrey Zhang 
> wrote:
> 
> > Sorry for late. But Kolla project need a new release candidate. I will
> > push it today.
> >
> > On Tue, Mar 7, 2017 at 6:27 AM, Doug Hellmann 
> > wrote:
> >
> >> Excerpts from Doug Hellmann's message of 2017-03-06 11:00:15 -0500:
> >> > Excerpts from Doug Hellmann's message of 2017-03-02 18:24:12 -0500:
> >> > >
> >> > > Release Tasks
> >> > > -
> >> > >
> >> > > Liaisons for cycle-trailing projects should prepare their final
> >> > > release candidate tags by Monday 6 March. The release team will
> >> > > prepare a patch showing the final release versions on Wednesday 7
> >> > > March, and PTLs and liaisons for affected projects should +1. We
> >> > > will then approve the final releases on Thursday 8 March.
> >> >
> >> > We have 13 cycle-trailing deliverables without final releases for Ocata.
> >> > All have at least one release candidate, so if no new release candidates
> >> > are proposed *today* I will prepare a patch using these versions as the
> >> > final and we will approve that early Wednesday.
> >> >
> >> > If you know that you need a new release candidate, please speak up now.
> >> >
> >> > If you know that you do not need a new release candidate, please also
> >> > let me know that.
> >> >
> >> > Thanks!
> >> > Doug
> >> >
> >> > $ list-deliverables --series ocata --missing-final -v
> >> > fuel   fuel 11.0.0.0rc1 other
> >>  cycle-trailing
> >> > instack-undercloud tripleo  6.0.0.0rc1 other
> >>cycle-trailing
> >> > kolla-ansible  kolla4.0.0.0rc1 other
> >>cycle-trailing
> >> > kolla  kolla4.0.0.0rc1 other
> >>cycle-trailing
> >> > openstack-ansible  OpenStackAnsible 15.0.0.0rc1 other
> >>  cycle-trailing
> >> > os-apply-configtripleo  6.0.0.0rc1 other
> >>cycle-with-milestones
> >> > os-cloud-configtripleo  6.0.0.0rc1 other
> >>cycle-with-milestones
> >> > os-collect-config  tripleo  6.0.0.0rc1 other
> >>cycle-with-milestones
> >> > os-net-config  tripleo  6.0.0.0rc1 other
> >>cycle-with-milestones
> >> > os-refresh-config  tripleo  6.0.0.0rc1 other
> >>cycle-with-milestones
> >> > tripleo-heat-templates tripleo  6.0.0.0rc1 other
> >>cycle-trailing
> >> > tripleo-image-elements tripleo  6.0.0.0rc1 other
> >>cycle-trailing
> >> > tripleo-puppet-elementstripleo  6.0.0.0rc1 other
> >>cycle-trailing
> >> >
> >>
> >> I have lined up patches with the final release tags for all 3 projects.
> >> Please review and +1 or propose a new patch with an updated release
> >> candidate.
> >>
> >> Ansible: https://review.openstack.org/442138
> >> Kolla: https://review.openstack.org/442137
> >> TripleO: https://review.openstack.org/442129
> >>
> >> Doug
> >>
> >> 
> >> __
> >> 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
> >>
> >
> >
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> > __
> > OpenStack Development Mailing 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] OpenStack client default ironic API version

[Dmitry Tantsur]

On 03/07/2017 04:59 PM, Loo, Ruby wrote:

On 2017-03-06, 3:46 PM, "Mario Villaplana"  wrote:

Hi ironic,

At the PTG, an issue regarding the default version of the ironic API
used in our python-openstackclient plugin was discussed. [0] In short,
the issue is that we default to a very old API version when the user
doesn't otherwise specify it. This limits discoverability of new
features and makes the client more difficult to use for deployments
running the latest version of the code.

We came to the following consensus:

1. For a deprecation period, we should log a warning whenever the user
doesn't specify an API version, informing them of this change.

2. After the deprecation period:

a) OSC baremetal plugin will default to the latest available version

I think OSC and ironic CLI have the same behaviour -- are we only interested in 
OSC or are we interested in both, except that we also want to at some point 
soon perhaps, deprecate ironic CLI?


I think we should only touch OSC, because of planned deprecation you mention.



Also, by 'latest available version', the OSC plugin knows (or thinks it knows) 
what the latest version is [1]. Will you be using that, or 'latest'?


It will pass "latest" to the API, so it may end up with a version the client 
side does not know about. This is intended, I think. It does have some 
consequences if we make breaking changes like removing parameters. As we're not 
overly keen on breaking changes anyway, this may not be a huge concern.




b) Specifying just macroversion will default to latest microversion
within that macroversion (example: --os-baremetal-api-version=1 would
default to 1.31 if 1.31 is the last microversion with 1 macroversion,
even if we have API 2.2 supported)

I have a patch up for review with the deprecation warning:
https://review.openstack.org/442153

Do you have an RFE? I'd like a spec for this too please.


Dunno if this change really requires a spec, but if you want one - let's have 
one :)

We should have an RFE anyway, obviously.



Please comment on that patch with any concerns.

We also still have yet to decide what a suitable deprecation period is
for this change, as far as I'm aware. Please respond to this email
with any suggestions on the deprecation period.

Thanks,
Mario


[0] https://etherpad.openstack.org/p/ironic-pike-ptg-operations L30

Thank YOU!

--ruby

[1] 
https://github.com/openstack/python-ironicclient/blob/f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L29

__
OpenStack Development Mailing 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] [acceleration] No team meeting today, resume next Wed

[Zhipeng Huang]

Hi team,

As agreed per our PTG/VTG session, we will have the team meeting two weeks
after to give people enough time to prepare the BPs we discussed.

Therefore there will be no team meeting today, and the next meeting is on
next Wed.
__
OpenStack Development Mailing 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][release][deployment] Packaging problems due to branch/release ordering

[Steven Hardy]

Hi all,

I wanted to raise visibility of a problem we're experiencing in TripleO CI,
which I think will potentially affect other projects that consume trunk
builds from the RDO repositories (and potentially other distros too I
guess)

The problem is that we tag our final ocata releases after branching
stable/ocata, but there is then a period prior to cutting pike-1 milestone
releases (or some other intermediate release for projects not following the
milestone model) where trunk package builds n-v-r is older than the stable
branches.

This presents a big problem if you want to test package-derived updates
from stable/$foo to master, as the pacakges don't get updated where the
installed stable one is newer than the one built from master.

I raised this bug initially thinking it was specific to the puppet-*
projects, but it seems from subsequent discussion that it's a broader issue
that may impact many OpenStack projects.

https://bugs.launchpad.net/tripleo/+bug/1669462

I'm not clear on the best path forward at this point, but the simplest one
suggested so far is to simply tag a new pre-milestone/alpha release for all
master branches, which will enable testing upgrades to master.

I know we don't expect to fully support upgrades to pre-milestone releases,
but the requirement here is to simply enable testing them.

A side-benefit of this regular testing e.g via CI is we'll find upgrade issues
much faster than waiting for one or more milestone releases to happen then
doing an upgrade-debug firedrill later in the cycle (which has been bad for
project and deployment teams IMO, so it'd be good to figure out this first
step to enable earlier testing of upgrades to the development release).

Any thoughts on how we can resolve this would be much appreciated, thanks!

Steve

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

Re: [openstack-dev] [kolla] Proposing duonghq for core

[Mauricio Lima]

+1

2017-03-08 7:34 GMT-03:00 Christian Berendt 
:

> +1
>
> > On 8 Mar 2017, at 07:41, Michał Jastrzębski  wrote:
> >
> > Hello,
> >
> > I'd like to start voting to include Duong (duonghq) in Kolla and
> > Kolla-ansible core teams. Voting will be open for 2 weeks (ends at
> > 21st of March).
> >
> > Consider this my +1 vote.
> >
> > Cheers,
> > Michal
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Mail: bere...@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>
>
> __
> OpenStack Development Mailing 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] Question to clarify versioned notifications

[Balazs Gibizer]

On Tue, Mar 7, 2017 at 8:42 PM, Matt Riedemann  
wrote:
While digging through nova code today to compare versioned and 
unversioned notifications, and reading specs and seeing how 
seachlight handles nova notifications, I noticed that the unversioned 
notifications have a "compute." prefix in the name. The versioned 
notifications do not.


It also took me awhile but I also sorted out that unversioned 
notifications are on the 'notifications' topic which is the default 
in oslo.messaging ([oslo_messaging_notifications]topics) and 
versioned notifications are on the 'versioned_notifications' topic.


Yes, versioned notifications are always emitted to the 
'versioned_notifications' topic. Sorry if that wasn't clear from the 
notification dev-ref. The actual code is here [5]





My question is, was it intentional to drop the "compute." prefix from 
the event type on the versioned notifications? I didn't see anything 
specifically stating that in the original spec [1].


Quote from the spec [1]:
The value of the event_type field of the envelope on the wire will be 
defined by the name of the affected object, the name of the performed 
action emitting the notification and the phase of the action. For 
example: instance.create.end, aggregate.removehost.start, 
filterscheduler.select_destinations.end. The notification model will do 
basic validation on the content of the event_type e.g. enum for valid 
phases will be created.


So yes, dropping the compute prefix was intentional as the information 
carried by the prefix was already in the publisher_id of the 
notification.


The goal was that the publisher_id should define what service emitted 
the notifications and the event_type should be a unique id of the given 
event regardless of which service emits that event. For example the 
event_type instance.delete.start is used by nova-compute and 
nova-conductor service. The publisher_id will contain the name of the 
service binary and the hostname where that binary runs[3][4]


[3] 
https://review.openstack.org/#/c/410297/12/doc/notification_samples/instance-delete-start_not_scheduled.json@59[4] 
https://github.com/openstack/nova/blob/master/doc/notification_samples/instance-delete-start.json#L72

[5] https://github.com/openstack/nova/blob/master/nova/rpc.py#L92-L99




Since the notifications are on independent topics it probably doesn't 
matter. I was just thinking about this from the searchlight 
perspective because they don't support nova versioned notifications 
yet and already have code to map the "compute." event types [2], I 
wasn't sure if they could re-use that and just listen on the 
'versioned_notifications' topic. In talking with Steve McLellan it 
doesn't sound like the different event types format will be an issue.


Honestly, If searchlight needs to be adapted to the versioned 
notifications then the smallest thing to change is to handle the 
removed prefix from the event_type. The biggest difference is the 
format and the content of the payload. In the legacy notifications the 
payload was a simply json dict in the versioned notification the 
payload is a json serialized ovo. Which means quite a different data 
structure. E.g. extra keys, deeper nesting, etc.


Cheers,
gibi




[1] 
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/versioned-notification-api.html
[2] 
https://github.com/openstack/searchlight/blob/2.0.0/searchlight/elasticsearch/plugins/nova/notification_handler.py#L82


--

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



__
OpenStack Development Mailing 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] Proposing duonghq for core

[Paul Bourke]

+1

On 08/03/17 08:29, Jeffrey Zhang wrote:

+1 from me

On Wed, Mar 8, 2017 at 2:41 PM, Michał Jastrzębski > wrote:

Hello,

I'd like to start voting to include Duong (duonghq) in Kolla and
Kolla-ansible core teams. Voting will be open for 2 weeks (ends at
21st of March).

Consider this my +1 vote.

Cheers,
Michal

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

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





--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me 


__
OpenStack Development Mailing 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] [horizon] Horizon Weekly IRC Meeting

[Rob Cresswell]

Hey everyone,

Reminder that the weekly IRC meeting is 2000 UTC on Wednesday (about 10.5 hours 
from sending this email) in #openstack-meeting-3. Anyone is welcome to add to 
the agenda at https://wiki.openstack.org/wiki/Meetings/Horizon

Previous logs, ICS files, and other info can be found at 
http://eavesdrop.openstack.org/#Horizon_Team_Meeting

Rob
__
OpenStack Development Mailing 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][Heat] Selectively disabling deployment resources

[Steven Hardy]

On Tue, Mar 07, 2017 at 02:34:50PM -0500, James Slagle wrote:
> I've been working on this spec for TripleO:
> https://review.openstack.org/#/c/431745/
>
> which allows users to selectively disable Heat deployment resources
> for a given server (or server in the case of a *DeloymentGroup
> resource).
> 
> Some of the main use cases in TripleO for such a feature are scaling
> out compute nodes where you do not need to rerun Puppet (or make any
> changes at all) on non-compute nodes, or to exclude nodes from hanging
> a stack-update if you know they are unreachable or degraded for some
> reason. There are others, but those are 2 of the major use cases.

Thanks for raising this, I know it's been a pain point for some users of
TripleO.

However I think we're conflating two different issues here:

1. Don't re-run puppet (or yum update) when no other changes have happened

2. Disable deployment resources when changes have happened

(1) is actually very simple, and is the default behavior of Heat
(SoftwareDeployment resources never update unless either the config
referenced or the input_values change).  We just need to provide an option
to disable the DeployIdentifier/UpdateIdentifier timestamps from being
generated in tripleoclient.

(2) is harder, because the whole point of SoftwareDeploymentGroup is to run
the exact same configuration on a group of servers, with no exceptions.

As Zane mentions (2) is related to the way ResourceGroup works, but the
problem here isn't ResourceGroup per-se, as it would in theory be pretty
easy to reimplement SoftwareDeploymentGroup to generate it's nested stack
without inheriting from ResourceGroup (which may be needed if you want a
flag to make existing Deployments in the group immutable).

I'd suggest we solve (1) and do some testing, it may be enough to solve the
"don't change computes on scale-out" case at least?

One way to potentially solve (2) would be to unroll the
SoftwareDeploymentGroup resources and instead generate the Deployment
resources via jinja2 - this would enable completely removing them on update
if that's what is desired, similar to what we already do for upgrades to
e.g not upgrade any compute nodes.

Steve

> 
> I started by taking an approach that would be specific to TripleO.
> Basically mapping all the deployment resources to a nested stack
> containing the logic to selectively disable servers from the
> deployment (using yaql) based on a provided parameter value. Here's
> the main patch: https://review.openstack.org/#/c/442681/
> 
> After considering that complexity, particularly the yaql expression,
> I'm wondering if it would be better to add this support natively to
> Heat.
> 
> I was looking at the restricted_actions key in the resource_registry
> and was thinking this might be a reasonable place to add such support.
> It would require some changes to how restricted_actions work.
> 
> One change would be a method for specifying that restricted_actions
> should not fail the stack operation if an action would have otherwise
> been triggered. Currently the behavior is to raise an exception and
> mark the stack failed if an action needs to be taken but has been
> marked restricted. That would need to be tweaked to allow specifying
> that that we don't want the stack to fail. One thought would be to
> change the allowed values of restricted_actions to:
> 
> replace_fail
> replace_ignore
> update_fail
> update_ignore
> replace
> update
> 
> where replace and update were synonyms for replace_fail/update_fail to
> maintain backwards compatibility.
> 
> Another change would be to add logic to the Deployment resources
> themselves to consider if any restricted_actions have been set on an
> Server resources before triggering an updated deployment for a given
> server.
> 
> It also might be nice to allow specifying restricted_actions on the
> server's name property (which typically is the hostname) instead of
> having to use the resource name. The reason being is that it is not
> really feasibly to expect operators/users to have to represent the
> full nested_stack structure in their resource_registry. They would
> have to query and record nested_stack names just to refer to a given
> server resource. Each ResourceGroup nested stack would be have to be
> individually represented, etc. Unless there is another way I'm
> overlooking.
> 
> Whether or not the restricted_actions approach is taken, is Heat
> interested in this functionality natively? I think it would make for a
> much cleaner implementation than something TripleO specific. I can
> work on a Heat spec if there's interest, though I'd like to get some
> early feedback.
> 
> Thanks.
> 
> -- 
> -- James Slagle
> --
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Re: [openstack-dev] [oslo_reports]Does GMR work for uwsgi mode service?

[hao wang]

Hi, Roman

Thank you very much!  It works well when I used file handle event to
trigger a generation of a report instead of signals.

Thanks again,
Wang Hao

2017-03-07 18:56 GMT+08:00 Roman Podoliaka :
> Hi,
>
> My understanding is that it's not recommended for WSGI apps to set up
> custom signal handlers. The reason for that is that a WSGI server
> (i.e. uwsgi in your case or Apache+mod_wsgi) will most likely have its
> own handlers for the very same set of signals [1].
>
> There is an alternative way to trigger a generation of a report by
> changing a file modification date [2].
>
> Thanks,
> Roman
>
> [1] 
> https://code.google.com/archive/p/modwsgi/wikis/ConfigurationDirectives.wiki#WSGIRestrictSignal
> [2] https://review.openstack.org/#/c/260976/
>
> On Tue, Mar 7, 2017 at 8:02 AM, hao wang  wrote:
>> Hi, stackers,
>>
>> I'm trying to use Guru Meditation Report in Zaqar project which can
>> support uwsgi server.  I imported gmr and used
>> "gmr.TextGuruMeditation.setup_autorun(version, conf=conf)",  but it
>> didn't work under uwsgi mode.
>>
>> Did I do something wrong,  or  GMR doesn't support uwsgi mode yet?
>>
>> Thanks for your help!
>>
>> Wang Hao
>>
>> __
>> OpenStack Development Mailing 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] [kolla] Proposing duonghq for core

[Jeffrey Zhang]

+1 from me

On Wed, Mar 8, 2017 at 2:41 PM, Michał Jastrzębski  wrote:

> Hello,
>
> I'd like to start voting to include Duong (duonghq) in Kolla and
> Kolla-ansible core teams. Voting will be open for 2 weeks (ends at
> 21st of March).
>
> Consider this my +1 vote.
>
> Cheers,
> Michal
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing 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] [tricircle]weekly meeting of Mar. 8

[joehuang]

Hello, team,

Attention please, the new weekly meeting time slot is UTC 14:00~UTC 15:00

Agenda of Mar.8 weekly meeting:

  1.  Pike-1 feature priority discussion
  2.  Pike features development
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 14:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.


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

Re: [openstack-dev] [tc][appcat][murano][app-catalog] The future of the App Catalog

[Adam Heczko]

Personally I tend to agree with Christopher's POV. IMO the OpenStack
community and TC could and should make a progress in perception how to make
OpenStack more 'consumable' and useful for a broader audience. And IMO
AppCatalog falls into this direction of making OpenStack more consumable
and useful. Rather than retiring AppCatalog let's discuss how to improve
it, try to figure out what's missing if anything etc.
Also please note that Murano is solving much deeper (wider?) problem than
Docker app deployment. Murano is more similar to what the Helm is to
Kubernetes [1]. Murano offers advanced application and infrastructure
integration capabilities.

[1] https://github.com/kubernetes/helm

On Wed, Mar 8, 2017 at 5:09 AM, Christopher Aedo  wrote:

> On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez 
> wrote:
> > Hello everyone,
> >
> > The App Catalog was created early 2015 as a marketplace of pre-packaged
> > applications that you can deploy using Murano. Initially a demo by
> > Mirantis, it was converted into an open upstream project team, and
> > deployed as a "beta" as apps.openstack.org.
> >
> > Since then it grew additional categories (Glance images, Heat & Tosca
> > templates), but otherwise did not pick up a lot of steam. The website
> > (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
> > heat templates and 94 murano packages (~30% of which are just thin
> > wrappers around Docker containers). Traffic stats show around 100 visits
> > per week, 75% of which only read the index page.
> >
> > In parallel, Docker developed a pretty successful containerized
> > application marketplace (the Docker Hub), with hundreds of thousands of
> > regularly-updated apps. Keeping the App Catalog around (including its
> > thinly-wrapped Docker container Murano packages) make us look like we
> > are unsuccessfully trying to compete with that ecosystem, while
> > OpenStack is in fact completely complementary.
>
> Without something like Murano "thinly wrapping" docker apps, how would
> you propose current users of OpenStack clouds deploy docker apps?  Or
> any other app for that matter?  It seems a little unfair to talk about
> murano apps this way when no reasonable alternative exists for easily
> deploying docker apps.  When I look back at the recent history of how
> we've handled containers (nova-docker, magnum, kubernetes, etc) it
> does not seem like we're making it easy for the folks who want to
> deploy a container on their cloud...
>
> Please understand I am not pleading to keep the Community App Catalog
> alive in perpetuity.  This just sounds like an unfair point of
> comparison.  One of the biggest challenges we've faced with the app
> catalog since day one is that there is no such thing as a simple
> definition of an "OpenStack Application".  OpenStack is an IaaS before
> anything else, and to my knowledge there is no universally accepted
> application deployment mechanism for OpenStack clouds.  Heat doesn't
> solve that problem as its very operator focused, and while being very
> popular and used heavily, it's not used as a way to share generic
> templates suitable for deploying apps across different clouds.  Murano
> is not widely adopted (last time I checked it's not available on any
> public clouds, though I hear it is actually used on a several
> university clouds, and it's also used on a few private clouds I'm
> aware of.)
>
> As a place to find things that run on OpenStack clouds, the app
> catalog did a reasonable job.  If anything, the experiment showed that
> there is no community looking for a place to share OpenStack-specific
> applications.  There are definitely communities for PaaS layers (cloud
> foundry, mesosphere, docker, kubernetes), but I don't see any
> community for openstack-native applications that can be deployed on
> any cloud, nor a commonly accepted way to deploy them.
>
> > In the past we have retired projects that were dead upstream. The App
> > Catalog is not in this case: it has an active maintenance team, which
> > has been successfully maintaining the framework and accepting
> > applications. If we end up retiring the App Catalog, it would clearly
> > not be a reflection on that team performance, which has been stellar
> > despite limited resources. It would be because the beta was arguably not
> > successful in building an active marketplace of applications, and
> > because its continuous existence is not a great fit from a strategy
> > perspective. Such removal would be a first for our community, but I
> > think it's now time to consider it.
> >
> > Before we discuss or decide anything at the TC level, I'd like to
> > collect everyone thoughts (and questions) on this. Please feel free to
> > reply to this thread (or reach out to me privately if you prefer).
> Thanks !
>
> As the former PTL I am obviously a little bit biased.  Even though my
> focus has shifted and I've stepped away from the app catalog, I had
> been