[openstack-dev] [searchlight] No Searchlight IRC meeting today

[Zhenyu Zheng]

Hi everyone,

As Travis sent out last week, most of the contributor will be on holiday
this week and the next, so we decide not to hold the Searchlight IRC
meeting today.

The only remaining topic from last meeting was the pipeline patch:
https://review.openstack.org/#/c/359972/

We have discussed in the Searchlight IRC channel and lei-zh will update the
patch according to the current comments, and we will help review it when it
gets update and hopefully we can have it in in few weeks.

Thanks, Merry Christmas and Happy New Year.

Kevin Zheng
__
OpenStack Development Mailing 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] FW: FW: No Relevant flows in br-int after SFC Creation

[Mohan Kumar]

Hi Anirudh,

Please share q-svc.log

Thanks.,
Mohankumar.N

On Thu, Dec 22, 2016 at 10:21 AM, Anirudh Gupta 
wrote:

> Hi Mohan,
>
>
>
> Thanks a lot for your help and support on IRC yesterday.
>
>
>
> As per your suggestion, we have upgraded our OVS version to 2.5.0,
> downloaded older version of networking-sfc (stable/mitaka).
>
> We have also changed the default driver to *default=['ovs']*  in the
> following files :-
>
>
>
> · networking_sfc/services/flowclassifier/common/config.py
>
> · networking_sfc/services/sfc/common/config.py
>
>
>
> We have removed the dummy section from the file
>
>
>
> · /opt/stack/networking-sfc/setup.cfg
>
>
>
> and run the command *sudo python setup.py install* in the networking-sfc.
>
>
>
> But still after creating Flow-Classifier, we could see the driver as *dummy
> *in q-svc  logs.
>
>
>
> *2016-12-22 15:29:00.684 ^[[00;32mDEBUG
> networking_sfc.services.flowclassifier.drivers.dummy.dummy
> [^[[01;36mreq-a634ebc4-7f65-4f46-acf0-0a3135c57237 ^[[00;36madmin
> 2ef781adeee54ee38354452b8264ed08^[[00;32m]
> ^[[01;35m^[[00;32mnetworking_sfc.services.flowclassifier.drivers.dummy.dummy.DummyDriver
> method create_flow_classifier called with arguments
> ( object at 0x7fcc69ec6590>,) {}^[[00m ^[[00;33mfrom (pid=21226) wrapper
> /usr/local/lib/python2.7/dist-packages/oslo_log/helpers.py:47^[[00m*
>
>
>
> Can you please suggest what more steps we need to follow in order to use
> ovs driver in networking-sfc?
>
>
>
> Regards
>
> Anirudh Gupta
>
>
>
>
>
> *From:* Mohan Kumar [mailto:nmohankumar1...@gmail.com]
> *Sent:* Friday, December 16, 2016 6:53 PM
> *To:* Anirudh Gupta 
> *Cc:* openstack-dev@lists.openstack.org; Lovelesh Pandya <
> lovelesh.pan...@aricent.com>; Mohit Gupta 
> *Subject:* Re: FW: FW: No Relevant flows in br-int after SFC Creation
>
>
>
> Hi Anirudh,
>
>
>
> Please try  out the suggestion as per our IRC chat  and post your
> experience
>
>
>
> Thanks.,
>
> Mohankumar.N
>
>
>
>
>
>
>
>
>
> On Thu, Dec 15, 2016 at 3:56 PM, Anirudh Gupta 
> wrote:
>
> Hi Mohan,
>
>
>
> Yes, we are getting timeout messages in q-agt logs.
>
>
>
> We have suspecting some communication issue between Driver and the Agent.
>
>
>
> Setup Details :-
>
>
>
> *· Openstack Newton - Devstack*
>
> *· Kernel version - 3.19.0-25-generic*
>
> *· ovs version – 2.4.0*
>
>
>
> After creating the Port chain, it was found that no relevant flows were
> added in br-int (attached in the mail).
>
>
>
> On Analysing, it was found in *q-svc logs*, that the driver is asking
> agent to update the flows.
>
>
>
> *2016-12-13 21:59:45.190 2293 DEBUG
> networking_sfc.services.sfc.drivers.ovs.driver
> [req-12ff22b4-e672-4c0a-84f1-ac50286ecfb5 admin -] create assoc port with
> node: {'portpair_id': u'960b7bed-971d-48ed-804c-cfdb1ff7d73b',
> 'pathnode_id': '426067de-40aa-431e-a23e-02587f2ac43e', 'weight': 1}
> _create_portchain_path
> /opt/stack/networking-sfc/networking_sfc/services/sfc/drivers/ovs/driver.py:454*
>
> *2016-12-13 21:59:45.206 2293 DEBUG networking_sfc.db.flowclassifier_db
> [req-12ff22b4-e672-4c0a-84f1-ac50286ecfb5 admin -]
> networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin method
> get_flow_classifier called with arguments ( at 0x7f4afaf4e290>, u'598c91d8-581d-4f14-9653-50767bb25d40') {} wrapper
> /usr/local/lib/python2.7/dist-packages/oslo_log/helpers.py:47*
>
> *2016-12-13 21:59:45.424 2293 DEBUG
> networking_sfc.services.sfc.drivers.ovs.rpc
> [req-12ff22b4-e672-4c0a-84f1-ac50286ecfb5 admin -] Ask agent on the
> specific host to update flows  ask_agent_to_update_flow_rules
> /opt/stack/networking-sfc/networking_sfc/services/sfc/drivers/ovs/rpc.py:60*
>
>
>
>
>
> But in *q-agt*, there are no flows were added and also there are some
> timeout logs.
>
>
>
> *2016-12-13 22:04:49.513 2486 ERROR neutron.common.rpc
> [req-f9c98709-0a3e-42ea-8437-b821adeff86d - -] Timeout in RPC method
> get_devices_details_list_and_failed_devices. Waiting for 33 seconds before
> next attempt. If the server is not down, consider increasing the
> rpc_response_timeout option as Neutron server(s) may be overloaded and
> unable to respond quickly enough.*
>
>
>
> It seems the request is not reaching the agent over rpc.
>
>
>
> PFA the following :-
>
> · q-agt logs
>
> · q-svc logs
>
> · nova.conf
>
> · Br-int flows
>
> · Dhcp agent
>
> · L3 agent
>
> · Local.conf
>
> · Ml2 conf
>
>
>
> Can you suggest if any configuration needs to be changed to resolve the
> issue?
>
>
>
> Regards
>
> Anirudh
>
>
>
> *From:* Mohan Kumar [mailto:nmohankumar1...@gmail.com]
> *Sent:* Wednesday, December 14, 2016 10:17 PM
> *To:* Anirudh Gupta 
> *Cc:* openstack-dev@lists.openstack.org; Lovelesh Pandya <
> lovelesh.pan...@aricent.com>; Mohit Gupta 
> *Subject:* 

[OpenStack-Infra] 答复: Re: [openstack-infra] how to config gerrit to get a summary of all jobs in gerrit page

[dong . wenjuan]

Hi all,

Thanks for your help. I'll try it.

BR,
dwj






Joshua Hesketh  
2016-12-21 19:29

收件人
dong.wenj...@zte.com.cn
抄送
openstack-infra 
主题
Re: [OpenStack-Infra] [openstack-infra] how to config gerrit to get a 
summary of all jobs in gerrit page






Hey,

We run some javascript that parses the comments in gerrit and pulls out 
the the results into a table as a summary:
http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/files/gerrit/hideci.js


This is loaded in by supplying the gerrit header:
http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/files/gerrit/GerritSiteHeader.html


Hope that helps!

Cheers,
Josh

On Wed, Dec 21, 2016 at 6:49 PM,  wrote:

Hi all, 

I setup a CI system, but after all the jobs run, the summary of all jobs 
don't show in gerrit page. 
Like this: 


Does anybody know how to config it? Thanks~ 



BR, 
dwj



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


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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Zhenyu Zheng]

Agreed with Amrith, it might be useful and maybe also good for new
contributors to learn how to have a commit to OpenStack. BUT over 130
identical patches to 130 different projects from one company/person in one
run? I don't think this is going to help OpenStack growing. We should not
let this happen.

On Thu, Dec 22, 2016 at 12:44 AM, Amrith Kumar  wrote:

> For those who would like to know exactly what this set of changes cost in
> the CI, the answer is approximately 1050 jobs which consumed 190 compute
> hours of CI time.
>
> -amrith
>
> -Original Message-
> From: Amrith Kumar [mailto:amr...@tesora.com]
> Sent: Wednesday, December 21, 2016 11:13 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to
> projects
>
> Ian, Andreas, Emilien,
>
> My sentiments on the subject of these kinds of "production line" changes
> is unchanged from [1] and [2]. A complete list of these changes is at [3].
>
> I've updated all of the changes in this thread with a block comment and a
> -1. My apologies to other reviewers (and active contributors in those
> projects) for this automated comment across 131 commits.
>
> It is high time we eliminated these kinds of changes which do little to
> improve the overall quality of the product and serve merely to generate a
> huge amount of pointless work on the CI systems, and boost some meaningless
> statistics that someone wants to put on a slide someplace.
>
> -amrith
>
> [1] http://openstack.markmail.org/thread/dsuxy2sxxudfbij4
> [2] http://openstack.markmail.org/thread/3sr5c2u7fhpzanit
> [3] https://review.openstack.org/#/q/topic:addCONTRIBUTING.rst
>
> -Original Message-
> From: Andreas Jaeger [mailto:a...@suse.com]
> Sent: Wednesday, December 21, 2016 10:47 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to
> projects
>
> On 2016-12-21 16:22, Ian Cordasco wrote:
> > [...]
> > That said, I think there are two better places for this information
> > that are already standards in OpenStack:
> >
> > * README.rst
> > * HACKING.rst
> >
> > Most projects include links to the contributing documentation in at
> > least one of these files. I think the effort here is to standardize,
> > albeit in a brand new file, and that's admirable.
>
> If that's the goal - to standardize - then I would expect that we move all
> the documentation out of those files in one place.
>
> Right now, the changes duplicate information that exists - and the new
> information is often wrong. It points to place that do not exist or where
> better places exist. ;(
>
>
> I'm fine with the status quo - of using the two files that you mention.
> Having contribution information is important,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing 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] Performance issue on single physical host

[Vikram Chhibber]

Hi,

I was able to resolve the performance related issue by changing the cpu
allocation ratio from 16 to lower value.

Thanks

On Tue, Dec 20, 2016 at 6:09 PM, Vikram Chhibber 
wrote:

> Thanks Konstantin.
> This does not look like any specific issue with the boot of the instance.
> The issue is that overall system gets slow as multiple instances are
> running.
> Since this is nested virtualization, I also checked the kvm acceleration
> in the first leve VM which looks ok to me.
>
> The strange thing is that there are too many interrupts of type
> "Rescheduling interrupts".
>
> If I bring up one instance, things are fast and here is the vmstat:
> r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id
> wa st
>
> 1  1  0 2714652 270040 65698000 032  514  825  0 16 80
>  4  0
>
> 3  0  0 2714652 270040 65698000 032  573  904  1 20 76
>  3  0
>
> 0  0  0 2713908 270044 65699600 032  526  829  1 15 80
>  2  1
>
> 0  0  0 2713940 270044 65699600 032  478  795  1 11 85
>  3  0
>
>
> vmstat when two instances are running.
>
> r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id
> wa st
>
> 3  1  0 2715332 269700 65612800 056  504  779  3 32 64
>  1  0
>
> 4  0  0 2715704 269700 65612800 048  536  801  4 34 57
>  5  0
>
> 2  0  0 2715752 269700 65612800 036  554  920  3 34 58
>  6  0
>
> 21  2  0 2713700 269708 65612400 0   176  601  837 11 39
> 44  5  1
>
>
> Thanks
>
>
>
>
> On Mon, Dec 19, 2016 at 1:58 AM, Kostyantyn Volenbovskyi <
> volenbov...@yandex.ru> wrote:
>
>> Hi,
>>
>> a few thoughts:
>> -analyze what exactly time is spent on using Nova logs
>> (api+scheduler+conductor+compute)+Neutron (agent, bind port
>> stuff)+Libvirt/QEMU logs. Use req-id and UUID of instance to identify the
>> ’slow’ case across logs.
>> Take a look at the create instance’ flow that is present in bunch of
>> websites in internet and make a draft of distribution of time for each stage
>> (side note: maybe there is tool that will allow such thing?). Turn on
>> debug logging in Nova and Neutron to narrow it down in case necessary .
>> -compare CPU/RAM consumption in normal case and ‘slow’ case’
>>
>> How do I bound my vCPU all the way to the physical host?
>>
>> Answer is CPU pinning. But yup, that is about CPU utilization on host ,
>> not related to time of VM launch.
>> Note that for general-purpose case CPU pinning can be an overkill in a
>> way that general-purpose relies
>> on scheduling by host OS and it should not be problematic. And most
>> configurations run with oversubscription of CPU 16 which is default (1
>> physical CPU=16 virtual)
>> 'Specific purpose' cases are like NFV/Telco where CPU pinning is
>> much-much more used.
>>
>> BR,
>> Konstantin
>>
>>
>> On Dec 19, 2016, at 5:27 AM, Vikram Chhibber 
>> wrote:
>>
>> Hi All,
>>
>> I am using Kilo release 1:2015.1.4-0ubuntu2 for my lab deployment on
>> single physical host. The issue is that I am getting very low performance
>> when I launch multiple VM instances. The first one boots up within seconds
>> but the second takes noticeable time. If I instantiate the third instance
>> when two instances are already running, it may take 30 minutes to come up.
>> Moreover, the CPU idle % for a given instance keeps decreasing as number of
>> running instances increase.
>> I am suspecting that this behavior is because be lack of bounding of
>> vCPUs with physical CPUs.
>> Because of single node installation, the compute node itself becomes
>> virtualized and run my instances within it. How do I bound my vCPU all the
>> way to the physical host? I did not see any documentation regarding this
>> for Kilo release and there is no mention of bounding CPU for the
>> virtualized compute node on single node installation.
>>
>> This is the specification of the host:
>> Architecture:  x86_64
>> CPU op-mode(s):32-bit, 64-bita
>> Byte Order:Little Endian
>> CPU(s):36
>> On-line CPU(s) list:   0-35
>> Thread(s) per core:2
>> Core(s) per socket:18
>> Socket(s): 1
>> NUMA node(s):  1
>> Vendor ID: GenuineIntel
>> CPU family:6
>> Model: 63
>> Stepping:  2
>> CPU MHz:   1200.000
>> BogoMIPS:  4599.94
>> Virtualization:VT-x
>> L1d cache: 32K
>> L1i cache: 32K
>> L2 cache:  256K
>> L3 cache:  46080K
>> NUMA node0 CPU(s): 0-35
>>
>>
>> Spec. for the compute node:
>> Architecture:  x86_64
>> CPU op-mode(s):32-bit, 64-bit
>> Byte Order:Little Endian
>> CPU(s):26
>> On-line CPU(s) list:   0-25
>> Thread(s) per core:1
>> Core(s) per socket:1
>> Socket(s): 26
>> NUMA node(s):  1
>> 

Re: [Openstack] (no subject)

[Atif Munir]

Thanks everyone for reply.

The problem got resolved by adding

SESSION_ENGINE = 'django.contrib.sessions.backends.cache'

in
the /usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py
file.and I was able to launch my first Instance.


This is really a great product and a game changer for the next 5-10 years.


Regards,
Atif



On Wed, Dec 21, 2016 at 7:37 PM, Jose Manuel Ferrer Mosteiro <
jmferrer.paradigmatecnolog...@gmail.com> wrote:

> Double check you have closed all ' and " in vars you changed.
>
> Maybe the problem could en in values of OPENSTACK_KEYSTONE_DEFAULT_DOMAIN,
> CACHES['default']['LOCATION'], OPENSTACK_HOST or TIME_ZONE ?
>
> You can use meld to compare original configuration file and your
> configuration file.
>
> Regards,
>   Jose Manuel
>
>
>
>
> El 2016-12-21 12:57, Neil Jerram escribió:
>
> Hi Atif,
>
> There is incorrect Python indentation in the local_settings file,
> /usr/share/openstack-dashboard/openstack_dashboard/
> local/local_settings.py.
>
> From the perspective of the vanilla Horizon project, I believe
> local_settings.py is a file that the user can create and/or modify in order
> to influence how their own web UI looks.  So it could be that you created
> that file yourself, or it could be that it was created by the install
> method that you are using.
>
> But either way, you can just open the file yourself and see if you can see
> and fix the indentation problem.
>
> Regards,
> Neil
>
>
> On Wed, Dec 21, 2016 at 11:45 AM Atif Munir  wrote:
>
>>
>> After successful installation of openstack. I am getting this error while
>> I was going to open http://controller/horizon. The error message is for
>> Apache2 erro logs. Please advise. Thanks
>>
>> Atif
>>
>>
>> [Wed Dec 21 16:30:36.170646 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754] mod_wsgi (pid=5302): Target
>> WSGI script 
>> '/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi'
>> cannot be loaded as Python module.
>> [Wed Dec 21 16:30:36.170708 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754] mod_wsgi (pid=5302):
>> Exception occurred processing WSGI script '/usr/share/openstack-
>> dashboard/openstack_dashboard/wsgi/django.wsgi'.
>> [Wed Dec 21 16:30:36.170734 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754] Traceback (most recent call
>> last):
>> [Wed Dec 21 16:30:36.170757 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754]   File "/usr/share/openstack-
>> dashboard/openstack_dashboard/wsgi/django.wsgi", line 16, in 
>> [Wed Dec 21 16:30:36.170790 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754] application =
>> get_wsgi_application()
>> [Wed Dec 21 16:30:36.170803 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754]   File
>> "/usr/lib/python2.7/dist-packages/django/core/wsgi.py", line 14, in
>> get_wsgi_application
>> [Wed Dec 21 16:30:36.170820 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754] django.setup()
>> [Wed Dec 21 16:30:36.170830 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754]   File
>> "/usr/lib/python2.7/dist-packages/django/__init__.py", line 17, in setup
>> [Wed Dec 21 16:30:36.170844 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754]
>> configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
>> [Wed Dec 21 16:30:36.170853 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754]   File
>> "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in
>> __getattr__
>> [Wed Dec 21 16:30:36.170868 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754] self._setup(name)
>> [Wed Dec 21 16:30:36.170894 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754]   File
>> "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in
>> _setup
>> [Wed Dec 21 16:30:36.170910 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754] self._wrapped =
>> Settings(settings_module)
>> [Wed Dec 21 16:30:36.170920 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754]   File
>> "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 92, in
>> __init__
>> [Wed Dec 21 16:30:36.170933 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754] mod =
>> importlib.import_module(self.SETTINGS_MODULE)
>> [Wed Dec 21 16:30:36.170943 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754]   File
>> "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
>> [Wed Dec 21 16:30:36.170957 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 172.16.72.2:40754] __import__(name)
>> [Wed Dec 21 16:30:36.170973 2016] [wsgi:error] [pid 5302:tid
>> 140489127257856] [remote 

Re: [openstack-dev] [Neutron][networking-*] Attention for upcoming refactoring

[Russell Bryant]

On Wed, Dec 21, 2016 at 10:50 AM, Anna Taraday 
wrote:

> Hello everyone!
>
> I've got two changes with refactor of TypeDriver [1] and segments db [2]
> which is needed for implementation new engine facade [3].
>
> Reviewers of networking-cisco, networking-arista, networking-nec
> 
> , networking-midonet
> 
> , networking-edge-vpn, networking-bagpipe, tricircle, group-based-policy -
> pay attention for [4].
>
> Also recently merged refactor of ml2/db.py [5]. Fixes
> for networking-cisco, networking-cisco, networking-cisco - are on review
> [6]
>
> [1] - https://review.openstack.org/#/c/398873/
> [2] - https://review.openstack.org/#/c/406275/
> [3] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
> [4] - https://review.openstack.org/#/q/topic:segmentsdb
> [5] - https://review.openstack.org/#/c/404714/
> [6] - https://review.openstack.org/#/q/status:open++branch:
> master+topic:refactor_ml2db
>

​Thanks a lot for looking out for the various networking-* projects when
working on changes like this.  It's really great to see.

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

Re: [openstack-dev] Retire the radar project?

[Anita Kuno]

On 2016-12-21 07:02 PM, Michael Still wrote:

Hi,

radar was an antique effort to import some outside-OpenStack code that did
CI reliability dashboarding. It was never really a thing, and has been
abandoned over time.

The last commit that wasn't part of a project wide change series was in
January 2015.

Does anyone object to me following the project removal steps described at
http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

Thanks,
Michael


I have no objection.

Thanks for agreeing to put your code into gerrit in a repo in the first 
place, I appreciate it.


Sorry it never got any attention, time to let it be but a legend.

Thanks Michael,
Anita.


__
OpenStack Development Mailing 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] [Congress] no meeting on December 29, 2016

[Eric K]

No congress team meeting on December 29, 2016. Regular meeting resumes on
January 5, 2016.

Happy holidays all!



__
OpenStack Development Mailing 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] Retire the radar project?

[Michael Still]

Hi,

radar was an antique effort to import some outside-OpenStack code that did
CI reliability dashboarding. It was never really a thing, and has been
abandoned over time.

The last commit that wasn't part of a project wide change series was in
January 2015.

Does anyone object to me following the project removal steps described at
http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

Thanks,
Michael

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

Re: [openstack-dev] [keystone] office hours starting January 6th

[Rodrigo Duarte]

Thanks for the initiative! This is something that both keystone and the
community will benefit! :)

On Wed, Dec 21, 2016 at 4:22 PM, Steve Martinelli 
wrote:

> Thanks for setting this up Lance!
>
> You can count on me to join and smash some bugs.
>
> On Wed, Dec 21, 2016 at 1:06 PM, Lance Bragstad 
> wrote:
>
>> Hi folks!
>>
>> If you remember, last year we started a weekly bug day [0]. The idea was
>> to dedicate one day a week to managing keystone's bug queue by triaging,
>> fixing, and reviewing bugs. This was otherwise known as keystone's office
>> hours.
>>
>> I'd like to remind everyone that we are starting up this initiative
>> again, right after the New Year. Our first bug day this year will be
>> Friday, January 6th, and it will be recurring every Friday after that.
>>
>> Previously, we used the etherpad [1] to track the status of patches and
>> bugs through the day. This time around, I'd like to see if we can keep
>> state out of the etherpad in favor of Gerrit dashboards and IRC (which are
>> easier to log and track). The etherpad now consists of information about
>> the event, which should eventually be moved into a wiki somewhere.
>>
>> I wanted to get this out the door before the holidays so that people can
>> get it on their calendar. We can also use this thread to air out any
>> questions about office hours before the January 6th.
>>
>> Thanks and have a safe holiday season!
>>
>> Lance
>>
>>
>> [0] http://lists.openstack.org/pipermail/openstack-dev/2015-
>> October/076649.html
>> [1] https://etherpad.openstack.org/p/keystone-office-hours
>>
>> 
>> __
>> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Issues with libvirt transition 1.2.7 -> 2.0.0 (CentOS 7.3)

[Steve Gordon]

- Original Message -
> From: "Neil Jerram" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Cc: "Steve Gordon" 
> Sent: Monday, December 19, 2016 5:53:02 AM
> Subject: Re: [openstack-dev] Issues with libvirt transition 1.2.7 -> 2.0.0 
> (CentOS 7.3)
> 
> On Fri, Dec 16, 2016 at 4:16 PM Neil Jerram  wrote:
> 
> > On Fri, Dec 16, 2016 at 4:08 PM Steve Gordon  wrote:
> >
> > > If you haven't already I would suggest grabbing qemu-kvm-ev from the
> > CentOS
> > > > Virt SIG repos:
> > > >
> > > > http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/
> > > >
> > > > You can enable the repository using this release RPM:
> > > >
> > > >
> > > >
> > http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/centos-release-qemu-ev-1.0-1.el7.noarch.rpm
> > > >
> > > >
> > > Would you expect that to help with virt_type = qemu (as well as with
> > > virt_type = kvm, which I assume is the more common setting)?  If so I'll
> > be
> > > very excited to try this!
> >
> > For this particular flag issue I am not 100% sure yet as I'm still
> > checking with some of the qemu folks, but I think it would still be worth a
> > try.
> >
> >
> > Well I have at least one booting instance now, and there is no mention of
> > 'tsc_adjust not found' in the instance's log.
> >
> > So looking more promising - thanks!
> >
> >
> 
> Most of my testing on CentOS 7.3 is now working again, but I am reliably
> seeing issues in 3 cases connected with
> - multiple interfaces into a VM
> - a VM being rebooted.
> 
> Should I report those in more detail here, or is there some better place
> such as a CentOS- or libvirt-focussed list?

Hi Neil,

Sorry for the delay, the places I would suggest to get in touch with Libvirt 
folks are:

* Mailing list: https://www.redhat.com/mailman/listinfo/libvirt-users
* IRC: #virt on irc.oftc.net (often quite slow but stick around and someone 
will try help, lots of lurkers)
* Bugzilla: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Virtualization%20Tools

Hope that helps,

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] Storyboard Lives!

[Andrey Kurilin]

Hi!

It looks really promising. I like the idea of abandoning launchpad (it is
inconvenient at all) and I like "boards" for tasks.
But I have one feature request, before I can think seriously about
switching to it from my trello board - ability to change colors of UI.
Generally I like red and black colors, but it’s just too harsh and my eyes get
tired quickly while browsing pages at StoryBoard.

On Wed, Dec 21, 2016 at 11:59 PM, Kendall Nelson 
wrote:

> Hello All,
>
>As you may or may not have heard, we are still working on moving
> towards Storyboard as our task tracker. In an effort to spread awareness
> about Storyboard and its capabilities, we’ve decided to write some blog
> posts about how it works and how it will be different from Launchpad. The
> first post is a general overview of the decision to move to Storyboard from
> Launchpad [1]. Please take a few minutes to look it over!
>
> We will have more blog posts coming after the new year begins (with
> everyone taking things easy over the holidays and all there will be a bit
> of a gap). The next post’s focus will be a more in depth compare and
> contrast of Launchpad and Storyboard. After that, we have a few others
> planned, but if there are things you would be interested in hearing about
> in more detail that might be good for a blog post, let us know! Also, feel
> free to drop in the #storyboard channel if you have questions or attend our
> weekly meetings [2].
>
> If you are interested in playing around in the Storyboard sandbox [3],
> read some of the documentation [4], or just go check it out [5] please do
> so as well :)
>
> Thanks!
>
> Kendall Nelson (diablo_rojo) & the Storyboard team :)
>
> [1] https://storyboard-blog.sotk.co.uk/why-storyboard-for-openstack.html
>
> [2] https://wiki.openstack.org/wiki/StoryBoard
>
> [3] https://storyboard-dev.openstack.org/
>
> [4] http://docs.openstack.org/infra/storyboard/
>
> [5] https://storyboard.openstack.org/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing 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] Storyboard Lives!

[Kendall Nelson]

Hello All,

   As you may or may not have heard, we are still working on moving towards
Storyboard as our task tracker. In an effort to spread awareness about
Storyboard and its capabilities, we’ve decided to write some blog posts
about how it works and how it will be different from Launchpad. The first
post is a general overview of the decision to move to Storyboard from
Launchpad [1]. Please take a few minutes to look it over!

We will have more blog posts coming after the new year begins (with
everyone taking things easy over the holidays and all there will be a bit
of a gap). The next post’s focus will be a more in depth compare and
contrast of Launchpad and Storyboard. After that, we have a few others
planned, but if there are things you would be interested in hearing about
in more detail that might be good for a blog post, let us know! Also, feel
free to drop in the #storyboard channel if you have questions or attend our
weekly meetings [2].

If you are interested in playing around in the Storyboard sandbox [3], read
some of the documentation [4], or just go check it out [5] please do so as
well :)

Thanks!

Kendall Nelson (diablo_rojo) & the Storyboard team :)

[1] https://storyboard-blog.sotk.co.uk/why-storyboard-for-openstack.html

[2] https://wiki.openstack.org/wiki/StoryBoard

[3] https://storyboard-dev.openstack.org/

[4] http://docs.openstack.org/infra/storyboard/

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

Re: [openstack-dev] [docs] Stepping down from core

[Steve Martinelli]

Sorry to see you go Matt. Thanks for everything you've done with in the
docs project, and thank you for always taking the time to field all the
setup questions in #openstack and #openstack-dev from the newcomers, it was
invaluable.

Hoping your new opportunity brings you much success.

On Wed, Dec 21, 2016 at 11:11 AM, Matt Kassawara 
wrote:

> Howdy!
>
> After several years of contributing to OpenStack documentation, a
> significant change in my career path warrants resigning from my role as a
> core reviewer. Working with the OpenStack community was a great experience
> and I hope it continues to grow... with sufficient documentation, of course.
>
> Cheers,
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] Stepping down from core

[Matthew Thode]

On 12/21/2016 10:11 AM, Matt Kassawara wrote:
> Howdy!
> 
> After several years of contributing to OpenStack documentation, a
> significant change in my career path warrants resigning from my role as
> a core reviewer. Working with the OpenStack community was a great
> experience and I hope it continues to grow... with sufficient
> documentation, of course.
> 
> Cheers,
> Matt

Hey other Matt, selfishly sorry to see you go.  Between your networking
guides and talking with you on ipv6 related topics, working with you has
been great.

Again, sorry to see you go, docs will be worse without you.  I do hope
you will be going on to greater things.


-- 
-- 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-operators] CentOS 7.3 libvirt appears to be broken for virtio-scsi and ceph with cephx auth

[Mike Lowe]

Looks like there has been some quick movement from the RedHat guys.  From the 
most recent update looks like a patch for the existing 7.3 libvirt for 
virtio-scsi cephx hotplug problem is in flight, so there’s that. 
https://bugzilla.redhat.com/show_bug.cgi?id=1406442 



> On Dec 21, 2016, at 3:32 PM, Mike Smith  wrote:
> 
> We had a similar surprise updating our lab to CentOS 7.3.  Even Openstack 
> aside, libvirt itself on 7.3 couldn’t recognize any of our defined VMs - kept 
> giving a message of “ No path to ‘ ‘ “ just trying to do a ‘virsh list’.   We 
> ended up adding an additional yum repo definition pointing to the older 7.2 
> repo and doing a yum history rollback and we’ve stopped pointing to the 7.3 
> repo altogether.  We had other problems with Cent 7.3 as well, unrelated to 
> virtualization.
> 
> Are others out there successfully using CentOS 7.3 right now with libvirt or 
> is everyone experiencing this similar pain.
> 
> That’s frightening that the virtio-scsi support is broken as well. 
>  
> Mike Smith
> Lead Cloud Systems Architect
> Overstock.com 
> 
> 
> 
>> On Dec 20, 2016, at 9:57 AM, Mike Lowe > > wrote:
>> 
>> I got a rather nasty surprise upgrading from CentOS 7.2 to 7.3.  As far as I 
>> can tell the libvirt 2.0.0 that ships with 7.3 doesn’t behave the same way 
>> as the 1.2.17 that ships with 7.2 when using ceph with cephx auth during 
>> volume attachment using virtio-scsi.  It looks like it fails to add the 
>> cephx secret.  The telltale signs are "No secret with id 
>> 'scsi0-0-0-1-secret0’” in the /var/log/libvirt/qemu instance logs.  I’ve 
>> filed a bug here https://bugzilla.redhat.com/show_bug.cgi?id=1406442 
>>  and there is a libvirt 
>> mailing list  thread about a fix for libvirt 2.5.0 for what looks like this 
>> same problem 
>> https://www.redhat.com/archives/libvir-list/2016-October/msg00396.html 
>>   
>> I’m out of ideas for workarounds having had kind of a disastrous attempt at 
>> downgrading to libvirt 1.2.17, so if anybody has any suggestions I’m all 
>> ears.  
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 
> 
> CONFIDENTIALITY NOTICE: This message is intended only for the use and review 
> of the individual or entity to which it is addressed and may contain 
> information that is privileged and confidential. If the reader of this 
> message is not the intended recipient, or the employee or agent responsible 
> for delivering the message solely to the intended recipient, you are hereby 
> notified that any dissemination, distribution or copying of this 
> communication is strictly prohibited. If you have received this communication 
> in error, please notify sender immediately by telephone or return email. 
> Thank you.

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

[openstack-dev] [release] reno 2.0.0

[Doug Hellmann]

This new version of reno is a major rewrite of the repository scanner
logic and includes some breaking changes to the internal API (the
command line remains the same). Those changes broke the release
announcement job, and we're working on getting that fixed. In the
mean time, I wanted to make sure folks were aware that the new
version is out there, in case you start seeing build issues.

The release notes at http://docs.openstack.org/developer/reno/history.html
are up to date, even though the version number looks wrong there.

Doug

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

Re: [openstack-dev] [docs] Stepping down from core

[Martin Hickey]

Hi Matt,

It was a pleasure working with you and all the help you volunteered. All
the best.

Regards,
Martin



From:   Matt Kassawara 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   21/12/2016 16:17
Subject:[openstack-dev] [docs] Stepping down from core



Howdy!

After several years of contributing to OpenStack documentation, a
significant change in my career path warrants resigning from my role as a
core reviewer. Working with the OpenStack community was a great experience
and I hope it continues to grow... with sufficient documentation, of
course.

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


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

Re: [Openstack-operators] CentOS 7.3 libvirt appears to be broken for virtio-scsi and ceph with cephx auth

[Mike Smith]

We had a similar surprise updating our lab to CentOS 7.3.  Even Openstack 
aside, libvirt itself on 7.3 couldn’t recognize any of our defined VMs - kept 
giving a message of “ No path to ‘ ‘ “ just trying to do a ‘virsh list’.   We 
ended up adding an additional yum repo definition pointing to the older 7.2 
repo and doing a yum history rollback and we’ve stopped pointing to the 7.3 
repo altogether.  We had other problems with Cent 7.3 as well, unrelated to 
virtualization.

Are others out there successfully using CentOS 7.3 right now with libvirt or is 
everyone experiencing this similar pain.

That’s frightening that the virtio-scsi support is broken as well.

Mike Smith
Lead Cloud Systems Architect
Overstock.com



On Dec 20, 2016, at 9:57 AM, Mike Lowe > 
wrote:

I got a rather nasty surprise upgrading from CentOS 7.2 to 7.3.  As far as I 
can tell the libvirt 2.0.0 that ships with 7.3 doesn’t behave the same way as 
the 1.2.17 that ships with 7.2 when using ceph with cephx auth during volume 
attachment using virtio-scsi.  It looks like it fails to add the cephx secret.  
The telltale signs are "No secret with id 'scsi0-0-0-1-secret0’” in the 
/var/log/libvirt/qemu instance logs.  I’ve filed a bug here 
https://bugzilla.redhat.com/show_bug.cgi?id=1406442 and there is a libvirt 
mailing list  thread about a fix for libvirt 2.5.0 for what looks like this 
same problem 
https://www.redhat.com/archives/libvir-list/2016-October/msg00396.html  I’m out 
of ideas for workarounds having had kind of a disastrous attempt at downgrading 
to libvirt 1.2.17, so if anybody has any suggestions I’m all ears.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [openstack-dev] [keystone] office hours starting January 6th

[Steve Martinelli]

Thanks for setting this up Lance!

You can count on me to join and smash some bugs.

On Wed, Dec 21, 2016 at 1:06 PM, Lance Bragstad  wrote:

> Hi folks!
>
> If you remember, last year we started a weekly bug day [0]. The idea was
> to dedicate one day a week to managing keystone's bug queue by triaging,
> fixing, and reviewing bugs. This was otherwise known as keystone's office
> hours.
>
> I'd like to remind everyone that we are starting up this initiative again,
> right after the New Year. Our first bug day this year will be Friday,
> January 6th, and it will be recurring every Friday after that.
>
> Previously, we used the etherpad [1] to track the status of patches and
> bugs through the day. This time around, I'd like to see if we can keep
> state out of the etherpad in favor of Gerrit dashboards and IRC (which are
> easier to log and track). The etherpad now consists of information about
> the event, which should eventually be moved into a wiki somewhere.
>
> I wanted to get this out the door before the holidays so that people can
> get it on their calendar. We can also use this thread to air out any
> questions about office hours before the January 6th.
>
> Thanks and have a safe holiday season!
>
> Lance
>
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/
> 2015-October/076649.html
> [1] https://etherpad.openstack.org/p/keystone-office-hours
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] Stepping down from core

[Andreas Jaeger]

On 12/21/2016 05:11 PM, Matt Kassawara wrote:
> Howdy!
> 
> After several years of contributing to OpenStack documentation, a
> significant change in my career path warrants resigning from my role as
> a core reviewer. Working with the OpenStack community was a great
> experience and I hope it continues to grow... with sufficient
> documentation, of course.

Matt,

all the best for your future.

Thanks for all your docs work!

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


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

Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

[Clay Gerrard]

On Tue, Dec 20, 2016 at 2:11 PM, Dean Troyer  wrote:
>
> This is exactly how it should work.  I do want to make an additional
> important but subtle point:  while it looks like those are namespaced
> commands, we used 'server' not 'compute' because it is not a
> compute-namespaced, but a server-specific resource.

I *think* I understood this - the server command is representative of a
server resource, not a service.  It's somewhat circumstantial that often
times when you think about the top level base primitive resources OpenStack
provides cloud users - that they occasionally align with a single service
API endpoint.  But a big design goal for a unified client seems like it
might hopefully help abstract the services away so the user can focus on
their "stuff" ;)

>'object store container' would be consistent, 'object store object' is
awful.

Fully agree, would suggest:

"object "
"object container "
"object account "

I think this follows closely where the other resource commands are going?

>
> Notice that in the command list lined above the 'backup' resource has
> been deprecated and renamed as 'volume backup'.  We could possibly
> also do this with 'object' and 'container' from Swift, we will be
> doing this with other resources (flavor -> server flavor comes to
> mind).

I had not noticed the backup command, or flavor, thank you for pointing
those out.  This is excellent news!

>
> Backward compatibility is very important to us though, so renaming
> these resources takes a long time to complete.  Freeing up the
> top-level bare container resource would be three cycles out at best.
>

Seems reasonable to me!  AIUI the top level "object" resource would stay,
it would grow "container" & "account" sub resources, and the "object store
account" and "container" top-level commands would be deprecated.  Then
during the development of the release after a release which includes those
changes you could start to remove the deprecated interfaces.

-Clay
__
OpenStack Development Mailing 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] [Gluon] IRC Meeting cancelled on Dec 28, 2016 and Re-convene on Jan 4, 2017

[HU, BIN]

Hello folks,

Many thanks to all of contributors to Gluon project, and we have had great 
progress in 2016. Thank you.

For those of you who are interested in joining and contributing to our work, 
please get all information from our wiki [1] and past meeting agenda and 
minutes [2].

We just agreed that we will cancel the IRC meeting next week Dec 28 so that 
everyone can enjoy the holidays. We will re-convene on Jan 4 in the new year.

Wish everyone happy holidays

Bin

[1] https://wiki.openstack.org/wiki/Gluon
[2] https://wiki.openstack.org/wiki/Meetings/Gluon

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

Re: [openstack-dev] [docs] Stepping down from core

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Matt,
Thanks for all your efforts in documenting.
It was pleasure working with you.
Looking forward to see you contribute back to OpenStack.

Thanks
Swami

From: Matt Kassawara [mailto:mkassaw...@gmail.com]
Sent: Wednesday, December 21, 2016 8:11 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [docs] Stepping down from core

Howdy!

After several years of contributing to OpenStack documentation, a significant 
change in my career path warrants resigning from my role as a core reviewer. 
Working with the OpenStack community was a great experience and I hope it 
continues to grow... with sufficient documentation, of course.

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

[openstack-dev] [keystone] office hours starting January 6th

[Lance Bragstad]

Hi folks!

If you remember, last year we started a weekly bug day [0]. The idea was to
dedicate one day a week to managing keystone's bug queue by triaging,
fixing, and reviewing bugs. This was otherwise known as keystone's office
hours.

I'd like to remind everyone that we are starting up this initiative again,
right after the New Year. Our first bug day this year will be Friday,
January 6th, and it will be recurring every Friday after that.

Previously, we used the etherpad [1] to track the status of patches and
bugs through the day. This time around, I'd like to see if we can keep
state out of the etherpad in favor of Gerrit dashboards and IRC (which are
easier to log and track). The etherpad now consists of information about
the event, which should eventually be moved into a wiki somewhere.

I wanted to get this out the door before the holidays so that people can
get it on their calendar. We can also use this thread to air out any
questions about office hours before the January 6th.

Thanks and have a safe holiday season!

Lance


[0]
http://lists.openstack.org/pipermail/openstack-dev/2015-October/076649.html
[1] https://etherpad.openstack.org/p/keystone-office-hours
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] Stepping down from core

[Sean M. Collins]

Thanks for all your hard work - I remember the Bad Old Days when there
was little to no documentation on anything in OpenStack. We are in a
much better place, thanks to your work.


-- 
Sean M. Collins

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

[openstack-dev] [craton] [api] Pagination Specification

[Ian Cordasco]

Hey all,

As promised I've worked out a tiny, but hopefully informative,
pagination specification for Craton. It's available at
https://review.openstack.org/413735 and I might update it to include
more information as I go along today. Regardless, nothing is decided
in that. Following the spirit of our last specification, I've put all
our options into one place and once we've started to reject them we
can move them to the Alternatives section with explanations.

Cheers,
--
Ian Cordasco

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

[openstack-dev] [kolla] kolla-kubernetes needs to sort out what to call our k8s objects

[Steven Dake (stdake)]

Hello folks,

In our team meeting today, I took an action to begin a mailing list discussion 
around what to call our k8s objects in the kolla-kubernetes deliverable.  At 
present, we are calling them “pods”.  The general consensus on the team meeting 
is this is a hard concept for people new to the Kolla project to understand 
because we are not using pods directly.  Instead we are using a bunch of 
different k8s objects that morph into k8s PODs internally in Kubernetes.  There 
was also a general consensus that this problem needs to be solved because it 
hampers growth of the Kolla community long term as it relates to the 
kolla-kubernetes deliverable.

There were several suggestions mentioned, however, no decision was made.  I’d 
encourage individuals interested in solving this problem to respond on this 
thread with an expansion of the discussion.  The end goal is to determine what 
to call these k8s object filenames in the repository.

I’d further encourage individuals to read the IRC logs here for full context of 
the problem in more detail:

Search for this timestamp with your browser:

16:23:26 to 16:36:39

http://eavesdrop.openstack.org/meetings/kolla/2016/kolla.2016-12-21-16.00.log.html

Happy holidays ☺

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

[openstack-dev] [keystone] 2016-12-21 policy meeting

[Lance Bragstad]

Sending a note to summarize the policy meeting we had today [0]. Also to
remind folks that our next policy meeting will be Wednesday, January 4th.

Hope everyone has a safe and happy holiday season!

[0]
http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-21-16.01.log.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Fwd: Dive into Live Migration-Query-Reg

[yamini jaya naga Malliswari]

-- Forwarded message --
From: "yamini jaya naga Malliswari" 
Date: Dec 21, 2016 13:39
Subject: Dive into Live Migration-Query-Reg
To: 
Cc:

Sir

I am research scholar in SRM University, Chennai, working on live migration
in open stack.I have watched the video "Dive into Live Migration-Open Stack
Summit". It was a great talk. I have a free doubts regarding this.

1. In active LM monitoring in open stack slide first point is track memory
transfer progress.
Is it possible to get access/ buffer the memory/modified memory pages that
are transferred during live migration. so that we can do some operations
for optimization.

Kindly reply.

Thanks and Regards

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

Re: [openstack-dev] [docs] Stepping down from core

[John Davidge]

On 12/21/16, 4:11 PM, "Matt Kassawara"  wrote:

>Howdy!
>
>
>After several years of contributing to OpenStack documentation, a
>significant change in my career path warrants resigning from my role as a
>core reviewer. Working with the OpenStack community was a great
>experience and I hope it continues to grow... with
> sufficient documentation, of course.
>
>
>Cheers,
>Matt
>

Thanks for all of your work on the networking guide, and good luck in your
future endeavors!

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] Stepping down from core

[Anita Kuno]

On 2016-12-21 11:11 AM, Matt Kassawara wrote:

Howdy!

After several years of contributing to OpenStack documentation, a
significant change in my career path warrants resigning from my role as a
core reviewer. Working with the OpenStack community was a great experience
and I hope it continues to grow... with sufficient documentation, of course.

Cheers,
Matt



I have so much gratitude for all your hard work, thank you Matt.

May you have clear skies in every direction you turn,
Anita.

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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Amrith Kumar]

For those who would like to know exactly what this set of changes cost in the 
CI, the answer is approximately 1050 jobs which consumed 190 compute hours of 
CI time.

-amrith

-Original Message-
From: Amrith Kumar [mailto:amr...@tesora.com] 
Sent: Wednesday, December 21, 2016 11:13 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

Ian, Andreas, Emilien,

My sentiments on the subject of these kinds of "production line" changes is 
unchanged from [1] and [2]. A complete list of these changes is at [3].

I've updated all of the changes in this thread with a block comment and a -1. 
My apologies to other reviewers (and active contributors in those projects) for 
this automated comment across 131 commits. 

It is high time we eliminated these kinds of changes which do little to improve 
the overall quality of the product and serve merely to generate a huge amount 
of pointless work on the CI systems, and boost some meaningless statistics that 
someone wants to put on a slide someplace.

-amrith

[1] http://openstack.markmail.org/thread/dsuxy2sxxudfbij4
[2] http://openstack.markmail.org/thread/3sr5c2u7fhpzanit
[3] https://review.openstack.org/#/q/topic:addCONTRIBUTING.rst

-Original Message-
From: Andreas Jaeger [mailto:a...@suse.com]
Sent: Wednesday, December 21, 2016 10:47 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

On 2016-12-21 16:22, Ian Cordasco wrote:
> [...]
> That said, I think there are two better places for this information 
> that are already standards in OpenStack:
> 
> * README.rst
> * HACKING.rst
> 
> Most projects include links to the contributing documentation in at 
> least one of these files. I think the effort here is to standardize, 
> albeit in a brand new file, and that's admirable.

If that's the goal - to standardize - then I would expect that we move all the 
documentation out of those files in one place.

Right now, the changes duplicate information that exists - and the new 
information is often wrong. It points to place that do not exist or where 
better places exist. ;(


I'm fine with the status quo - of using the two files that you mention.
Having contribution information is important,

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


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


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

Re: [openstack-dev] [ceilometer]

[Julien Danjou]

On Thu, Dec 22 2016, 刘瀚檄 wrote:

Hi Hanxi!

> Third, I have taken some questions into consideration:
> (1)
> Previous gnocchi configure:
>
>
> [dispatcher_gnocchi]
> filter_service_activity = False 
> archive_policy = low
>
>
> I want to make sure whether we still need configure in ceilometer.conf
> as previous.

Yes, that should not change.

> (2)
> Refer to panko:
>
> [default]
> event_dispatchers = panko 
>
>
> Where to configure panko dispatcher next? in pipline?
> If we remove collector, I'm sure something in panko need to be changed.

Yeah, I guess it'll be using direct:// or something like that to
directly talk to the dispatcher code without using the collector.

> Fourth, remove collector code. It will make many tests all of a sudden
> failure, so we have change the test suites. At the same time, we should
> add some integration tests to confirm these changes won't make the whole
> project gets stuck.

We have a whole integration test with Heat+Ceilometer+Aodh+Gnocchi, if
anything is broken when removing the collector in this deployment, we'll
know.

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


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

[openstack-dev] [ceilometer]Taskflow of removing collector

[刘瀚檄]

Hi ceilometer contributors,


I am so excited because this is my first mail on openstack-dev since
I started to read ceilometer code and make contributions to ceilmeter.
So wonderful it is that ceilometer architecture is being updated in
this cycle. One of these changes is we are going to remove collector.
As we all know, a slight move in one part may affect the situation
as a whole. Before that, we have to make many preparations for it.


First, update document refer to collector.


Second, devstack should be configured properly when no collector


Third, I have taken some questions into consideration:
(1)
Previous gnocchi configure:


[dispatcher_gnocchi]
filter_service_activity = False 
archive_policy = low


I want to make sure whether we still need configure in ceilometer.conf
as previous.


(2)
Refer to panko:

[default]
event_dispatchers = panko 


Where to configure panko dispatcher next? in pipline?
If we remove collector, I'm sure something in panko need to be changed.


Fourth, remove collector code. It will make many tests all of a sudden
failure, so we have change the test suites. At the same time, we should
add some integration tests to confirm these changes won't make the whole
project gets stuck.


I am look forward to your advice and discussing about the whole taskflow
of removing collector. I am always on IRC(nick name: lhx_). Btw, I am
from China. If you think using mail list is inconvinient, feel free to
ping me.


   Best regards 
 Hanxi Liu





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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Amrith Kumar]

Ian, Andreas, Emilien,

My sentiments on the subject of these kinds of "production line" changes is 
unchanged from [1] and [2]. A complete list of these changes is at [3].

I've updated all of the changes in this thread with a block comment and a -1. 
My apologies to other reviewers (and active contributors in those projects) for 
this automated comment across 131 commits. 

It is high time we eliminated these kinds of changes which do little to improve 
the overall quality of the product and serve merely to generate a huge amount 
of pointless work on the CI systems, and boost some meaningless statistics that 
someone wants to put on a slide someplace.

-amrith

[1] http://openstack.markmail.org/thread/dsuxy2sxxudfbij4
[2] http://openstack.markmail.org/thread/3sr5c2u7fhpzanit
[3] https://review.openstack.org/#/q/topic:addCONTRIBUTING.rst

-Original Message-
From: Andreas Jaeger [mailto:a...@suse.com] 
Sent: Wednesday, December 21, 2016 10:47 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

On 2016-12-21 16:22, Ian Cordasco wrote:
> [...]
> That said, I think there are two better places for this information
> that are already standards in OpenStack:
> 
> * README.rst
> * HACKING.rst
> 
> Most projects include links to the contributing documentation in at
> least one of these files. I think the effort here is to standardize,
> albeit in a brand new file, and that's admirable.

If that's the goal - to standardize - then I would expect that we move
all the documentation out of those files in one place.

Right now, the changes duplicate information that exists - and the new
information is often wrong. It points to place that do not exist or
where better places exist. ;(


I'm fine with the status quo - of using the two files that you mention.
Having contribution information is important,

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


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

[openstack-dev] [ceilometer]

[刘瀚檄]

Hi ceilometer contributors,


I am so excited because this is my first mail on openstack-dev since
I started to read ceilometer code and make contributions to ceilmeter.
So wonderful it is that ceilometer architecture is being updated in
this cycle. One of these changes is we are going to remove collector.
As we all know, a slight move in one part may affect the situation
as a whole. Before that, we have to make many preparations for it.


First, update document refer to collector.


Second, devstack should be configured properly when no collector


Third, I have taken some questions into consideration:
(1)
Previous gnocchi configure:


[dispatcher_gnocchi]
filter_service_activity = False 
archive_policy = low


I want to make sure whether we still need configure in ceilometer.conf
as previous.


(2)
Refer to panko:

[default]
event_dispatchers = panko 


Where to configure panko dispatcher next? in pipline?
If we remove collector, I'm sure something in panko need to be changed.


Fourth, remove collector code. It will make many tests all of a sudden
failure, so we have change the test suites. At the same time, we should
add some integration tests to confirm these changes won't make the whole
project gets stuck.


I am look forward to your advice and discussing about the whole taskflow
of removing collector. I am always on IRC(nick name: lhx_). Btw, I am
from China. If you think using mail list is inconvinient, feel free to ping me.


   Best regards 
 Hanxi Liu
















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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Ian Cordasco]

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

Date: December 21, 2016 at 10:11:42
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

> Hi stackers!
>  
> On Wed, Dec 21, 2016 at 5:33 PM, Emilien Macchi wrote:
>  
> > On Wed, Dec 21, 2016 at 10:22 AM, Ian Cordasco  
> > wrote:
> > > Hey everyone,
> > >
> > > It seems a contributor has written a script to add CONTRIBUTING.rst
> > > files to each OpenStack project that exists. [1]
> >
> > Thanks Ian for starting this discussion, it's very appreciated.
> >
> > It would have been great if the author of these patches would have run
> > this discussion before.
> > Just for Puppet OpenStack projects, it has consumed ~450 CI jobs
> > for... nothing (all patches will require some adjustments if we decide
> > to keep this file).
> >
>  
> You can configure your heavy jobs to not be launched on *.rst changes ;)
>  
>  
> > I can't imagine how many resources we consumed across all OpenStack
> > projects with this batch of patches...
> >
> > > As a community we've struggled with new contributors creating tonnes
> > > of patches like this at once, and that is emphatically not the purpose
> > > of this email. Instead, I'd like to discuss the actual merits of this
> > > change for OpenStack.
> > >
> > > What is CONTRIBUTING.rst?
> > > =
> > >
> > > It's a convention created by GitHub to make up for the lack of issue
> > > templating and encourage collaborators/contributors to read some
> > > documentation before filing new issues or pull requests. It does this
> > > by adding an unobtrusive link at the top of the New Issue and New Pull
> > > Request pages for projects that have these files.
> > >
> > > In my experience using these files on projects, they've been wildly
> > ineffective.
> > >
> > > Is there value in having a CONTRIBUTING.rst to OpenStack?
> > > =
> > >
> > > Well, let's consider a few things:
> > >
> > > * The canonical source for OpenStack repositories is
> > https://git.openstack.org/
> > > * OpenStack /mirrors/ to GitHub so when we add Badges to our README,
> > > they're displayed there for people who find the projects there
> >
>  
> Adding Badges is a sign that there are a lot of people who like finding
> everything in project
> repository.
> GitHub is just a mirror, but it is a first link of results list while
> googling, git.openstack.org is:
> - a second link in case of "openstack nova git" query;
> - a third link in case of "openstack keystone git;"
> - a fourth link in case of "openstack horizon git".
>  
> GitHub is a nice entry-point for new contributors. I do not want to say
> them
> "forget everything you know".

Except that learning to contribute to projects on GitHub is far from useful for 
them when looking at a project like ours or an Apache Software Foundation 
project or some of the projects open sourced by companies like Google.

> If CONTRIBUTING.rst is widely used and it can help newcomers, I'm for
> adding it.

Anecdotally speaking, it doesn't help new contributors though. Hence why I sent 
this email. If I felt it would have a measurable positive impact, I wouldn't 
have written this email. :)

> > > * OpenStack auto-closes all pull requests made to the GitHub mirrors
> > > with instructions on how to contribute
> > > * Having these files isn't really a *standard*. Other services
> > > (GitLab, BitBucket) have added support for these files, but when you
> > > look at projects not hosted on one of those service, these files
> > > aren't as common.
> >
>  
> If GitHub, GitLab, BitBucket support that file, having CONTRIBUTING.rst
> sounds like
> a standard for me.

That's not what defines a standard. One company coming up with a bandaid that a 
few others scrambled to support isn't a standard, it's a fad.

> > > * GitHub now allows the files that they look for to be in a .github
> > > directory so the root of the repository isn't cluttered with markdown
> > > and other files that only GitHub cares about for providing poorly made
> > > bandaids for serious issues in their platform.
> > >
> > > I'm not sure there's a great deal of benefit to OpenStack projects in
> > > these patches. I'm sure most of us don't ever look to see how many
> > > pull requests get opened against the GitHub mirrors. I doubt these
> > > files would stop anyone from sending pull requests there in the first
> > > place (based entirely on my own, purely anecdotal experiences).
> > >
> > > Further, OpenStack already has a great deal of cross-project and
> > > project-specific documentation around contributing that's easily
> > > findable. Making that slightly more discoverable probably isn't a bad
> > > thing.
> > >
> > > On top 

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Ian Cordasco]

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

Date: December 21, 2016 at 10:13:09
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

> On Wed, Dec 21, 2016 at 5:46 PM, Andreas Jaeger wrote:
>  
> > On 2016-12-21 16:22, Ian Cordasco wrote:
> > > [...]
> > > That said, I think there are two better places for this information
> > > that are already standards in OpenStack:
> > >
> > > * README.rst
> > > * HACKING.rst
> > >
> > > Most projects include links to the contributing documentation in at
> > > least one of these files. I think the effort here is to standardize,
> > > albeit in a brand new file, and that's admirable.
> >
> > If that's the goal - to standardize - then I would expect that we move
> > all the documentation out of those files in one place.
> >
> > Right now, the changes duplicate information that exists - and the new
> > information is often wrong. It points to place that do not exist or
> > where better places exist. ;(
> >
>  
> Duplication can be reduced by using `.. include:: ` directive.

That does not render anywhere except our documentation (via Sphinx). 
Git{Hub,Lab} don't render the include directive at all.

So, no, that's not an option.

--  
Ian Cordasco


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

Re: [openstack-dev] [acceleration]Team Bi-weekly Meeting 2016.12.21 Agenda

[Zhipeng Huang]

Hi all,

Thanks for attending the last team meeting in year 2016 :) Please find the
meeting notes at
https://wiki.openstack.org/wiki/Cyborg/MeetingLogs#2016-12-21 .

Our next meeting will be held at Jan 4th, 2017.

At the meantime, could you indicate whether you would attend Atlanta PTG by
replying to this email ? Many thanks :)

On Wed, Dec 21, 2016 at 3:14 PM, Zhipeng Huang 
wrote:

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



-- 
Zhipeng (Howard) Huang

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

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

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

[openstack-dev] [docs] Stepping down from core

[Matt Kassawara]

Howdy!

After several years of contributing to OpenStack documentation, a
significant change in my career path warrants resigning from my role as a
core reviewer. Working with the OpenStack community was a great experience
and I hope it continues to grow... with sufficient documentation, of course.

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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Andrey Kurilin]

On Wed, Dec 21, 2016 at 5:46 PM, Andreas Jaeger  wrote:

> On 2016-12-21 16:22, Ian Cordasco wrote:
> > [...]
> > That said, I think there are two better places for this information
> > that are already standards in OpenStack:
> >
> > * README.rst
> > * HACKING.rst
> >
> > Most projects include links to the contributing documentation in at
> > least one of these files. I think the effort here is to standardize,
> > albeit in a brand new file, and that's admirable.
>
> If that's the goal - to standardize - then I would expect that we move
> all the documentation out of those files in one place.
>
> Right now, the changes duplicate information that exists - and the new
> information is often wrong. It points to place that do not exist or
> where better places exist. ;(
>

Duplication can be reduced by using `.. include:: ` directive.

>
>
> I'm fine with the status quo - of using the two files that you mention.
> Having contribution information is important,
>
> 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
>



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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Andrey Kurilin]

Hi stackers!

On Wed, Dec 21, 2016 at 5:33 PM, Emilien Macchi  wrote:

> On Wed, Dec 21, 2016 at 10:22 AM, Ian Cordasco 
> wrote:
> > Hey everyone,
> >
> > It seems a contributor has written a script to add CONTRIBUTING.rst
> > files to each OpenStack project that exists. [1]
>
> Thanks Ian for starting this discussion, it's very appreciated.
>
> It would have been great if the author of these patches would have run
> this discussion before.
> Just for Puppet OpenStack projects, it has consumed ~450 CI jobs
> for... nothing (all patches will require some adjustments if we decide
> to keep this file).
>

You can configure your heavy jobs to not be launched on *.rst changes ;)


> I can't imagine how many resources we consumed across all OpenStack
> projects with this batch of patches...
>
> > As a community we've struggled with new contributors creating tonnes
> > of patches like this at once, and that is emphatically not the purpose
> > of this email. Instead, I'd like to discuss the actual merits of this
> > change for OpenStack.
> >
> > What is CONTRIBUTING.rst?
> > =
> >
> > It's a convention created by GitHub to make up for the lack of issue
> > templating and encourage collaborators/contributors to read some
> > documentation before filing new issues or pull requests. It does this
> > by adding an unobtrusive link at the top of the New Issue and New Pull
> > Request pages for projects that have these files.
> >
> > In my experience using these files on projects, they've been wildly
> ineffective.
> >
> > Is there value in having a CONTRIBUTING.rst to OpenStack?
> > =
> >
> > Well, let's consider a few things:
> >
> > * The canonical source for OpenStack repositories is
> https://git.openstack.org/
> > * OpenStack /mirrors/ to GitHub so when we add Badges to our README,
> > they're displayed there for people who find the projects there
>

Adding Badges is a sign that there are a lot of people who like finding
everything in project
repository.
GitHub is just a mirror, but it is a first link of results list while
googling, git.openstack.org is:
 - a second link in case of "openstack nova git" query;
 - a third link in case of "openstack keystone git;"
 - a fourth link in case of "openstack horizon git".

GitHub is a nice entry-point for new contributors. I do not want to say
them
"forget everything you know".
If CONTRIBUTING.rst is widely used and it can help newcomers, I'm for
adding it.


> > * OpenStack auto-closes all pull requests made to the GitHub mirrors
> > with instructions on how to contribute
> > * Having these files isn't really a *standard*. Other services
> > (GitLab, BitBucket) have added support for these files, but when you
> > look at projects not hosted on one of those service, these files
> > aren't as common.
>

If GitHub, GitLab, BitBucket support that file, having CONTRIBUTING.rst
sounds like
a standard for me.


> > * GitHub now allows the files that they look for to be in a .github
> > directory so the root of the repository isn't cluttered with markdown
> > and other files that only GitHub cares about for providing poorly made
> > bandaids for serious issues in their platform.
> >
> > I'm not sure there's a great deal of benefit to OpenStack projects in
> > these patches. I'm sure most of us don't ever look to see how many
> > pull requests get opened against the GitHub mirrors. I doubt these
> > files would stop anyone from sending pull requests there in the first
> > place (based entirely on my own, purely anecdotal experiences).
> >
> > Further, OpenStack already has a great deal of cross-project and
> > project-specific documentation around contributing that's easily
> > findable. Making that slightly more discoverable probably isn't a bad
> > thing.
> >
> > On top of that, some projects have had CONTRIBUTING.rst files for a
> > while (Glance's goes back at least to 2014).
>

Nova has it since 21 Nov 2012 ;)


> Standardization about
> > where to look for that info wouldn't hurt us at all.
> >
> > That said, I think there are two better places for this information
> > that are already standards in OpenStack:
> >
> > * README.rst
> > * HACKING.rst
> >
> > Most projects include links to the contributing documentation in at
> > least one of these files. I think the effort here is to standardize,
> > albeit in a brand new file, and that's admirable.
>
>
It is true. Regularly, README.rst includes "how-to contribute" stuff, but
"ideal" README should describe a lot of things about projects and it can
become huge enough, so new contributors can miss "how-to contribute"
section
there (README often doesn't have content list at the top of file).

+1 on those files.
>
> > If you look at the gerrit query, some projects have already merged or
> > abandoned some of the patches. Let's see if we can come to an
> > agreement about how to improve the experience for 

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Ian Cordasco]

 

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

Date: December 21, 2016 at 09:48:20
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

> On 2016-12-21 16:22, Ian Cordasco wrote:
> > [...]
> > That said, I think there are two better places for this information
> > that are already standards in OpenStack:
> >
> > * README.rst
> > * HACKING.rst
> >
> > Most projects include links to the contributing documentation in at
> > least one of these files. I think the effort here is to standardize,
> > albeit in a brand new file, and that's admirable.
>  
> If that's the goal - to standardize - then I would expect that we move
> all the documentation out of those files in one place. 

The best reasoning I can come up with for a mass number of changes like this is 
to standardize a bit. I could be entirely wrong, but sending these changes in 
the interest of standardization is the best possible assumption I can make 
about the contributor's intentions.

> Right now, the changes duplicate information that exists - and the new
> information is often wrong. It points to place that do not exist or
> where better places exist. ;(

I agree. This is why I've been -1'ing or -2'ing these patches on projects.

> I'm fine with the status quo - of using the two files that you mention.
> Having contribution information is important,

The status quo is far from perfect, but it seems to have worked well enough for 
a few years now.

--  
Ian Cordasco


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

[openstack-dev] [Neutron][networking-*] Attention for upcoming refactoring

[Anna Taraday]

Hello everyone!

I've got two changes with refactor of TypeDriver [1] and segments db [2]
which is needed for implementation new engine facade [3].

Reviewers of networking-cisco, networking-arista, networking-nec

, networking-midonet
,
networking-edge-vpn, networking-bagpipe, tricircle, group-based-policy
-
pay attention for [4].

Also recently merged refactor of ml2/db.py [5]. Fixes
for networking-cisco, networking-cisco, networking-cisco - are on review [6]

[1] - https://review.openstack.org/#/c/398873/
[2] - https://review.openstack.org/#/c/406275/
[3] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
[4] - https://review.openstack.org/#/q/topic:segmentsdb
[5] - https://review.openstack.org/#/c/404714/
[6] -
https://review.openstack.org/#/q/status:open++branch:master+topic:refactor_ml2db
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Andreas Jaeger]

On 2016-12-21 16:22, Ian Cordasco wrote:
> [...]
> That said, I think there are two better places for this information
> that are already standards in OpenStack:
> 
> * README.rst
> * HACKING.rst
> 
> Most projects include links to the contributing documentation in at
> least one of these files. I think the effort here is to standardize,
> albeit in a brand new file, and that's admirable.

If that's the goal - to standardize - then I would expect that we move
all the documentation out of those files in one place.

Right now, the changes duplicate information that exists - and the new
information is often wrong. It points to place that do not exist or
where better places exist. ;(


I'm fine with the status quo - of using the two files that you mention.
Having contribution information is important,

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


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

[openstack-dev] [heat] No IRC meeting next week

[Rabi Mishra]

Hi All,



As discussed in the meeting today, I'm cancelling the next IRC meeting on 28th
Dec. We'll meet again on 4th Jan 2017.


Wish you all merry Christmas and happy new year.

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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Emilien Macchi]

On Wed, Dec 21, 2016 at 10:22 AM, Ian Cordasco  wrote:
> Hey everyone,
>
> It seems a contributor has written a script to add CONTRIBUTING.rst
> files to each OpenStack project that exists. [1]

Thanks Ian for starting this discussion, it's very appreciated.

It would have been great if the author of these patches would have run
this discussion before.
Just for Puppet OpenStack projects, it has consumed ~450 CI jobs
for... nothing (all patches will require some adjustments if we decide
to keep this file).
I can't imagine how many resources we consumed across all OpenStack
projects with this batch of patches...

> As a community we've struggled with new contributors creating tonnes
> of patches like this at once, and that is emphatically not the purpose
> of this email. Instead, I'd like to discuss the actual merits of this
> change for OpenStack.
>
> What is CONTRIBUTING.rst?
> =
>
> It's a convention created by GitHub to make up for the lack of issue
> templating and encourage collaborators/contributors to read some
> documentation before filing new issues or pull requests. It does this
> by adding an unobtrusive link at the top of the New Issue and New Pull
> Request pages for projects that have these files.
>
> In my experience using these files on projects, they've been wildly 
> ineffective.
>
> Is there value in having a CONTRIBUTING.rst to OpenStack?
> =
>
> Well, let's consider a few things:
>
> * The canonical source for OpenStack repositories is 
> https://git.openstack.org/
> * OpenStack /mirrors/ to GitHub so when we add Badges to our README,
> they're displayed there for people who find the projects there
> * OpenStack auto-closes all pull requests made to the GitHub mirrors
> with instructions on how to contribute
> * Having these files isn't really a *standard*. Other services
> (GitLab, BitBucket) have added support for these files, but when you
> look at projects not hosted on one of those service, these files
> aren't as common.
> * GitHub now allows the files that they look for to be in a .github
> directory so the root of the repository isn't cluttered with markdown
> and other files that only GitHub cares about for providing poorly made
> bandaids for serious issues in their platform.
>
> I'm not sure there's a great deal of benefit to OpenStack projects in
> these patches. I'm sure most of us don't ever look to see how many
> pull requests get opened against the GitHub mirrors. I doubt these
> files would stop anyone from sending pull requests there in the first
> place (based entirely on my own, purely anecdotal experiences).
>
> Further, OpenStack already has a great deal of cross-project and
> project-specific documentation around contributing that's easily
> findable. Making that slightly more discoverable probably isn't a bad
> thing.
>
> On top of that, some projects have had CONTRIBUTING.rst files for a
> while (Glance's goes back at least to 2014). Standardization about
> where to look for that info wouldn't hurt us at all.
>
> That said, I think there are two better places for this information
> that are already standards in OpenStack:
>
> * README.rst
> * HACKING.rst
>
> Most projects include links to the contributing documentation in at
> least one of these files. I think the effort here is to standardize,
> albeit in a brand new file, and that's admirable.

+1 on those files.

> If you look at the gerrit query, some projects have already merged or
> abandoned some of the patches. Let's see if we can come to an
> agreement about how to improve the experience for people finding our
> projects and wanting to collaborate with us.
>
> [1]: 
> https://review.openstack.org/#/q/owner:zhouyunfeng%40inspur.com+topic:addCONTRIBUTING.rst
> --
> Ian Cordasco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

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

Re: [openstack-dev] [Vitrage] [aodh] Generig alarm help

[Weyl, Alexey (Nokia - IL)]

Thanks Julien (I thought that this may be the problem, but wasn't sure).

I have pushed some changes to gerrit for aodh and the client. If you could take 
a look and give some feedback that would be great :)

BR,
Alexey

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Wednesday, December 21, 2016 5:20 PM
> To: Weyl, Alexey (Nokia - IL)
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Vitrage] [aodh] Generig alarm help
> 
> On Wed, Dec 21 2016, Weyl, Alexey (Nokia - IL) wrote:
> 
> > I encountered an error there in py27 which I don't quite understand
> > why it happens because I have changed all the correct places in the
> > client (maybe I need to have some appropriate code for this in the
> > aodh project itself as well?)
> 
> The client tests are ran against Aodh itself… and since you did not
> implement that in Aodh, well, it can't work.
> 
> So you need to move to the next step to have the tests working one day.
> :)
> 
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Ian Cordasco]

Hey everyone,

It seems a contributor has written a script to add CONTRIBUTING.rst
files to each OpenStack project that exists. [1]

As a community we've struggled with new contributors creating tonnes
of patches like this at once, and that is emphatically not the purpose
of this email. Instead, I'd like to discuss the actual merits of this
change for OpenStack.

What is CONTRIBUTING.rst?
=

It's a convention created by GitHub to make up for the lack of issue
templating and encourage collaborators/contributors to read some
documentation before filing new issues or pull requests. It does this
by adding an unobtrusive link at the top of the New Issue and New Pull
Request pages for projects that have these files.

In my experience using these files on projects, they've been wildly ineffective.

Is there value in having a CONTRIBUTING.rst to OpenStack?
=

Well, let's consider a few things:

* The canonical source for OpenStack repositories is https://git.openstack.org/
* OpenStack /mirrors/ to GitHub so when we add Badges to our README,
they're displayed there for people who find the projects there
* OpenStack auto-closes all pull requests made to the GitHub mirrors
with instructions on how to contribute
* Having these files isn't really a *standard*. Other services
(GitLab, BitBucket) have added support for these files, but when you
look at projects not hosted on one of those service, these files
aren't as common.
* GitHub now allows the files that they look for to be in a .github
directory so the root of the repository isn't cluttered with markdown
and other files that only GitHub cares about for providing poorly made
bandaids for serious issues in their platform.

I'm not sure there's a great deal of benefit to OpenStack projects in
these patches. I'm sure most of us don't ever look to see how many
pull requests get opened against the GitHub mirrors. I doubt these
files would stop anyone from sending pull requests there in the first
place (based entirely on my own, purely anecdotal experiences).

Further, OpenStack already has a great deal of cross-project and
project-specific documentation around contributing that's easily
findable. Making that slightly more discoverable probably isn't a bad
thing.

On top of that, some projects have had CONTRIBUTING.rst files for a
while (Glance's goes back at least to 2014). Standardization about
where to look for that info wouldn't hurt us at all.

That said, I think there are two better places for this information
that are already standards in OpenStack:

* README.rst
* HACKING.rst

Most projects include links to the contributing documentation in at
least one of these files. I think the effort here is to standardize,
albeit in a brand new file, and that's admirable.

If you look at the gerrit query, some projects have already merged or
abandoned some of the patches. Let's see if we can come to an
agreement about how to improve the experience for people finding our
projects and wanting to collaborate with us.

[1]: 
https://review.openstack.org/#/q/owner:zhouyunfeng%40inspur.com+topic:addCONTRIBUTING.rst
--
Ian Cordasco

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

Re: [openstack-dev] [Vitrage] [aodh] Generig alarm help

[Julien Danjou]

On Wed, Dec 21 2016, Weyl, Alexey (Nokia - IL) wrote:

> I encountered an error there in py27 which I don't quite understand
> why it happens because I have changed all the correct places in the
> client (maybe I need to have some appropriate code for this in the
> aodh project itself as well?)

The client tests are ran against Aodh itself… and since you did not
implement that in Aodh, well, it can't work.

So you need to move to the next step to have the tests working one day.
:)

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


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

Re: [openstack-dev] [kolla] Kolla-k8s core nominations

[Michał Jastrzębski]

It seems like we have 2 new core team members:)

Cheers guys! Congrats:)

On 16 December 2016 at 15:31, Ken Wronkiewicz (kewronki)
 wrote:
> + srwilkers
> + portdirect
>
> :)
>
> On 12/14/16, 9:06 AM, "Michał Jastrzębski"  wrote:
>
> I'm happy to start nomination process for our 2 colleagues:
>
> srwilkers and portdirect
>
> to kolla-k8s core team!
> This nomination will is open for 1 week. Kolla-k8s core team, please 
> vote:)
> Consider this email as vote +1 from me.
>
> Regards,
> 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

__
OpenStack Development Mailing 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] Retiring ironic-webclient

[Loo, Ruby]

Thanks Julia.

--ruby

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

Date: Monday, December 19, 2016 at 2:34 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [Ironic] Retiring ironic-webclient

As discussed at the last summit during the contributor meet-up, as well as 
during today’s Ironic team meeting[0], we will be retiring the 
ironic-webclient. This is due to a number of factors, the largest being that 
the primary contributor has changed positions and is no longer contributing, 
nor does he have any interest in continuing to develop or maintain the 
ironic-webclient. Beyond that, no contributions have landed in the last six 
months, nor has there ever been an official release of the ironic-webclient.  
This should not be confused with ironic-ui which is a horizon plug-in.

Since there have been no releases, nor objections thus far, I will begin the 
process of retiring ironic-webclient this week.

-Julia

[0] 
http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-12-19-17.00.log.html


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

__
OpenStack Development Mailing 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] (no subject)

[Jose Manuel Ferrer Mosteiro]

 

Double check you have closed all ' and " in vars you changed. 

Maybe the problem could en in values of
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN, CACHES['default']['LOCATION'],
OPENSTACK_HOST or TIME_ZONE ? 

You can use meld to compare original configuration file and your
configuration file. 

Regards,
 Jose Manuel 

El 2016-12-21 12:57, Neil Jerram escribió: 

> Hi Atif,
> 
> There is incorrect Python indentation in the local_settings file, 
> /usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py.
> 
> From the perspective of the vanilla Horizon project, I believe 
> local_settings.py is a file that the user can create and/or modify in order 
> to influence how their own web UI looks. So it could be that you created that 
> file yourself, or it could be that it was created by the install method that 
> you are using.
> 
> But either way, you can just open the file yourself and see if you can see 
> and fix the indentation problem.
> 
> Regards, Neil
> 
> On Wed, Dec 21, 2016 at 11:45 AM Atif Munir  wrote: 
> 
>> After successful installation of openstack. I am getting this error while I 
>> was going to open http://controller/horizon [1]. The error message is for 
>> Apache2 erro logs. Please advise. Thanks 
>> 
>> Atif 
>> 
>> [Wed Dec 21 16:30:36.170646 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] mod_wsgi (pid=5302): Target 
>> WSGI script 
>> '/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi' cannot 
>> be loaded as Python module. 
>> [Wed Dec 21 16:30:36.170708 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] mod_wsgi (pid=5302): 
>> Exception occurred processing WSGI script 
>> '/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi'. 
>> [Wed Dec 21 16:30:36.170734 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] Traceback (most recent call 
>> last): 
>> [Wed Dec 21 16:30:36.170757 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] File 
>> "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi", line 
>> 16, in  
>> [Wed Dec 21 16:30:36.170790 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] application = 
>> get_wsgi_application() 
>> [Wed Dec 21 16:30:36.170803 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] File 
>> "/usr/lib/python2.7/dist-packages/django/core/wsgi.py", line 14, in 
>> get_wsgi_application 
>> [Wed Dec 21 16:30:36.170820 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] django.setup() 
>> [Wed Dec 21 16:30:36.170830 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] File 
>> "/usr/lib/python2.7/dist-packages/django/__init__.py", line 17, in setup 
>> [Wed Dec 21 16:30:36.170844 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] 
>> configure_logging(settings.LOGGING_CONFIG, settings.LOGGING) 
>> [Wed Dec 21 16:30:36.170853 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] File 
>> "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in 
>> __getattr__ 
>> [Wed Dec 21 16:30:36.170868 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] self._setup(name) 
>> [Wed Dec 21 16:30:36.170894 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] File 
>> "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in 
>> _setup 
>> [Wed Dec 21 16:30:36.170910 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] self._wrapped = 
>> Settings(settings_module) 
>> [Wed Dec 21 16:30:36.170920 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] File 
>> "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 92, in 
>> __init__ 
>> [Wed Dec 21 16:30:36.170933 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] mod = 
>> importlib.import_module(self.SETTINGS_MODULE) 
>> [Wed Dec 21 16:30:36.170943 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] File 
>> "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module 
>> [Wed Dec 21 16:30:36.170957 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] __import__(name) 
>> [Wed Dec 21 16:30:36.170973 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] File 
>> "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/settings.py",
>>  line 317, in  
>> [Wed Dec 21 16:30:36.170991 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] [remote 172.16.72.2:40754 [2]] from local.local_settings 
>> import * # noqa 
>> [Wed Dec 21 16:30:36.171047 2016] [wsgi:error] [pid 5302:tid 
>> 140489127257856] 

Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

[gordon chung]

On 20/12/16 05:09 PM, Steve Martinelli wrote:
> This was my initial thought when discussing the problem with Hongbin
> last night.
>
> We have three main "swift" resources in OSC -- "object store account",
> "container" and "object". I think renaming "container" to "object store
> container" is totally acceptable. The issue of deprecation comes into
> play, we'll need to deprecate it and give it at least one cycle.
> Luckily, the zun team isn't ready to publish a CLI just yet.
>
> Alternatively, I don't mind "appcontainer".

leverage/extend CADF taxonomy[1]?

[1] 
https://wiki.openstack.org/w/images/e/e1/Introduction_to_Cloud_Auditing_using_CADF_Event_Model_and_Taxonomy_2013-10-22.pdf
 
slide 13

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

[openstack-dev] [tripleo] Atlanta PTG

[Emilien Macchi]

General infos about PTG: https://www.openstack.org/ptg/

Some useful informations about PTG/TripleO:

* When? We have a room between Wednesday and Friday included.
Important sessions will happen on Wednesday and Thursday. We'll
probably have sessions on Friday, but it might be more hands-on and
hackfest, where people can enjoy the day to work together.

* Let's start to brainstorm our topics:
https://etherpad.openstack.org/p/tripleo-ptg-pike
  Feel free to add any topic, as soon as you can. We need to know asap
which sessions will be share with other projects (eg: tripleo/mistral,
tripleo/ironic, tripleo/heat, etc).


Please let us know any question or feedback,
Looking forward to seeing you there!
-- 
Emilien Macchi

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

[OpenStack-Infra] [nodepool] Heads up: 1.26.0 dib release for Xenial/glean network issues

[Ian Wienand]

Hi,

We found a regression where python3-only Xenial images have a messed
up pip, and incorrectly installs glean.  The result is that the system
boots but no network.

Because dib builds images for a wide range of platforms, some of which
ship python3 only, we need a way to call python scripts that is
version agnostic.  For this reason we have the dib-python element,
which installs a local dib-python binary which can be used as a #!
script.  This script decides basically to call python or python3 as
appropriate.  A recent change made this explicit [1] and removed the
(theoretically) redundant python2 install.

We believe this is due pollution of the VIRTUAL_ENV variable into the
building chroot and some magic that happens in site.py to fiddle paths
[2].  But we haven't quite sorted that out.  Of course, it is very
worrying that this all got past CI and we will be investigating that
too.

I have merged and released in 1.26.0 a hack [3] to ensure python2 is
installed for Xenial while we work on a better solution.

infra-root should be aware of this if there are any problems with
Xenial image generation that result in uncontactable hosts.  I believe
this will get us through the holidays.

Cheers & Happy Holidays/Merry Christmas all,

-i

[1] https://review.openstack.org/408288/
[2] https://review.openstack.org/413487/
[3] https://review.openstack.org/413410/

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

Re: [openstack-dev] [picasso] Picasso (FaaS) project release!

[Thierry Carrez]

Steven Dake (stdake) wrote:
> [...]
> If you do plan to enter the big tent with this code base, I’d have a
> read of:
> 
> https://github.com/openstack/governance/blob/master/reference/new-projects-requirements.rst

You can use the direct link:

https://governance.openstack.org/tc/reference/new-projects-requirements.html

Also if you plan to join the big tent one day (or want to be
forward-looking) I would advise to choose another name for the project,
since "Picasso" is one of the most actively-guarded trademarks in the world.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

On Tue, Dec 20, 2016 at 4:02 PM, Samuel Cassiba  wrote:

> >
> > On Dec 19, 2016, at 14:31, Tony Breeds  wrote:
> >
> > On Mon, Dec 19, 2016 at 09:18:20AM -0800, Samuel Cassiba wrote:
> >
> >> The Chef OpenStack cookbooks team is way late to the party. The
> cookbooks
> >> (openstack/cookbook-openstack-*, openstack/openstack-chef-repo )
> should have
> >> had their liberty branches EOL’d. I have checked and no open reviews
> exist
> >> against liberty.
> >
> > Thanks.
> >
> > While I have your attention what about your older branches.  Is there any
> > mertit keeping the kilo branches in openstack/cookbook-openstack-* or the
> > stable/{grizzly,havana,icehouse,juno} branches in
> openstack/openstack-chef-repo
> >
>
> No, no merit in keeping older branches around. They can be rightfully
> EOL’d as well.
>

Howdy,

I've cleaned up all of these branches for you. The repos that have been
retired haven't been touched. A lot of the repos had eol-$release tags but
the format used for the rest of openstack is typically $release-eol which
is the format I have kept for retiring kilo and liberty against.

Let me know if you have any questions.

Cheers,
Josh


>
> Many thanks!
>
> > Yours Tony.
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] (no subject)

[Neil Jerram]

Hi Atif,

There is incorrect Python indentation in the local_settings file,
/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py.

>From the perspective of the vanilla Horizon project, I believe
local_settings.py is a file that the user can create and/or modify in order
to influence how their own web UI looks.  So it could be that you created
that file yourself, or it could be that it was created by the install
method that you are using.

But either way, you can just open the file yourself and see if you can see
and fix the indentation problem.

Regards,
Neil


On Wed, Dec 21, 2016 at 11:45 AM Atif Munir  wrote:

>
> After successful installation of openstack. I am getting this error while
> I was going to open http://controller/horizon. The error message is for
> Apache2 erro logs. Please advise. Thanks
>
> Atif
>
>
> [Wed Dec 21 16:30:36.170646 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] mod_wsgi (pid=5302): Target
> WSGI script
> '/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi'
> cannot be loaded as Python module.
> [Wed Dec 21 16:30:36.170708 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] mod_wsgi (pid=5302):
> Exception occurred processing WSGI script
> '/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi'.
> [Wed Dec 21 16:30:36.170734 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] Traceback (most recent call
> last):
> [Wed Dec 21 16:30:36.170757 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754]   File
> "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi", line
> 16, in 
> [Wed Dec 21 16:30:36.170790 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] application =
> get_wsgi_application()
> [Wed Dec 21 16:30:36.170803 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754]   File
> "/usr/lib/python2.7/dist-packages/django/core/wsgi.py", line 14, in
> get_wsgi_application
> [Wed Dec 21 16:30:36.170820 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] django.setup()
> [Wed Dec 21 16:30:36.170830 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754]   File
> "/usr/lib/python2.7/dist-packages/django/__init__.py", line 17, in setup
> [Wed Dec 21 16:30:36.170844 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754]
> configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
> [Wed Dec 21 16:30:36.170853 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754]   File
> "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in
> __getattr__
> [Wed Dec 21 16:30:36.170868 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] self._setup(name)
> [Wed Dec 21 16:30:36.170894 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754]   File
> "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in
> _setup
> [Wed Dec 21 16:30:36.170910 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] self._wrapped =
> Settings(settings_module)
> [Wed Dec 21 16:30:36.170920 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754]   File
> "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 92, in
> __init__
> [Wed Dec 21 16:30:36.170933 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] mod =
> importlib.import_module(self.SETTINGS_MODULE)
> [Wed Dec 21 16:30:36.170943 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754]   File
> "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
> [Wed Dec 21 16:30:36.170957 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] __import__(name)
> [Wed Dec 21 16:30:36.170973 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754]   File
> "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/settings.py",
> line 317, in 
> [Wed Dec 21 16:30:36.170991 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] from local.local_settings
> import *  # noqa
> [Wed Dec 21 16:30:36.171047 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754]   File
> "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/local/local_settings.py",
> line 322
> [Wed Dec 21 16:30:36.171061 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] 'profile_support': None,
> [Wed Dec 21 16:30:36.171066 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] ^
> [Wed Dec 21 16:30:36.171071 2016] [wsgi:error] [pid 5302:tid
> 140489127257856] [remote 172.16.72.2:40754] IndentationError: unexpected
> indent
>
> 

Re: [Openstack] (no subject)

[Turbo Fredriksson]

On 21 Dec 2016, at 11:33, Atif Munir  wrote:

> [Wed Dec 21 16:30:36.170646 2016] [wsgi:error] [pid 5302:tid 140489127257856] 
> [remote 172.16.72.2:40754] mod_wsgi (pid=5302): Target WSGI script 
> '/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi' cannot 
> be loaded as Python module.

Does this file exists? Is it executable, is it a python script?

> [Wed Dec 21 16:30:36.171047 2016] [wsgi:error] [pid 5302:tid 140489127257856] 
> [remote 172.16.72.2:40754]   File 
> "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/local/local_settings.py",
>  line 322
> [Wed Dec 21 16:30:36.171061 2016] [wsgi:error] [pid 5302:tid 140489127257856] 
> [remote 172.16.72.2:40754] 'profile_support': None,
> [Wed Dec 21 16:30:36.171066 2016] [wsgi:error] [pid 5302:tid 140489127257856] 
> [remote 172.16.72.2:40754] ^
> [Wed Dec 21 16:30:36.171071 2016] [wsgi:error] [pid 5302:tid 140489127257856] 
> [remote 172.16.72.2:40754] IndentationError: unexpected indent

What do the ten lines before and after line 322 look like?
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] (no subject)

[Atif Munir]

After successful installation of openstack. I am getting this error while I
was going to open http://controller/horizon. The error message is for
Apache2 erro logs. Please advise. Thanks

Atif


[Wed Dec 21 16:30:36.170646 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] mod_wsgi (pid=5302): Target
WSGI script
'/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi'
cannot be loaded as Python module.
[Wed Dec 21 16:30:36.170708 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] mod_wsgi (pid=5302): Exception
occurred processing WSGI script
'/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi'.
[Wed Dec 21 16:30:36.170734 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] Traceback (most recent call
last):
[Wed Dec 21 16:30:36.170757 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754]   File
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi", line
16, in 
[Wed Dec 21 16:30:36.170790 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] application =
get_wsgi_application()
[Wed Dec 21 16:30:36.170803 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754]   File
"/usr/lib/python2.7/dist-packages/django/core/wsgi.py", line 14, in
get_wsgi_application
[Wed Dec 21 16:30:36.170820 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] django.setup()
[Wed Dec 21 16:30:36.170830 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754]   File
"/usr/lib/python2.7/dist-packages/django/__init__.py", line 17, in setup
[Wed Dec 21 16:30:36.170844 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754]
configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
[Wed Dec 21 16:30:36.170853 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754]   File
"/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in
__getattr__
[Wed Dec 21 16:30:36.170868 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] self._setup(name)
[Wed Dec 21 16:30:36.170894 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754]   File
"/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in
_setup
[Wed Dec 21 16:30:36.170910 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] self._wrapped =
Settings(settings_module)
[Wed Dec 21 16:30:36.170920 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754]   File
"/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 92, in
__init__
[Wed Dec 21 16:30:36.170933 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] mod =
importlib.import_module(self.SETTINGS_MODULE)
[Wed Dec 21 16:30:36.170943 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754]   File
"/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
[Wed Dec 21 16:30:36.170957 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] __import__(name)
[Wed Dec 21 16:30:36.170973 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754]   File
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/settings.py",
line 317, in 
[Wed Dec 21 16:30:36.170991 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] from local.local_settings
import *  # noqa
[Wed Dec 21 16:30:36.171047 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754]   File
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/local/local_settings.py",
line 322
[Wed Dec 21 16:30:36.171061 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] 'profile_support': None,
[Wed Dec 21 16:30:36.171066 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] ^
[Wed Dec 21 16:30:36.171071 2016] [wsgi:error] [pid 5302:tid
140489127257856] [remote 172.16.72.2:40754] IndentationError: unexpected
indent
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

On Mon, Dec 19, 2016 at 11:10 AM, Tony Breeds 
wrote:

> On Fri, Dec 16, 2016 at 05:41:31PM -0500, Emilien Macchi wrote:
> > Hey Tony,
> >
> > Could we also EOL tripleo-incubator and tripleo-image-elements
> > stable/icehouse please?
>
> Yup, No problem.
>

I have retired icehouse in both of those repos.

Cheers,
Josh


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

Re: [OpenStack-Infra] [openstack-infra] how to config gerrit to get a summary of all jobs in gerrit page

[Mikhail Medvedev]

On Wed, Dec 21, 2016 at 1:49 AM,  wrote:
>
>
> Hi all,
>
> I setup a CI system, but after all the jobs run, the summary of all jobs
don't show in gerrit page.
> Like this:
>
>
> Does anybody know how to config it? Thanks~
>

OpenStack infra uses custom js script to create that table.

If you're asking how to configure your own gerrit instance to format CI
results like a table: you can use something similar to hideci.js script [1]
in your gerrit instance UI. To see how hideci.js is setup on OpenStack
gerrit instance, see puppet configuration at [2].

If you're asking how to get your third-party CI to show up on OpenStack
gerrit: your CI's comment needs to adhere to what hideci.js expects when it
parses CI comments.


[1]
https://github.com/openstack-infra/system-config/blob/dcacf61853fb5e4e2e2f15df8ce1fbab79a8494e/modules/openstack_project/files/gerrit/hideci.js
[2]
https://github.com/openstack-infra/system-config/blob/dcacf61853fb5e4e2e2f15df8ce1fbab79a8494e/modules/openstack_project/manifests/gerrit.pp

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

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

Re: [openstack-dev] [FaaS] Function as a service in OpenStack

[Lingxian Kong]

On Wed, Dec 21, 2016 at 6:04 PM, Derek Schultz 
wrote:

> Hi all,
>
> We just released Picasso[1][2], an OpenStack API for Functions as a
> Service. I think it may be of particular interest to those in this thread,
> as it's based on IronFunctions, an open-source alternative to Lambda.
>
> The mission is to provide an API to run functions on OpenStack.
>

​Thanks very much for bringing Picasso here, I personally think it's very
import to have such a project in OpenStack ecosystem.


>
> Picasso is comprised of two main components:
>
>- Picasso API
>   - The Picasso API server uses Keystone authentication and
>   authorization through its middleware.
>- IronFunctions
>   - Picasso leverages the backend container engine provided by
>   IronFunctions[3], an open-source Serverless/FaaS platform based on 
> Docker.
>
> You can try out Picasso now on DevStack by following the quick start
> guide[4]. Let us know what you think!
>
> If you’re interested in contributing or just have any questions, please
> join us on Slack at open-iron.slack.com.
>

​Why not using an IRC channel?
​

>
> Regards,
> Derek
>
> [1] https://launchpad.net/picasso
>
> [2] https://launchpad.net/python-picassoclient
>
> [3] https://github.com/iron-io/functions
>
> [4] https://github.com/iron-io/picasso/blob/master/README.
> md#quick-start-guide
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Question on coding style on osops-tools-contrib repo

[Saverio Proto]

Hello,

in the osops-tools-contrib repo so far I proposed always python
scripts that are contained in a single file.

Now I have this file:
openstackapi.py

that I reuse in many scripts, look at this:
https://review.openstack.org/#/c/401409/

but maybe is not the best idea to commit this generic file in the
neutron folder.

any advice how to handle this ? what is the accepted python import strategy ?

thanks

Saverio

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

Re: [Openstack-operators] CentOS 7.3 libvirt appears to be broken for virtio-scsi and ceph with cephx auth

[Arne Wiebalck]

From the quoted mail thread and a quick test I just did it seems that this 
issue only affects virtio-scsi, not virtio-blk.
Does anyone know if that is correct?

Thanks!
 Arne 

> On 20 Dec 2016, at 17:57, Mike Lowe  wrote:
> 
> I got a rather nasty surprise upgrading from CentOS 7.2 to 7.3.  As far as I 
> can tell the libvirt 2.0.0 that ships with 7.3 doesn’t behave the same way as 
> the 1.2.17 that ships with 7.2 when using ceph with cephx auth during volume 
> attachment using virtio-scsi.  It looks like it fails to add the cephx 
> secret.  The telltale signs are "No secret with id 'scsi0-0-0-1-secret0’” in 
> the /var/log/libvirt/qemu instance logs.  I’ve filed a bug here 
> https://bugzilla.redhat.com/show_bug.cgi?id=1406442 and there is a libvirt 
> mailing list  thread about a fix for libvirt 2.5.0 for what looks like this 
> same problem 
> https://www.redhat.com/archives/libvir-list/2016-October/msg00396.html  I’m 
> out of ideas for workarounds having had kind of a disastrous attempt at 
> downgrading to libvirt 1.2.17, so if anybody has any suggestions I’m all 
> ears.  
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--
Arne Wiebalck
CERN IT

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

Re: [openstack-dev] [picasso] Picasso (FaaS) project release!

[Steven Dake (stdake)]

Derek,

I think Serverless is a great idea.  I had considered starting a new project in 
October around Serverless.  During my analysis I of course saw iron.io’s work 
and OpenWhisk.  I thought OpenWhisk would be a better community to join as it 
was open.  Iron.io and OpenWhisk should join forces!  That may be challenging, 
as OpenWhisk is an apache project and OpenStack doesn’t have Scala 
infrastructure for a language choice.

If you do plan to enter the big tent with this code base, I’d have a read of:
https://github.com/openstack/governance/blob/master/reference/new-projects-requirements.rst

Best wishes for success for OpenWhisk+Iron.io!,
-steve

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

Date: Tuesday, December 20, 2016 at 11:27 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [picasso] Picasso (FaaS) project release!


Hi all,

I’m very pleased to announce a new project, Picasso[1][2] - Functions as a 
Service (FaaS).

The mission is to provide an API for running FaaS on OpenStack, abstracting 
away the infrastructure layer while enabling simplicity, efficiency and 
scalability for both developers and operators.

Picasso can be used to trigger functions from OpenStack services, such as 
Telemetry (via HTTP callback) or Swift notifications. This means no long 
running applications, as functions are only executed when called.

Picasso is comprised of two main components:

  *   Picasso API

 *   The Picasso API server uses Keystone authentication and authorization 
through its middleware.

  *   IronFunctions

 *   Picasso leverages the backend container engine provided by 
IronFunctions, an open-source 
Serverless/FaaS platform based on Docker.

Resources

  *   Wiki

 *   https://wiki.openstack.org/wiki/Picasso

  *   Architecture

 *   Picasso deployment 
architecture
 *   Picasso/IronFunctions inter-component 
architecture

  *   Examples

 *   Triggering functions from Telemetry and 
Aodh
 *   Application that queries Nova for a list of running 
servers



We’ve created some initial blueprints 
to show what the future roadmap looks like for the project.

You can try out Picasso now on DevStack by following the quick start guide 
here.
 Let us know what you think!

If you’re interested in contributing or just have any questions, please join us 
on Slack at open-iron.slack.com.



[1] https://launchpad.net/picasso

[2] https://launchpad.net/python-picassoclient



Regards,

Derek Schultz
__
OpenStack Development Mailing 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] Removal of a core reviewer from the kolla-kubernetes-core team

[Steven Dake (stdake)]

Hey peeps,

David Wang asked that we remove him from the kolla-kubernetes-core team because 
he is involved in other activities and he isn’t sure if or when he will be able 
to begin reviewing again.

In our earlier cleanup of the kolla-kubernetes-core review team, the core 
reviewer team was on the fence about Dave because kolla-kubernetes wouldn’t 
have happened without him.  His contributions in terms of reviews and code are 
significant and Dave provided crucial implementation work and review guidance 
during the initial stages of kolla-kubernetes development.

I’d like to personally thank Dave for his service as a core reviewer for the 
kolla-kubernetes deliverable in the kolla project team.

Dave is always welcome back as a core reviewer and would likely receive a 
fast-track assuming his reviews were of the great quality they were prior to 
his changes in circumstances.

Regards,
-steve

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

[openstack-dev] [vitrage] no IRC meeting next week

[Afek, Ifat (Nokia - IL)]

Hi,

The next IRC meeting on December 28 will be canceled due to the holidays. We 
will meet again on Wednesday, January 4th.

Best Regards,
Ifat.

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

Re: [openstack-dev] [tacker] December 28th weekly meeting cancelled

[Kanagaraj Manickam]

Happy christmas & new year 2017.

Thanks & Regards
Kanagaraj M

On Dec 21, 2016 1:18 PM, "Sridhar Ramaswamy"  wrote:

We are skipping next week's Tacker meeting, on Dec 28th [1]. We will resume
on Jan 4th.

Happy Holidays!!

[1] http://eavesdrop.openstack.org/meetings/tacker/
2016/tacker.2016-12-21-05.30.log.html

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