Re: [openstack-dev] [telemetry] [ceilometer] [kilo] trouble reloading ceilometer pipeline

[ZhiQiang Fan]

changing pipeline only requires restart ceilometer-agent-compute or
ceilometer-agent-central service, no need to restart nova-compute or
ceilometer-collector

the question is not suitable for dev mailing list, and you have provided
too less info:
* what change do you made? paste the diff
* what do you expected after the change, and how are you sure it is
disregarded?

change polling rate functionality is solid, I have done such thing many
times and it never fail according to my observation

On Sun, May 22, 2016 at 9:50 PM, Rosensweig, Elisha (Nokia - IL) <
elisha.rosensw...@nokia.com> wrote:

> Hi All,
>
> I'm running with Kilo and I want to make changes to my ceilometer pipeline
> file (changing the rate of sampling, in this case). What I did was:
> (1) make the changes,
> (2) restart the ceilometer agents on the compute [service
> openstack-ceilometer-compute restart]
> (3) restart the nova agent [service openstack-nova-compute restart]
> (4) restart the collector [service openstack-ceilometer-collector restart]
>
> The changes are disregarded. What am I doing wrong?
>
> Thanks
>
> Elisha Rosensweig
>
> __
> OpenStack Development Mailing 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] [aodhclient] does the aodh have the feature for import/export batch alarms?

[ZhiQiang Fan]

batch alarm is not supported, and I think it is a burden instead of good
feature to implement it in aodh

import/export alarm is not supported, considering dump db and restore it in
new env? or you can get alarm list from old env and create new alarm in new
env via REST API if data set is not too large.

On Fri, May 20, 2016 at 9:37 AM,  wrote:

> HI All,
>
> in the aodh/aodhclient, I not find the feature for import/export
> batch alarms.
>
> I mainly want to use it to implement the following requirement:
> In "migrate alarms from one openstack env to another openstack
> env" scenario, I would like to do this requirement
>by a simple method, such as exporting/downloading the alarms from
> one env and then importing these alarms to a new env.
>
> currently, does the aodh have the similar command for
> import/export batch alarms?
> or does have an alternative method to implement this requirement?
> If not have, does the feature need to add in aodh/aodhclient?
>
> Rajen(liyuanzhen)
>
>
> 
> ZTE Information Security Notice: The information contained in this mail (and 
> any attachment transmitted herewith) is privileged and confidential and is 
> intended for the exclusive use of the addressee(s).  If you are not an 
> intended recipient, any disclosure, reproduction, distribution or other 
> dissemination or use of the information contained is strictly prohibited.  If 
> you have received this mail in error, please delete it and notify us 
> immediately.
>
>
>
>
__
OpenStack Development Mailing 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] Error when creating 2 event alarms with the same name

[ZhiQiang Fan]

Alarm name unique constraint is only applied to each project, I don't
remember the original cause, but in our customer's environment, alarm will
be showed in the portal, with their name, no uuid, because user will be
confused about such a random like string, then if alarm name can be
duplicated, it is hard for them to differ between alarms.

So is there particular reason why you need to create duplicate name? can it
be something like event-alarm-{event_type}-{seq_number} ?

Anyway, it is not so hard to remove this constraint, I just want to say
that alarm name should be meaningful, otherwise it makes no difference with
UUID: not human friendly.



On Tue, May 3, 2016 at 10:30 PM, Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi,
>
> First of all, I wanted to thank again to all the participants in the
> fruitful Aodh-Vitrage design session in Austin :)
>
> I wanted to show in this email, the problem that we have when creating 2
> event alarms with the same name.
> Here is what I got in the command line:
>
> stack@ubuntu-devstack:/etc/vitrage$ ceilometer
> alarm-list
>
> +--+--+---+--+-++-+--+
> | Alarm ID | Name | State | Severity | Enabled | Continuous | Alarm
> condition | Time constraints |
>
> +--+--+---+--+-++-+--+
>
> +--+--+---+--+-++-+--+
>
> stack@ubuntu-devstack:/etc/vitrage$ ceilometer alarm-event-create --name
> 'Event Alarm 2' --state alarm --event-type 'my.event'
> +---+--+
> | Property  | Value|
> +---+--+
> | alarm_actions | []   |
> | alarm_id  | 96f11384-abd7-4c11-b0a5-678646c11e79 |
> | description   | Alarm when my.event event occurred.  |
> | enabled   | True |
> | event_type| my.event |
> | insufficient_data_actions | []   |
> | name  | Event Alarm 2|
> | ok_actions| []   |
> | project_id| bec13d47c22e45a9948981f5cb1ba45b |
> | query | []   |
> | repeat_actions| False|
> | severity  | low  |
> | state | alarm|
> | type  | event|
> | user_id   | d8812494489546aca8341af184eddd2c |
> +---+--+
>
> stack@ubuntu-devstack:/etc/vitrage$ ceilometer alarm-list
>
> +--+---+---+--+-++--+--+
> | Alarm ID | Name  | State | Severity
> | Enabled | Continuous | Alarm condition  | Time constraints |
>
> +--+---+---+--+-++--+--+
> | 96f11384-abd7-4c11-b0a5-678646c11e79 | Event Alarm 2 | alarm | low
> | True| False  | query: []| None |
> |  |   |   |
> | || event_type: my.event |  |
>
> +--+---+---+--+-++--+--+
>
> stack@ubuntu-devstack:/etc/vitrage$ ceilometer alarm-event-create --name
> 'Event Alarm 2' --state alarm --event-type 'my.event'
> Alarm with name='Event Alarm 2' exists (HTTP 409) (Request-ID:
> req-b05dd105-fd23-47d3-a0b6-940bde6bcdd8)
>
>
> Do you think it is possible to drop the uniqueness of the alarm name in
> Aodh (for the Vitrage use cases that we talked about in the design session)?
>
> Best regards,
> Alexey Weyl
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Libvirt version requirement

[ZhiQiang Fan]

Glad to hear the news. Thanks, Daniel and Michael.

On Tue, May 3, 2016 at 5:19 PM, Daniel P. Berrange 
wrote:

> On Mon, May 02, 2016 at 11:27:01AM +0800, ZhiQiang Fan wrote:
> > Hi Nova cores,
> >
> > There is a spec[1] submitted to Telemetry project for Newton release,
> > mentioned that a new feature requires libvirt >= 1.3.4 , I'm not sure if
> > this will have bad impact to Nova service, so I open this thread and wait
> > for your opinions.
> >
> > [1]: https://review.openstack.org/#/c/311655/
>
> Nova's policy is that we pick a minimum requires libvirt that everyone
> must have, this is shown in this table
>
>
> https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix#Nova_release_min_version
>
> Nova will accept code changes which use features from a newer libvirt,
> as long as they don't cause breakage for people with older libvirt.
> Generally this means that we'll use newer libvirt features, only for
> features which are new to nova - we don't change existing Nova code
> to use new libvirt features, since that would cause regression.
>
> IOW, I don't see any problem with you using newer libvirt version,
> provided you gracefully fallback without error if run against the
> current min required libvirt Nova declares.
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] Libvirt version requirement

[ZhiQiang Fan]

Hi Nova cores,

There is a spec[1] submitted to Telemetry project for Newton release,
mentioned that a new feature requires libvirt >= 1.3.4 , I'm not sure if
this will have bad impact to Nova service, so I open this thread and wait
for your opinions.

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

Thanks!
ZhiQiang Fan
__
OpenStack Development Mailing 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] [Ceph][ceilometer][libvirt] Libvirt error during instance disk allocation metering

[ZhiQiang Fan]

Hi Ceph devs,

I raise this bug again because as Ceph becomes more popular, our customer
suffers from it and I have no solution for it.

*Is there anyway to get the usage of a disk which is a Ceph volume? (Not
sure if the term is right or not)*

Ceilometer use libvirt.domain.blockInfo(device) to get the usage
(allocation/physical/capacity) of a disk, [1]. This works fine when the VM
is boot from local file system, and according to the note from [2], it
seems blockInfo uses stat instead of querying qemu, so **maybe** this is
why it doesn't work for the network type disk: internal error: missing
storage backend for network files using rbd protocol.

libvirt.domain.blockStats() doesn't return usage but r/w bytes/requests,
 neither domainListGetStats

I haven't try virStorageVolInfo yet, because don't know the args, but it
doesn't return all the 3 usage dimension of a disk, only capacity and
allocation[3]

So I'm asking if anyone can help me to resolve this issue.
Thank you very much!

PS: change subject to get ceph devs noticed.

[1] https://review.openstack.org/#/c/145819/
[2]  https://www.redhat.com/archives/libvir-list/2014-December/msg00762.html

[3] https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolInfo
[4] https://bugs.launchpad.net/ceilometer/+bug/1457440

On Wed, Nov 18, 2015 at 11:46 PM, Ilya Tyaptin 
wrote:

> Hi, folks!
>
> In our deployed envs we met with a libvirt error *"missing storage
> backend for network files using rbd protocol"* in *virDomainGetBlockInfo*
>  call [1] 
> .
> This exception is raised when Ceilometer are trying to get info about VM
> disk usage and allocation.
> It only affects getting measures for a some disk pollsters which added in
> this CR [2]
> 
>  with specified libvirt call [3]
> 
>  .
> These pollsters have been added in the Kilo cycle and successful work in
> Kilo deployments, but it doesn't work now.
>
> Also, we have a bug in the upstream launchpad [4]
> 
>  but it have not been fixed yet.
>
> I would glad to see any ideas about root cause of this issue or ways to
> fixing it.
>
> Thank you in advance!
>
> References:
> [1] Traceback 
>
>
> ./ceilometer-polling.log.0:4192:2015-11-17 16:20:54.807 14107 ERROR
> ceilometer.compute.pollsters.disk Traceback (most recent call last):
> ./ceilometer-polling.log.0:4193:2015-11-17 16:20:54.807 14107 ERROR
> ceilometer.compute.pollsters.disk   File
> "/usr/lib/python2.7/dist-packages/ceilometer/compute/pollsters/disk.py",
> line 703, in get_samples
> ./ceilometer-polling.log.0:4194:2015-11-17 16:20:54.807 14107 ERROR
> ceilometer.compute.pollsters.disk instance,
> ./ceilometer-polling.log.0:4195:2015-11-17 16:20:54.807 14107 ERROR
> ceilometer.compute.pollsters.disk   File
> "/usr/lib/python2.7/dist-packages/ceilometer/compute/pollsters/disk.py",
> line 672, in _populate_cache
> ./ceilometer-polling.log.0:4196:2015-11-17 16:20:54.807 14107 ERROR
> ceilometer.compute.pollsters.disk for disk, info in disk_info:
> ./ceilometer-polling.log.0:4197:2015-11-17 16:20:54.807 14107 ERROR
> ceilometer.compute.pollsters.disk   File
> "/usr/lib/python2.7/dist-packages/ceilometer/compute/virt/libvirt/inspector.py",
> line 215, in inspect_disk_info
> ./ceilometer-polling.log.0:4198:2015-11-17 16:20:54.807 14107 ERROR
> ceilometer.compute.pollsters.disk block_info = domain.blockInfo(device)
> ./ceilometer-polling.log.0:4199:2015-11-17 16:20:54.807 14107 ERROR
> ceilometer.compute.pollsters.disk   File
> "/usr/lib/python2.7/dist-packages/libvirt.py", line 658, in blockInfo
> ./ceilometer-polling.log.0:4200:2015-11-17 16:20:54.807 14107 ERROR
> ceilometer.compute.pollsters.disk if ret is None: raise libvirtError
> ('virDomainGetBlockInfo() failed', dom=self)
> ./ceilometer-polling.log.0:4201:2015-11-17 16:20:54.807 14107 ERROR
> ceilometer.compute.pollsters.disk libvirtError: internal error: missing
> storage backend for network files using rbd protocol
>
> [2] CR with this commit:
> https://review.openstack.org/#/c/145819/23/ceilometer/compute/virt/libvirt/inspector.py,cm
>
> [3] Code entry:
> https://github.com/openstack/ceilometer/blob/stable/liberty/ceilometer/compute/virt/libvirt/inspector.py#L215
> [4] Upstream bug: https://bugs.launchpad.net/ceilometer/+bug/1457440
>
>
> Best regards,
>
> Tyaptin Il​y​a,
>
> Ceilometer developer,
>
> Mirantis Inc.
>
>
>
> __
> OpenStack Development Mailing 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] Devstack liberty with keystone v3

[ZhiQiang Fan]

Sorry, I didn't notice you're using liberty branch, that patch is for
master, not sure if it can be cherry-picked to stable/liberty

As Dolph Mathews pointed out, you're using keystoneclient.v2 to request to
keystone API v3, so it fails with 404, which command are you using?
``openstack catalog list`` ?

On Wed, Apr 27, 2016 at 1:34 AM, kiran vemuri UH  wrote:

> Hello Sean,
>
> I tried doing what you suggested and what  ZhiQiang Fan  suggested as
> well.
>
> But both of them give me similar error when I try to fetch keystone
> catalog.
>
> DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
> http://10.10.50.101:5000/v3/tokens
>
> INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
> (1): 10.10.50.101
>
> DEBUG:requests.packages.urllib3.connectionpool:"POST /v3/tokens HTTP/1.1"
> 404 93
>
> DEBUG:keystoneclient.session:Request returned failure status: 404
>
> Authorization Failed: The resource could not be found. (HTTP 404)
> (Request-ID: req-a2b71b1d-b58f-46c3-9e99-2837699a5750)
>
> --
>
> DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
> http://10.10.50.101:5000/v3/tokens
>
> INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
> (1): 10.10.50.101
>
> DEBUG:requests.packages.urllib3.connectionpool:"POST /v3/tokens HTTP/1.1"
> 404 93
>
> DEBUG:keystoneclient.session:Request returned failure status: 404
>
> Authorization Failed: The resource could not be found. (HTTP 404)
> (Request-ID: req-ff589197-07af-47bf-8d66-4cc575a12924)
>
> --
>
> Also, I am doubtful if openrc change result in all the services using v3?
>
> Thanks,
> Kiran Vemuri
>
>
> *kiran vemuri*
> www.kiranvemuri.info
> Tel: (832)-701-8281
> kkvem...@uh.edu
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-manuals] What the status of DocImpact

[ZhiQiang Fan]

Thanks, @Matt and @Doug, I agree that it's time to consider project holds
its document in its own repository. There is a gap between document team
and our projects source code, even though they are excellent and working
hard, but our source code is growing fast in the same time, this problem is
getting worse after we switch to Big Tent mode.

@Lana: The patch I submitted is modified via script tools, and I have
provided extra patch to fix our tools to make it better. Anyway, thank you
for your input. Cheers

ZhiQiang

On Wed, Apr 27, 2016 at 1:29 AM, Lana Brindley 
wrote:

> No trouble. Yes, the config changes should be picked up automatically. You
> can't edit those files in the book directly, as a script writes them.
> That's why your change would have been declined.
>
> Thanks for asking the question, though :)
>
> L
>
> On 24/04/16 11:12, ZhiQiang Fan wrote:
> > Hi Lana,
> >
> > Thank you for explaining it!
> >
> > Yes, I noticed that the DocImpact bug track now has shifted to project
> its own, that why I submit a change by using the tool in
> openstack-doc-tools, but that change is disagreed by a doc core. Meanwhile
> I also find that there is rarely change merged for config reference update.
> >
> > So I want to know is the config reference automatically updated so no
> more individual commit is required?
> >
> > Best Regards,
> >
> > On Sun, Apr 24, 2016 at 11:28 PM, Lana Brindley <
> openst...@lanabrindley.com <mailto:openst...@lanabrindley.com>> wrote:
> >
> > Hi ZhiQiang,
> >
> > I am not sure I understand your question. The only change to
> DocImpact is that now the bug is created in the project's bug queue, not
> OpenStack manuals. There is no other automation for DocImpact.
> >
> > For the config ref, there is a script that we run to get any new
> changes. That will happen whether or not there is a DocImpact bug.
> >
> > Does that answer your question?
> >
> > Thanks,
> > Lana
> >
> > On 23/04/16 19:00, ZhiQiang Fan wrote:
> > > Hi Doc Team,
> > >
> > > I want to know the recent status of DocImpact tag, is it
> deprecated for config option changes now? If it's true, then what the
> workflow for config reference now, any hint or link?
> > >
> > > Previously, when a patch has impact to document, including config
> option changes, I usually ask contributors to add a DocImpact, hence there
> will be a bug track the document issue.
> > >
> > > Recently, a patch lands in Ceilometer which adds two new options,
> and Ceilometer receives the auto created document bug. However, when I
> submit a patch to openstack-manuals to fix it, I was told by a core that
> such change is not needed any more, I searched latest merged patch in
> openstack-manuals and found what he said is true, but still don't know why
> and what action I should follow in Ceilometer/Aodh projects
> > >
> > > Thank you very much!
> > >
> > > ZhiQiang Fan
> > >
> > >
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > --
> > Lana Brindley
> > Technical Writer
> > Rackspace Cloud Builders Australia
> > http://lanabrindley.com
> >
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <
> http://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
> >
>
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Devstack liberty with keystone v3

[ZhiQiang Fan]

what you need is this patch: https://review.openstack.org/#/c/307574/

after install finished, to use admin:demo account and v3 API, run ``source
openrc -k3 admin``, then it is done.

Cheers!

On Tue, Apr 26, 2016 at 7:10 AM, kiran vemuri UH  wrote:

> Hello All,
>
> I recently got started with OpenStack with a goal of bringing up a multi
> region setup i.e., 2 regions using the same keystone service.
>
> I started with devstack liberty stable release by following the
> documentation available at:
> http://docs.openstack.org/developer/devstack/#configuration
>
> I am able to bring up the liberty but it boots with keystone v2 as
> default. Could anyone please point me to the documentation on how to enable
> keystone v3?
>
> I tried making changes to local.conf file with the following parameters.
>
> ENABLE_IDENTITY_V2=False
> IDENTITY_API_VERSION=3
> OS_IDENTITY_API_VERSION=3
> DEFAULT_DOMAIN=default
>
> but, everytime I do unstack and stack, it results in error similar to this
> https://bugs.launchpad.net/devstack/+bug/1490950
>
> I also tried solutions listed in the above bug.. but nothing helped.
>
> Could anyone help me out with this?
>
> Thanks,
> Kiran Vemuri
>
> *kiran vemuri*
> www.kiranvemuri.info
> Tel: (832)-701-8281
> kkvem...@uh.edu
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-manuals] What the status of DocImpact

[ZhiQiang Fan]

Thank you, Sir!

On Mon, Apr 25, 2016 at 2:25 AM, Andreas Jaeger  wrote:

> On 04/24/2016 11:12 AM, ZhiQiang Fan wrote:
>
>> Hi Lana,
>>
>> Thank you for explaining it!
>>
>> Yes, I noticed that the DocImpact bug track now has shifted to project
>> its own, that why I submit a change by using the tool in
>> openstack-doc-tools, but that change is disagreed by a doc core.
>> Meanwhile I also find that there is rarely change merged for config
>> reference update.
>>
>> So I want to know is the config reference automatically updated so no
>> more individual commit is required?
>>
>
> If you just care about updating the tables: The docs team does it at
> regular levels, no need for a bug report.
>
> If you want to help and regenerate all tables for a project, that is also
> welcome.
>
> Keep in mind that we have no mitaka branch yet. So, our master branch
> targets mitaka at the moment. Please hold back any Newton related changes
> for the configuration reference,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-manuals] What the status of DocImpact

[ZhiQiang Fan]

Hi Lana,

Thank you for explaining it!

Yes, I noticed that the DocImpact bug track now has shifted to project its
own, that why I submit a change by using the tool in openstack-doc-tools,
but that change is disagreed by a doc core. Meanwhile I also find that
there is rarely change merged for config reference update.

So I want to know is the config reference automatically updated so no more
individual commit is required?

Best Regards,

On Sun, Apr 24, 2016 at 11:28 PM, Lana Brindley 
wrote:

> Hi ZhiQiang,
>
> I am not sure I understand your question. The only change to DocImpact is
> that now the bug is created in the project's bug queue, not OpenStack
> manuals. There is no other automation for DocImpact.
>
> For the config ref, there is a script that we run to get any new changes.
> That will happen whether or not there is a DocImpact bug.
>
> Does that answer your question?
>
> Thanks,
> Lana
>
> On 23/04/16 19:00, ZhiQiang Fan wrote:
> > Hi Doc Team,
> >
> > I want to know the recent status of DocImpact tag, is it deprecated for
> config option changes now? If it's true, then what the workflow for config
> reference now, any hint or link?
> >
> > Previously, when a patch has impact to document, including config option
> changes, I usually ask contributors to add a DocImpact, hence there will be
> a bug track the document issue.
> >
> > Recently, a patch lands in Ceilometer which adds two new options, and
> Ceilometer receives the auto created document bug. However, when I submit a
> patch to openstack-manuals to fix it, I was told by a core that such change
> is not needed any more, I searched latest merged patch in openstack-manuals
> and found what he said is true, but still don't know why and what action I
> should follow in Ceilometer/Aodh projects
> >
> > Thank you very much!
> >
> > ZhiQiang Fan
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-manuals] What the status of DocImpact

[ZhiQiang Fan]

but Document Team has so beautiful tables, and so convenient tools
, it is a huge waste of resource if we manually write
it to release note in each project.

So I want to figure out what have happened to prevent Document Team
continuing previous workflow.

Thanks

On Sun, Apr 24, 2016 at 8:54 PM, Doug Hellmann 
wrote:

> Excerpts from ZhiQiang Fan's message of 2016-04-24 08:00:10 +0800:
> > Hi Doc Team,
> >
> > I want to know the recent status of DocImpact tag, is it deprecated for
> > config option changes now? If it's true, then what the workflow for
> config
> > reference now, any hint or link?
> >
> > Previously, when a patch has impact to document, including config option
> > changes, I usually ask contributors to add a DocImpact, hence there will
> be
> > a bug track the document issue.
> >
> > Recently, a patch lands in Ceilometer which adds two new options, and
> > Ceilometer receives the auto created document bug. However, when I
> submit a
> > patch to openstack-manuals to fix it, I was told by a core that such
> change
> > is not needed any more, I searched latest merged patch in
> openstack-manuals
> > and found what he said is true, but still don't know why and what action
> I
> > should follow in Ceilometer/Aodh projects
> >
> > Thank you very much!
> >
> > ZhiQiang Fan
>
> I recommend at a minimum including a release note using reno in the
> patch changing any configuration options (adding, deprecating, changing
> defaults, etc.).
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-manuals] What the status of DocImpact

[ZhiQiang Fan]

Hi Doc Team,

I want to know the recent status of DocImpact tag, is it deprecated for
config option changes now? If it's true, then what the workflow for config
reference now, any hint or link?

Previously, when a patch has impact to document, including config option
changes, I usually ask contributors to add a DocImpact, hence there will be
a bug track the document issue.

Recently, a patch lands in Ceilometer which adds two new options, and
Ceilometer receives the auto created document bug. However, when I submit a
patch to openstack-manuals to fix it, I was told by a core that such change
is not needed any more, I searched latest merged patch in openstack-manuals
and found what he said is true, but still don't know why and what action I
should follow in Ceilometer/Aodh projects

Thank you very much!

ZhiQiang Fan
__
OpenStack Development Mailing 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] [Telemetry][Ceilometer][Aodh] Clean crazy old bugs and patches

[ZhiQiang Fan]

Hi devs,

Recently I'm cleaning bugs and reviews of Ceilometer+Aodh, some out dated
bugs, long time (two months) no active reviews, assignments will be
removed. If you are the owner or just interest in it, please provide new
information or follow ups, to let them alive again.

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

Re: [openstack-dev] [oslo][keystone][documentation][gate] Babel dependency for oslo.log

[ZhiQiang Fan]

Thanks for the confirm.

On Thu, Apr 21, 2016 at 7:44 PM, Andreas Jaeger  wrote:

> On 2016-04-21 13:22, ZhiQiang Fan wrote:
> > Hi Andreas,
> >
> > so if some projects, such as ceilometer, need babel even if they don't
> > directly depend on it, just because they are setup in infra for
> > translations?
> >
> > can you explain a bit more to me, or just provide some links, or
> > keywords for search ?
>
>
> What I'm saying is: If your repository is translated, you do need Babel
> - either directly (not preferred) or indirectly vai oslo.i18n (preferred).
>
> Ceilometer is translated and uses olso.i18n. The extra requirement on
> Babel in ceilometer/test-requirements is not really needed.
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [devstack] Adding example "local.conf" files for testing?

[ZhiQiang Fan]

+1
more example and documentation are welcomed

On Tue, Apr 19, 2016 at 3:10 AM, John Griffith 
wrote:

>
>
> On Thu, Apr 14, 2016 at 1:31 AM, Markus Zoeller 
> wrote:
>
>> Sometimes (especially when I try to reproduce bugs) I have the need
>> to set up a local environment with devstack. Everytime I have to look
>> at my notes to check which option in the "local.conf" have to be set
>> for my needs. I'd like to add a folder in devstacks tree which hosts
>> multiple example local.conf files for different, often used setups.
>> Something like this:
>>
>> example-confs
>> --- newton
>> --- --- x86-ubuntu-1404
>> --- --- --- minimum-setup
>> --- --- --- --- README.rst
>> --- --- --- --- local.conf
>> --- --- --- serial-console-setup
>> --- --- --- --- README.rst
>> --- --- --- --- local.conf
>> --- --- --- live-migration-setup
>> --- --- --- --- README.rst
>> --- --- --- --- local.conf.controller
>> --- --- --- --- local.conf.compute1
>> --- --- --- --- local.conf.compute2
>> --- --- --- minimal-neutron-setup
>> --- --- --- --- README.rst
>> --- --- --- --- local.conf
>> --- --- s390x-1.1.1-vulcan
>> --- --- --- minimum-setup
>> --- --- --- --- README.rst
>> --- --- --- --- local.conf
>> --- --- --- live-migration-setup
>> --- --- --- --- README.rst
>> --- --- --- --- local.conf.controller
>> --- --- --- --- local.conf.compute1
>> --- --- --- --- local.conf.compute2
>> --- mitaka
>> --- --- # same structure as master branch. omitted for brevity
>> --- liberty
>> --- --- # same structure as master branch. omitted for brevity
>>
>> Thoughts?
>>
>> Regards, Markus Zoeller (markus_z)
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> ​Love the idea personally.  Maybe we could start with a working Neutron
> multi node deployment!!!​
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][keystone][documentation][gate] Babel dependency for oslo.log

[ZhiQiang Fan]

Hi Andreas,

so if some projects, such as ceilometer, need babel even if they don't
directly depend on it, just because they are setup in infra for
translations?

can you explain a bit more to me, or just provide some links, or keywords
for search ?

Thanks
ZhiQiang

On Tue, Apr 19, 2016 at 2:34 PM, Andreas Jaeger  wrote:

> On 2016-04-18 22:34, Davanum Srinivas wrote:
> > On Mon, Apr 18, 2016 at 4:28 PM, Joshua Harlow 
> wrote:
> >> Okie, the following reviews are up:
> >>
> >> https://review.openstack.org/307461 (oslo.concurrency)
> >> https://review.openstack.org/307463 (oslo.cache)
> >> https://review.openstack.org/307464 (oslo.privsep)
> >> https://review.openstack.org/307466 (oslo.middleware)
> >> https://review.openstack.org/307467 (oslo.log)
> >> https://review.openstack.org/307468 (oslo.db)
> >> https://review.openstack.org/307469 (oslo.versionedobjects)
> >> https://review.openstack.org/307470 (oslo.service)
> >> https://review.openstack.org/307471 (oslo.reports)
> >>
> >> Do note that the following have a dependency on babel but do not depend
> on
> >> oslo.il8n:
> >>
> >> tooz
> >> oslo.context
> >> oslo.serialization
> >> debtcollector
>
> And none of them is setup in infra for translations, so Babel can be
> removed,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][barbican][designate][murano][fuel][ironic][cue][ceilometer][astara][gce-api][kiloeyes] keystoneclient 3.0.0 release - no more CLI!

[ZhiQiang Fan]

barbican fix: https://review.openstack.org/#/c/247810/
but no patch update since Nov 20

On Tue, Apr 19, 2016 at 7:59 AM, ZhiQiang Fan  wrote:

> ironic fix: https://review.openstack.org/307523
>
> On Tue, Apr 19, 2016 at 7:50 AM, ZhiQiang Fan  wrote:
>
>> ceilometer fix: https://review.openstack.org/307521
>>
>> On Tue, Apr 19, 2016 at 4:05 AM, Steve Martinelli 
>> wrote:
>>
>>> Everyone,
>>>
>>> I sent out a note about this on Friday [1], but I'll repeat it here and
>>> tag individual projects. The keystone team *will* be releasing a new
>>> version of keystoneclient on *Thursday* that will not include a CLI.
>>>
>>> A quick codesearch showed that a few projects are still using the old
>>> `keystone` CLI in either their docs, scripts that create sample data or in
>>> devstack plugins; the latter being the more immediate issue here. These
>>> fixes should be very quick, use `openstackclient` CLI instead. I've gone
>>> ahead and created a listed off some files that include a keystone CLI
>>> command (keystone user-list, keystone tenant-list, keystone user-create,
>>> keystone role-list, etc )
>>>
>>> Barbican:
>>>
>>> http://git.openstack.org/cgit/openstack/barbican/tree/bin/keystone_data.sh
>>>
>>> Designate:
>>>
>>> http://git.openstack.org/cgit/openstack/designate/tree/tools/designate-keystone-setup
>>> (already being addressed by: https://review.openstack.org/307433 )
>>>
>>> Murano:
>>>
>>> http://git.openstack.org/cgit/openstack/murano-deployment/tree/murano-ci/config/devstack/local.sh
>>>
>>> Fuel:
>>>
>>> http://git.openstack.org/cgit/openstack/fuel-plugin-plumgrid/tree/deployment_scripts/cleanup_os.sh
>>>
>>> http://git.openstack.org/cgit/openstack/fuel-octane/tree/octane/tests/create_vms.sh
>>>
>>> http://git.openstack.org/cgit/openstack/fuel-plugin-plumgrid/tree/deployment_scripts/cleanup_os.sh
>>>
>>> Ironic:
>>>
>>> http://git.openstack.org/cgit/openstack/ironic-inspector/tree/devstack/exercise.sh#n49
>>>
>>> Cue:
>>> http://git.openstack.org/cgit/openstack/cue/tree/devstack/plugin.sh
>>>
>>> Ceilometer:
>>>
>>> http://git.openstack.org/cgit/openstack/ceilometer/tree/tools/make_test_data.sh
>>>
>>> Astara:
>>>
>>> http://git.openstack.org/cgit/openstack/astara/tree/tools/run_functional.sh
>>>
>>> GCE-API:
>>> http://git.openstack.org/cgit/openstack/gce-api/tree/install.sh
>>>
>>> Kiloeyes:
>>> http://git.openstack.org/cgit/openstack/kiloeyes/tree/setup_horizon.sh
>>>
>>> [1]
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-April/092471.html
>>>
>>> Thanks,
>>>
>>> Steve Martinelli
>>> OpenStack Keystone Project Team Lead
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][barbican][designate][murano][fuel][ironic][cue][ceilometer][astara][gce-api][kiloeyes] keystoneclient 3.0.0 release - no more CLI!

[ZhiQiang Fan]

ironic fix: https://review.openstack.org/307523

On Tue, Apr 19, 2016 at 7:50 AM, ZhiQiang Fan  wrote:

> ceilometer fix: https://review.openstack.org/307521
>
> On Tue, Apr 19, 2016 at 4:05 AM, Steve Martinelli 
> wrote:
>
>> Everyone,
>>
>> I sent out a note about this on Friday [1], but I'll repeat it here and
>> tag individual projects. The keystone team *will* be releasing a new
>> version of keystoneclient on *Thursday* that will not include a CLI.
>>
>> A quick codesearch showed that a few projects are still using the old
>> `keystone` CLI in either their docs, scripts that create sample data or in
>> devstack plugins; the latter being the more immediate issue here. These
>> fixes should be very quick, use `openstackclient` CLI instead. I've gone
>> ahead and created a listed off some files that include a keystone CLI
>> command (keystone user-list, keystone tenant-list, keystone user-create,
>> keystone role-list, etc )
>>
>> Barbican:
>> http://git.openstack.org/cgit/openstack/barbican/tree/bin/keystone_data.sh
>>
>> Designate:
>>
>> http://git.openstack.org/cgit/openstack/designate/tree/tools/designate-keystone-setup
>> (already being addressed by: https://review.openstack.org/307433 )
>>
>> Murano:
>>
>> http://git.openstack.org/cgit/openstack/murano-deployment/tree/murano-ci/config/devstack/local.sh
>>
>> Fuel:
>>
>> http://git.openstack.org/cgit/openstack/fuel-plugin-plumgrid/tree/deployment_scripts/cleanup_os.sh
>>
>> http://git.openstack.org/cgit/openstack/fuel-octane/tree/octane/tests/create_vms.sh
>>
>> http://git.openstack.org/cgit/openstack/fuel-plugin-plumgrid/tree/deployment_scripts/cleanup_os.sh
>>
>> Ironic:
>>
>> http://git.openstack.org/cgit/openstack/ironic-inspector/tree/devstack/exercise.sh#n49
>>
>> Cue:
>> http://git.openstack.org/cgit/openstack/cue/tree/devstack/plugin.sh
>>
>> Ceilometer:
>>
>> http://git.openstack.org/cgit/openstack/ceilometer/tree/tools/make_test_data.sh
>>
>> Astara:
>>
>> http://git.openstack.org/cgit/openstack/astara/tree/tools/run_functional.sh
>>
>> GCE-API:
>> http://git.openstack.org/cgit/openstack/gce-api/tree/install.sh
>>
>> Kiloeyes:
>> http://git.openstack.org/cgit/openstack/kiloeyes/tree/setup_horizon.sh
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2016-April/092471.html
>>
>> Thanks,
>>
>> Steve Martinelli
>> OpenStack Keystone Project Team Lead
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][barbican][designate][murano][fuel][ironic][cue][ceilometer][astara][gce-api][kiloeyes] keystoneclient 3.0.0 release - no more CLI!

[ZhiQiang Fan]

ceilometer fix: https://review.openstack.org/307521

On Tue, Apr 19, 2016 at 4:05 AM, Steve Martinelli 
wrote:

> Everyone,
>
> I sent out a note about this on Friday [1], but I'll repeat it here and
> tag individual projects. The keystone team *will* be releasing a new
> version of keystoneclient on *Thursday* that will not include a CLI.
>
> A quick codesearch showed that a few projects are still using the old
> `keystone` CLI in either their docs, scripts that create sample data or in
> devstack plugins; the latter being the more immediate issue here. These
> fixes should be very quick, use `openstackclient` CLI instead. I've gone
> ahead and created a listed off some files that include a keystone CLI
> command (keystone user-list, keystone tenant-list, keystone user-create,
> keystone role-list, etc )
>
> Barbican:
> http://git.openstack.org/cgit/openstack/barbican/tree/bin/keystone_data.sh
>
> Designate:
>
> http://git.openstack.org/cgit/openstack/designate/tree/tools/designate-keystone-setup
> (already being addressed by: https://review.openstack.org/307433 )
>
> Murano:
>
> http://git.openstack.org/cgit/openstack/murano-deployment/tree/murano-ci/config/devstack/local.sh
>
> Fuel:
>
> http://git.openstack.org/cgit/openstack/fuel-plugin-plumgrid/tree/deployment_scripts/cleanup_os.sh
>
> http://git.openstack.org/cgit/openstack/fuel-octane/tree/octane/tests/create_vms.sh
>
> http://git.openstack.org/cgit/openstack/fuel-plugin-plumgrid/tree/deployment_scripts/cleanup_os.sh
>
> Ironic:
>
> http://git.openstack.org/cgit/openstack/ironic-inspector/tree/devstack/exercise.sh#n49
>
> Cue:
> http://git.openstack.org/cgit/openstack/cue/tree/devstack/plugin.sh
>
> Ceilometer:
>
> http://git.openstack.org/cgit/openstack/ceilometer/tree/tools/make_test_data.sh
>
> Astara:
> http://git.openstack.org/cgit/openstack/astara/tree/tools/run_functional.sh
>
> GCE-API:
> http://git.openstack.org/cgit/openstack/gce-api/tree/install.sh
>
> Kiloeyes:
> http://git.openstack.org/cgit/openstack/kiloeyes/tree/setup_horizon.sh
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-April/092471.html
>
> Thanks,
>
> Steve Martinelli
> OpenStack Keystone Project Team Lead
>
> __
> OpenStack Development Mailing 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] Our Install Guides Only Cover Defcore - What about big tent?

[ZhiQiang Fan]

Agree.

Install guide is just a start/example, concentrate is better than cover
all, for more services we can just provide a good place to let them
discoverable, and lfor arger scale, we should use advanced tools such as
puppet and ansible

On Mon, Apr 4, 2016 at 6:12 PM, Thierry Carrez 
wrote:

> Doug Hellmann wrote:
>
>> [...]
>>> We would love to add all sufficiently mature projects to the installation
>>> guide because it increases visibility and adoption by operators, but we
>>> lack resources to develop a source installation mechanism that retains as
>>> much simplicity as possible for our audience.
>>>
>>
>> I think it would be a big mistake to try to create one guide for
>> installing all OpenStack projects. As you say, testing what we have
>> now is already a monumental task and impedes your ability to make
>> changes.  Adding more projects, with ever more dependencies and
>> configuration issues to the work the same team is doing would bury
>> the current documentation team. So I think focusing on the DefCore
>> list, or even a smaller list of projects with tight installation
>> integration requirements, makes sense for the team currently producing
>> the installation guide.
>>
>
> Yes, the base install guide should ideally serve as a reference to reach
> that first step where you have all the underlying services (MySQL, Rabbit)
> and a base set of functionality (starterkit:compute ?) installed and
> working. That is where we need high-quality, proactively-checked, easy to
> understand content.
>
> Then additional guides (ideally produced by each project team with tooling
> and mentoring from the docs team) can pick up from that base first step,
> assuming their users have completed that first step successfully.
>
> --
> Thierry Carrez (ttx)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Adding Custom Meters in Kilo Ceilometer

[ZhiQiang Fan]

basically, you need to inherit the base class and impl the get_samples
interface, then registry it in setup.cfg.

see an example in kilo: https://review.openstack.org/#/c/145819/  this
patch adds some new meters polling by compute agent

On Tue, Mar 29, 2016 at 3:29 PM, Murali Krishna  wrote:

>
>
> Hi Team,
>
>
> Anyone please help on writing a custom meters in open-stack kilo
> version.
>
>
> I tried going through many docs, but i couldn't find out any
> hint. please guide me how to customize it as per new parameters.
>
>
> Thanks in Advance [image: 😊] [image: 😊] [image:
> 😊] [image: 😊] [image: 😊]
>
>
> Thanks & Regards,
>
> Murali Krishna R
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [telemetry] Rescheduling IRC meetings

[ZhiQiang Fan]

+1 to demand meetings and asynchronous way

On Thu, Mar 31, 2016 at 9:33 PM, Ildikó Váncsa 
wrote:

> Hi Gordon,
>
> >
> > ie. the new PTL should checkpoint with subteam leads regularly to review
> spec status or identify missing resources on high-priority
> > items?
>
> I would say anything that we feel as useful information to people who read
> this mailing list. In this sense features that got implemented, items we
> are focusing on, as you mentioned resource bottlenecks on important items,
> etc.
>
> >
> > as some feedback, re: news flash mails, we need a way to promote roadmap
> backlog items better. i'm not sure anyone looks at Road
> > Map page...
> > maybe we need to organise it better with priority and incentive.
>
> I had the Roadmap page in mind as well partially, we could highlight the
> plans/tasks from that page and also track progress.
>
> Thanks,
> /Ildikó
>
> >
> > On 31/03/2016 7:14 AM, Ildikó Váncsa wrote:
> > > Hi All,
> > >
> > > +1 on the on demand meeting schedule. Maybe we can also have some news
> flash mails  week to summarize the progress in our
> > sub-modules when we don't have the meeting. Just to keep people up to
> date.
> > >
> > > Will we already skip the today's meeting?
> > >
> > > Thanks,
> > > /Ildikó
> > >
> > >> -Original Message-
> > >> From: Julien Danjou [mailto:jul...@danjou.info]
> > >> Sent: March 31, 2016 11:04
> > >> To: liusheng
> > >> Cc: openstack-dev@lists.openstack.org
> > >> Subject: Re: [openstack-dev] [telemetry] Rescheduling IRC meetings
> > >>
> > >> On Thu, Mar 31 2016, liusheng wrote:
> > >>
> > >>> Another personal suggestion:
> > >>>
> > >>> maybe we can have a weekly routine mail thread to present the things
> > >>> need to be discussed or need to be notified. The mail will also list
> > >>> the topics posted in meeting agenda and ask to Telemetry folks if  a
> > >>> online IRC meeting is necessary, if there are a very few topics or
> > >>> low priority topics, or the topics can be suitably discussed
> > >>> asynchronously, we can disuccs them in the mail thread.
> > >>>
> > >>> any thoughts?
> > >>
> > >> Yeah I think it's more or less the same idea that was proposed,
> > >> schedule a meeting only if needed. I'm going to amend the meeting
> wiki page with that!
> > >>
> > >> --
> > >> 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
> > >
> >
> > --
> > 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 Development Mailing 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] [vitrage] Gerrit Upgrade 12/16

[ZhiQiang Fan]

thanks for the effort, new feature is welcomed

but the new UI is really worse than the old one, it is not only related to
habit, it is just ugly, for the first view I thought it has css bug.

And it is not easy to find out current review status, old UI has a clear
and nice table for review list

On Thu, Dec 17, 2015 at 6:24 PM, Marc Koderer  wrote:

> +1 I am also very confused about the new UI.. but maybe it takes time to
> get use to it.
>
> Regards
> Marc
>
> Am 17.12.2015 um 10:55 schrieb Mohan Kumar :
>
> > Eugene:  +1 , Old Gerrit page was better than new one . Please fix
> >
> > On Thu, Dec 17, 2015 at 2:11 PM, Eugene Nikanorov <
> enikano...@mirantis.com> wrote:
> > I'm sorry to say that, but the new front page design is horrible and
> totally confusing.
> >
> > I hope it'll change soon in the new release.
> >
> > E.
> >
> >
> > On Tue, Dec 15, 2015 at 10:53 AM, AFEK, Ifat (Ifat) <
> ifat.a...@alcatel-lucent.com> wrote:
> > Hi,
> >
> > Reminder: Gerrit upgrade is scheduled for tomorrow at 17:00 UTC.
> >
> > Ifat.
> >
> >
> > -Original Message-
> > From: Spencer Krum [mailto:n...@spencerkrum.com]
> > Sent: Monday, December 14, 2015 9:53 PM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] Gerrit Upgrade 12/16
> >
> > This is a gentle reminder that the downtime will be this Wednesday
> starting at 17:00 UTC.
> >
> > Thank you for your patience,
> > Spencer
> >
> > --
> >   Spencer Krum
> >   n...@spencerkrum.com
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __
> > OpenStack Development Mailing 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] [aodh] HBase gate job

[ZhiQiang Fan]

I prefer to deprecate all drivers except sql, but the upgrade issue
requires us providing some tools to migrate those existent data

On Tue, Nov 17, 2015 at 6:10 PM, Julien Danjou  wrote:

> Hi,
>
> So we recently decided to run the functional tests for the HBase driver
> and enabled the gate job. It turned out the gate job didn't worked, so I
> tried to fix it. Now it's almost fixed, and it run the functional tests
> and Gabbi tests against Aodh with HBase as a back-end:
>
>   https://review.openstack.org/#/c/245585/
>
> Obviously, as you know this is not a real HBase back-end, but a
> in-memory backend that is provided inside Aodh. Now, it turns out that
> this driver or this in-memory backend has a bug, as the Gabbi tests
> fail.
>
> I don't have time nor interest to fix that, so the way I see it it's
> either:
> 1. Someone stands up, determines if the issue is in the driver or the
>in-memory implementation and fix it
> 2. Nobody cares and we drop HBase gate and deprecates the driver
>
> If nobody stands up in the next week, I'll start working on 2.
>
> --
> 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 Development Mailing 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] proposal to add Rohit Jaiswal to Ceilometer core

[ZhiQiang Fan]

+1

On Thu, Nov 5, 2015 at 9:45 PM, gord chung  wrote:

> hi folks,
>
> i'd like to nominate Rohit Jaiswal as core for Ceilometer. he's done a lot
> of good work recently like discovering and fixing many issues with Events
> and implemented the configuration reloading functionality. he's also been
> very active providing input and fixes for many bugs.
>
> as we've been doing, please vote here:
> https://review.openstack.org/#/c/242058/
>
> reviews:
>
> https://review.openstack.org/#/q/reviewer:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/ceilometer,n,z
>
> patches:
>
> https://review.openstack.org/#/q/owner:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/ceilometer,n,z
>
> https://review.openstack.org/#/q/owner:%22Rohit+Jaiswal+%253Crohit.jaiswal%2540hp.com%253E%22+project:openstack/python-ceilometerclient,n,z
>
> cheers,
>
> --
> gord
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo.config] MultiStrOpt VS. ListOpt

[ZhiQiang Fan]

Hi, devs

I come across a problem that crudini cannot handle MultiStrOpt[1], I don't
know why such type configuration option is needed. It seems ListOpt is a
better choice. Currently I find lots of MultiStrOpt options in both Nova
and Ceilometer, and I think other projects have too.

Here are my questions:

1) how can I update such type of option without manually rewrite the config
file? (like devstack scenario)
2) Is there any way to migrate MultiStrOpt to ListOpt? The ListOpt will
take last specified value while MultiStrOpt takes all, so the compatibility
is a big problem

Any hints?

Thanks!

[1]
https://github.com/pixelb/crudini/blob/6c7cb8330d2b3606610af20c767433358c8d20ab/TODO#L19
__
OpenStack Development Mailing 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] time based auto scaling

[ZhiQiang Fan]

Hi devs,

I'm thinking to add new type of alarm for time based auto scaling, but not
sure if there is a better way to achieve it outside ceilometer scope

Currently we can auto scaling based on vm load, but it will take several
minutes to do it. For the worst case, when the vm load is heavy, ceilometer
needs 10 minutes (by default) to collect the performance data, and alarm
need 1 minutes to evaluate it, maybe there is evaluation_periods which set
to higher that 1 to avoid performance peak.

So even though we can collect data by 1 minutes, but evaluation periods may
be set to 3, so the worst case is after vm load perfomance in high level
for 4 minutes, then the alarm is triggered, then heat will expand vm count,
nova will take dozens seconds or more to create, finally the service on the
in the heat server group will performance bad or unavailable for several
minutes, which is not acceptable for some critical applications.

But if we can know some high load which related with time, for example,
08:00am will be a peak, and after 22:00pm will definitely drop to idel
level, then heat can increase some vms at 07:30am, then decrease some vms
at 22:00 (or decrease by load as normal routine)

However, current ceilometer only provide time constraint alarm, which will
only evaluate but not guarantee it will be triggered. And heat cannot
provide something like timer, but just can wait for the signal.

So I propose to add a new type of alarm, which will definitely send a
signal to action when it is evaluated (with or without repeat, it will work
well with time constraint)

Any suggestion?
__
OpenStack Development Mailing 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] Stepping down as PTL

[ZhiQiang Fan]

Thanks for your great work!

On Fri, Apr 3, 2015 at 10:18 PM, Doug Hellmann 
wrote:

> Excerpts from Eoghan Glynn's message of 2015-04-02 10:18:22 -0400:
> >
> > Hi Folks,
> >
> > Just a quick note to say that I won't be running again for
> > ceilometer PTL over the liberty cycle.
> >
> > I've taken on a new role internally that won't realistically
> > allow me the time that the PTL role deserves. But y'all haven't
> > seen the last of me, I'll be sticking around as a contributor,
> > bandwidth allowing.
> >
> > I just wanted to take to opportunity to warmly thank everyone
> > in the ceilometer community for their efforts over the past two
> > cycles, and before.
> >
> > And I'm sure I'll be leaving the reins in good hands :)
> >
> > Cheers,
> > Eoghan
> >
>
> Thank you for serving as PTL, Eoghan. You've seen the team through some
> rough spots with aplomb.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] "All rights reserved" V.S. "Apache license"

[ZhiQiang Fan]

@Stefano Maffulli

Yes, the main point is the conflict of reserved all, and abandon some
(actually most).

According to the order the last will take effect IIUC Monty Taylor's
explaination.

I'm thinking that we should remove the "all rights reserved" words if we're
using Apache license.
Misleading is not a good thing, especially when it is for legal issue.

On Mon, Jan 19, 2015 at 6:53 AM, Stefano Maffulli 
wrote:

> On Sat, 2015-01-17 at 16:07 -0500, Monty Taylor wrote:
> > It's actually a set of words that is no longer necessary as of the year
> > 2000. It's not communicating anything about a granted license, which is
> > what the Apache License does - it's actually just asserting that the
> > original copyright holder asserts that they have not waived any of their
> > rights as a copyright holder. However, the Berne convention grants this
> > automatically without a positive assertion.
>
> I think ZhiQiang Fan's question is about the sentence "all rights
> reserved" followed by the implicit "some rights not reserved" granted by
> the Apache license, rather than the meaning of 'all rights reserved'
> alone. You're right that such sentence by itself is meaningless but in
> the context of the Apache license I think it's confusing at best,
> probably wrong.
>
> I don't remember seeing this case discussed on legal-discuss and I'm
> quite sure that the right way to apply the Apache license to source code
> is *not* by saying "(C) `date +%Y` Foo Corp, All Rights Reserved"
> followed by Apache license (see appendix on
> http://www.apache.org/licenses/LICENSE-2.0)
>
> Maybe a passage on legal-discuss would be better?
>
> /stef
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] "All rights reserved" V.S. "Apache license"

[ZhiQiang Fan]

Thanks for the clarification

On Sun, Jan 18, 2015 at 5:07 AM, Monty Taylor  wrote:

> On 01/17/2015 03:27 AM, ZhiQiang Fan wrote:
> > Hi, developers
> >
> > I have observed that some source code files in our projects have been
> > announced as "Copyright xxx, All rights reserved", and then followed by a
> > "Apache License"
> >
> > Is this right? any conflict?
> >
> > And if one company claims that it reserves all rights for some source
> > files,  those source files may have already created by or will be
> > maintained by several companies, then what about the others?
> >
> > Maybe a stupid question, but will be very appreciated if there is any
> > clarification.
>
> It's actually a set of words that is no longer necessary as of the year
> 2000. It's not communicating anything about a granted license, which is
> what the Apache License does - it's actually just asserting that the
> original copyright holder asserts that they have not waived any of their
> rights as a copyright holder. However, the Berne convention grants this
> automatically without a positive assertion.
>
> In short - the words "All rights reserved" neither help or harm anything.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] "All rights reserved" V.S. "Apache license"

[ZhiQiang Fan]

Hi, developers

I have observed that some source code files in our projects have been
announced as "Copyright xxx, All rights reserved", and then followed by a
"Apache License"

Is this right? any conflict?

And if one company claims that it reserves all rights for some source
files,  those source files may have already created by or will be
maintained by several companies, then what about the others?

Maybe a stupid question, but will be very appreciated if there is any
clarification.

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

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

[ZhiQiang Fan]

+1

how about the deep dependency? for example, we depends package A, and pin
it, but A->B->C, then B and C are not pined since they are not directly
depended, then what should we do? pin everything?

On Thu, Jan 15, 2015 at 5:35 PM, Joe Gordon  wrote:

> Eventlet released 0.16.1 on 2015-01-14 [0], which removed a deprecated
> API that nova stable/* still used. This caused nova-compute in stable/juno
> and stable/icehouse to crash thus breaking grenade on master. In 24 hours
> this bug caused 671 grenade jobs to fail[1]!
>
> After some quick debugging of this cryptic error suppressing stacktrace
> [2] we got to the real stacktrace:
> " File "nova/virt/libvirt/__init__.py", line 15, in 
>
> from nova.virt.libvirt import driver
>   File "nova/virt/libvirt/driver.py", line 48, in 
> from eventlet import util as eventlet_util
>
> ImportError: cannot import name util" [3]
> and capped the eventlet version on stable/* [4]
>
> As dependency bugs go this was a pretty typical one, so why am I writing
> this? Because we knew about this bug before it hit the gate, yet it was
> still an issue. The util module was removed in 0.16.0 but 'sneaked into'
> the build [5] so 0.16.1 fixed that. Before 0.16.1 was released this bug
> only impacted people who installed eventlet 0.16.0 from source and not from
> pip. Luckily someone did this and filed a bug [6] and a fix for this was
> landed on master on January 7th, and by the 10th the fix was backported to
> stable/juno and ready [7].  In the mean time, we had an unusually bad week
> dealing with new library versions; boto 2.35.0 was released and broke
> master and stable/juno [8] and sqlalchemy-migrate broke glance on master
> and stable as well [9].  And by the time these issues were fixed, and the
> tests would pass, eventlet 0.16.1 was already out. Unfortunately, there are
> a very small number of people who work on fixing dependency issues, some of
> them were traveling and the rest were over worked, so figuring out what
> went wrong with all the new packages came down to a handful of overworked
> people.
>
> So how could we have avoided this problem? By capping stable branch
> requirements so we only have to worry about uncapped dependencies on
> master. Capping stable branches has been previous discussed but no action
> has been taken. So going forward I propose we pin all requirements,
> including transitive, on stable branches. This way the release of new
> dependencies cannot automatically break stable branches and thus break
> grenade on master.
>
> I think we can implement this using `pip freeze` to get a list of all the
> installed libraries and `pip install -r --no-deps` to install the specific
> package versions.  I am not sure how best to handle package versions being
> removed from pypi though. Or at the very least we can cap requirements in
> global requirements and at least reduce the number of packages we install
> uncapped versions of.
>
> Thoughts?
>
> best,
> Joe
>
> [0] https://pypi.python.org/pypi/eventlet/0.16.1
> [1] http://status.openstack.org/elastic-recheck/#1410626
> [2]
> http://logs.openstack.org/98/115998/59/check/check-grenade-dsvm/e57eb40/logs/old/screen-n-cpu.txt.gz
> [3] http://paste.openstack.org/show/157558/
> [4]
> https://review.openstack.org/#/q/I4bbbeb5bf9c22ed36f5c9a74fec6b487d2c15697,n,z
> [5] https://github.com/eventlet/eventlet/releases/tag/v0.16.1
> [6] https://bugs.launchpad.net/nova/+bug/1407685
> [7]
> https://review.openstack.org/#/q/Idbb9d2b53829dae0e807cd1260dee3dce155d5f3,n,z
> [8] https://bugs.launchpad.net/nova/+bug/1408987
> [9] https://bugs.launchpad.net/glance/+bug/1410494
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
__
OpenStack Development Mailing 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] [CI][TripleO][Ironic] check-tripleo-ironic-xxx fails

[ZhiQiang Fan]

check-tripleo-ironic-xxx failed because:

rm -rf /home/jenkins/.cache/image-create/pypi/mirror/
rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/':
Permission denie

see
http://logs.openstack.org/37/143937/1/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/9be729b/console.html

search on logstash.openstack.org:
message:"rm: cannot remove
`/home/jenkins/.cache/image-create/pypi/mirror/\': Permission denied"
there are 59 hits in last 48 hours
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: Ceilometer memory.usage can not get info from libvirt

[ZhiQiang Fan]

libvirt cannot inspect memory usage because some condition is not satisfied.

But the AttributeError exception is ugly, Ceilometer should add basic check
for return value, otherwise the unnecessary exception will bother cloud
operator.  I have reported a bug in Ceilometer for this issue, see
https://bugs.launchpad.net/ceilometer/+bug/1393415

On Mon, Nov 17, 2014 at 5:51 PM, Rao Dingyuan  wrote:

> As described in the document:
> http://docs.openstack.org/developer/ceilometer/measurements.html#measurements
>
>
>
> “””
>
> *Note*
>
>
>
> To enable the libvirt memory.usage supporting, you need libvirt version
> 1.1.1+, qemu version 1.5+, and you need to prepare suitable balloon driver
> in the image, particularly for Windows guests, most modern Linuxes have it
> built in. The memory.usage meters can’t be fetched without image balloon
> driver.
>
>
>
> “””
>
> J
>
>
>
>
>
>
> --
>
> E_mail: raodingy...@chinacloud.com.cn
>
>
>
> *发件人:* Du Jun [mailto:dj199...@gmail.com]
> *发送时间:* 2014年11月17日 16:57
> *收件人:* OpenStack Development Mailing List (not for usage questions)
> *主题:* [openstack-dev] Ceilometer memory.usage can not get info from
> libvirt
>
>
>
> Hi all,
>
> 2014-11-17 16:04:01.563 5162 INFO ceilometer.agent [-] Polling pollster
> memory.usage in the context of meter_source
> 14 2014-11-17 16:04:01.564 5162 DEBUG
> ceilometer.compute.pollsters.memory [-] Checking memory usage for instance
> 7e53172c-f05f-4fda-9855-af6775c1f4a8 get_samples
> /opt/stack/ceilometer/ceilometer/compute/pollsters/memory.py:31
> 140002 2014-11-17 16:04:01.573 5162 WARNING
> ceilometer.compute.virt.libvirt.inspector [-] Failed to inspect memory
> usage of instance-0002, can not get info from libvirt
> 140003 2014-11-17 16:04:01.574 5162 ERROR
> ceilometer.compute.pollsters.memory [-] Could not get Memory Usage for
> 7e53172c-f05f-4fda-9855-af6775c1f4a8: 'NoneType' object has no attribute
> 'usage'
> 140004 2014-11-17 16:04:01.574 5162 TRACE
> ceilometer.compute.pollsters.memory Traceback (most recent call last):
> 140005 2014-11-17 16:04:01.574 5162 TRACE
> ceilometer.compute.pollsters.memory   File
> "/opt/stack/ceilometer/ceilometer/compute/pollsters/memory.py", line 37, in
> get_samples
> 140006 2014-11-17 16:04:01.574 5162 TRACE
> ceilometer.compute.pollsters.memory 'usage': memory_info.usage}))
> 140007 2014-11-17 16:04:01.574 5162 TRACE
> ceilometer.compute.pollsters.memory AttributeError: 'NoneType' object has
> no attribute 'usage'
>
> When
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] unable to collect compute.node.cpu.* data

[ZhiQiang Fan]

If you don't know what IndentationError is, I think there is a long way to
go before you familiar with Python.

I suggest you discus something about developer issue in this Development
Mailing List

Your problem is that you have modify the file
/opt/stack/ceilometer/ceilometer/compute/notifications/cpu.py, but use
wrong indentation, for example, you're using tab in linux vim, but set
wrong configuration for .vimrc, so it gets wrong indentation comparing to
original code

Let's end it, please

On Wed, Nov 12, 2014 at 10:41 AM, Du Jun  wrote:

> Hi all,
>
> I think I have found the reason why I am unable to get compute.node.cpu*
> information from command:
>
> $ ceilometer meter-list
>
> I get the error message from ceilometer-agent-notification.log
>
> 2014-11-11 17:10:40.015 19486 ERROR stevedore.extension [-] Could not load
> 'cpu_user_percent': unexpected indent (cpu.py, line 58)
>
> 2014-11-11 17:10:40.015 19486 ERROR stevedore.extension [-] unexpected
> indent (cpu.py, line 58)
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension Traceback (most
> recent call last):
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension   File
> "/usr/local/lib/python2.7/dist-packages/stevedore/extension.py", line 162,
> in _load_plugins
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension
> verify_requirements,
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension   File
> "/usr/local/lib/python2.7/dist-packages/stevedore/extension.py", line 178,
> in _load_one_plugin
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension plugin =
> ep.load(require=verify_requirements)
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension   File
> "/usr/local/lib/python2.7/dist-packages/pkg_resources.py", line 2184, in
> load
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension ['__name__'])
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension   File
> "/opt/stack/ceilometer/ceilometer/compute/notifications/cpu.py", line 58
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension if info:
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension^
>
> 2014-11-11 17:10:40.015 19486 TRACE stevedore.extension IndentationError:
> unexpected indent
>
>
> It seems that the python stevedore throws the error. I am not familiar
> with python stevedore, so I have no idea about the error message now. Any
> help will be appreciated.
>
>
>
> --
>
> Regards,
>
> Frank
>
> 2014-11-11 10:52 GMT+08:00 Du Jun :
>
>> $ ceilometer sample-list -m compute.node.cpu.idle.time
>>
>> I still get nothing.
>>
>>
>> --
>> Regards,
>> Frank
>>
>> 2014-11-07 21:17 GMT+08:00 Hang H Liu :
>>
>>> You didn't provide the full name of the meter. Here are results in my
>>> system.
>>>
>>> localadmin@ostest2:~/devstack$ ceilometer sample-list -m
>>> compute.node.cpu
>>> +-+--+--++--+---+
>>> | Resource ID | Name | Type | Volume | Unit | Timestamp |
>>> +-+--+--++--+---+
>>> +-+--+--++--+---+
>>>
>>> localadmin@ostest2:~/devstack$ ceilometer sample-list -m
>>> compute.node.cpu.idle.time | head
>>>
>>> +-+++-+--++
>>> | Resource ID | Name   | Type   | Volume
>>>  | Unit | Timestamp  |
>>>
>>> +-+++-+--++
>>> | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative |
>>> 3.876353234e+16 | ns   | 2014-11-07T13:15:06.580099 |
>>> | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative |
>>> 3.876282715e+16 | ns   | 2014-11-07T13:14:06.587392 |
>>> | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative |
>>> 3.87621264e+16  | ns   | 2014-11-07T13:13:06.556272 |
>>> | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative |
>>> 3.876141325e+16 | ns   | 2014-11-07T13:12:05.596962 |
>>> | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative |
>>> 3.876070965e+16 | ns   | 2014-11-07T13:11:05.576771 |
>>> | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative |
>>> 3.875998092e+16 | ns   | 2014-11-07T13:10:03.597978 |
>>> | ostest2_ostest2 | compute.node.cpu.idle.time | cumulative |
>>> 3.87592522e+16  | ns   | 2014-11-07T13:09:01.583991 |
>>>
>>>
>>> Best Regards,
>>> Liu, Hang(Henry)
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> Du Jun  写于 2014/11/07 15:46:21:
>>>
>>> > From: Du Jun 
>>> > To: "OpenStack Development Mailing List (not for usage questions)"
>>> > 
>>> > Date: 2014/11/07 15:50
>>>
>>> > Subject: Re: [openstack-dev] [ceilometer] unable to collect
>>> > compute.node.cpu.* data
>>> >
>>> > Nothing shows when I type command:
>>> >
>>> > vcap@ubuntu:~$ ceil

[openstack-dev] [Ceilometer] Timeout should be added when call http request

[ZhiQiang Fan]

Hi, devs,

I noticed that Ceilometer project uses lots of other OpenStack services,
and other thirdparty services APIs, but rare of them set timeout when call
http request, this is not a good behavior because many pollsters run in one
of threads, if one is every slow or stuckd, then others will not be able to
work too.

The worst case is if Ceilometer thread is stuckd, then when outside service
becomes normal, Ceilometer cannot recover itself, cloud operator will need
to restart the service manually, that is bad.

I have reported a bug, see:
https://bugs.launchpad.net/ceilometer/+bug/1388778
and uploaded a patch, see: https://review.openstack.org/#/c/132974/

What's your opinion?

And *I need help for writing test code for this patch* (the main reason why
I write this mail), is there any idea to test timeout case? I don't want
the unit test to be very slow, so a real timeout like sleep is not my
current choice.

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

Re: [openstack-dev] [Ceilometer][MongoDB] Using native time to live feature in MongoDB

[ZhiQiang Fan]

+1

On Thu, Nov 6, 2014 at 6:27 PM, Igor Degtiarov 
wrote:

> Hi stackers,
>
> I'm working on solving bug [1]. Time to live feature has native
> implementation in MongoDB thru index.
>
> Now we remove docs from resource table if they have no relations with
> existing samples in meter table while samples are removed when time to
> live is expired. So it seems that we can use ttl index also in
> resource table and remove reduce operation from the code.
>
> We update field last_sample_timestamp in resource table with every new
> sample that is received from certain resource. So adding ttl index to
> that field gives the same result as reduce operation in
> clear_expired_metering_data, but it will work in background with low
> priority and won't block database.
>
> Change request with implementation of ttl index in resource table [2].
>
> [1] https://bugs.launchpad.net/ceilometer/+bug/1270779
> [2] https://review.openstack.org/#/c/132988/
>
> Cheers, Igor.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Dev] [BarbicanClient] [Cinder] Cinder unit tests failing

[ZhiQiang Fan]

Actually, Alan Pevec on 2014-11-01 reported a bug
https://bugs.launchpad.net/cinder/+bug/1388461  and it is assigned to
original spec developer Brianna Poulos



On Wed, Nov 5, 2014 at 6:33 AM, John Griffith 
wrote:

> Hey Everyone,
>
> So there's been a bit of activity around barbicanclient as of late due
> version 3.0.0 causing unit test failures as a result of cliff
> dependencies in stable.
>
> Unfortunately, there's a detail that's been neglected here.  Looking
> at the logs for the unit test it turns out that barbicanclient remove
> a module.  That would be fine but sadly a unit test was written in
> cinder that imported module from python-barbicanclient directly
> (that's bad!!).  So as a result said unit tests now obviously fail.
>
> As a temporary solution I've removed
> cinder/tests/keymgr/test_barbican.py from Cinders unit tests. I'll
> look at rewriting the unit tests or maybe some of the barbican folks
> would be willing to step up and take a shot at cleaning this all up
> before I get a chance.
>
> For reference I've filed a cinder bug [1]
>
> Thanks,
> John
>
> [1]: https://bugs.launchpad.net/cinder/+bug/1389419
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] unable to collect compute.node.cpu.* data

[ZhiQiang Fan]

is there any error or warning information related to that meter-list
request in ceilometer-api.log?

On Wed, Nov 5, 2014 at 10:43 AM, Du Jun  wrote:

> Hi all,
>
> I attempt to collect compute.node.cpu as the following link mentions:
>
>
> http://docs.openstack.org/developer/ceilometer/measurements.html#compute-nova
>
> I set:
>
> compute_monitors = ComputeDriverCPUMonitor
>
> in /etc/nova/nova.conf and restart nova-compute, nova-scheduler,
> ceilometer-agent-notification, ceilometer-api, ceilometer-collector.
>
> From ceilometer-agent-notification's log, I can see agent transform and
> publish data samples compute.node.cpu.*
>
> What's more, from ceilometer database, I can see all the meters
> compute.node.cpu.*
>
> mysql> select * from meter;
>
> ++-++---+
>
> | id | name| type   | unit  |
>
> ++-++---+
>
> | 39 | compute.node.cpu.frequency  | gauge  | MHz   |
>
> | 41 | compute.node.cpu.idle.percent   | gauge  | % |
>
> | 38 | compute.node.cpu.idle.time  | cumulative | ns|
>
> | 45 | compute.node.cpu.iowait.percent | gauge  | % |
>
> | 42 | compute.node.cpu.iowait.time| cumulative | ns|
>
> | 36 | compute.node.cpu.kernel.percent | gauge  | % |
>
> | 44 | compute.node.cpu.kernel.time| cumulative | ns|
>
> | 37 | compute.node.cpu.percent| gauge  | % |
>
> | 43 | compute.node.cpu.user.percent   | gauge  | % |
>
> | 40 | compute.node.cpu.user.time  | cumulative | ns|
>
>
> However, when I type
>
> ceilometer meter-list
>
> It shows nothing about compute.node.cpu.*, so I wonder what's wrong with
> my steps.
>
> --
> Regards,
> Frank
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer][HBase] Failed to run tox with master code on local environment

[ZhiQiang Fan]

Hi, devs,

When I run tox -epy27 -- alarms (fresh install with tox -r), it shows that
may test case for hbase failed, I notice that jenkins runs well. I'm
wondering are there any further steps needed to be taken before run tox
locally? If so, which recent changes causes it?


part of screen output:

FAIL:
ceilometer.tests.api.v2.test_alarm_scenarios.TestAlarms.test_alarm_sends_notification(hbase)
tags: worker-1
--
Traceback (most recent call last):
  File "ceilometer/tests/base.py", line 99, in skip_if_not_implemented
return func(*args, **kwargs)
  File "ceilometer/tests/api/v2/test_alarm_scenarios.py", line 2092, in
test_alarm_sends_notification
headers=self.auth_headers, status=204)
  File "ceilometer/tests/api/__init__.py", line 136, in delete
expect_errors=expect_errors)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 421, in delete
content_type=content_type)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 734, in _gen_request
expect_errors=expect_errors)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 630, in do_request
self._check_status(status, res)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 665, in _check_status
"Bad response: %s (not %s)", res_status, status)
AppError: Bad response: 500 Internal Server Error (not 204)
Traceback (most recent call last):
_StringException: Empty attachments:
  stderr
  stdout

Traceback (most recent call last):
  File "ceilometer/tests/base.py", line 99, in skip_if_not_implemented
return func(*args, **kwargs)
  File "ceilometer/tests/api/v2/test_alarm_scenarios.py", line 2092, in
test_alarm_sends_notification
headers=self.auth_headers, status=204)
  File "ceilometer/tests/api/__init__.py", line 136, in delete
expect_errors=expect_errors)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 421, in delete
content_type=content_type)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 734, in _gen_request
expect_errors=expect_errors)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 630, in do_request
self._check_status(status, res)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 665, in _check_status
"Bad response: %s (not %s)", res_status, status)
AppError: Bad response: 500 Internal Server Error (not 204)

Traceback (most recent call last):
_StringException: Empty attachments:
  stderr
  stdout

Traceback (most recent call last):
  File "ceilometer/tests/base.py", line 99, in skip_if_not_implemented
return func(*args, **kwargs)
  File "ceilometer/tests/api/v2/test_alarm_scenarios.py", line 2092, in
test_alarm_sends_notification
headers=self.auth_headers, status=204)
  File "ceilometer/tests/api/__init__.py", line 136, in delete
expect_errors=expect_errors)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 421, in delete
content_type=content_type)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 734, in _gen_request
expect_errors=expect_errors)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 630, in do_request
self._check_status(status, res)
  File
"/home/zqfan/openstack/ceilometer-master/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
line 665, in _check_status
"Bad response: %s (not %s)", res_status, status)
AppError: Bad response: 500 Internal Server Error (not 204)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group

[ZhiQiang Fan]

Ceilometer mixes notifications and pollsters, so instance sample cannot
represents how many instances (sample-list nor statistics),
when we specify a time range in API query, the count of samples is not
precise to real situation, it is ether less (due to potential lag when time
range is precise) or more (due to redundant when time range has been
extended a bit to avoid lag)

IMHO, count of resource should be queried from specific service's API

On Tue, Oct 28, 2014 at 12:00 AM, Clint Byrum  wrote:

> Excerpts from Daniel Comnea's message of 2014-10-27 04:16:32 -0700:
> > Yes i did but if you look at this example
> >
> >
> https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml
> >
> >
> > the flow is simple:
> >
> > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy"
> which
> > then triggers the "type: OS::Heat::AutoScalingGroup"
> >
> >
> >
> > Now what i want is to be able to always maintain a min number of
> instances
> > in my Group, if is min_size been reached than trigger HEAT to spun a new
> > one to be min_size + n
> >
>
> Sounds like you're expecting Heat to respond to the stop/delete of one
> of the instances in the group.
>
> It doesn't do that.. yet. There's a very large scale effort under way
> called 'convergence' that will add such a capability to Heat (by having
> Heat try to assert that reality should match intention). Until then it
> doesn't support this use case very well.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Why alarm name is unique per project?

[ZhiQiang Fan]

@Nejc Saje

you're talking about group alarm, I'm going to try it on Kilo

On Wed, Sep 24, 2014 at 7:34 PM, Nejc Saje  wrote:

>
> On 09/24/2014 12:23 PM, Long Suo wrote:
>
>> Hi, all
>>
>> I am just a little confused why alarm name should be unique per project,
>> anyone knows this?
>>
>
> Good point, I admit I can't find a compelling reason for that either.
> Perhaps someone else can?
>
> Also, an interesting use-case comes to mind, where you can have for
> example an alarm for each instance, all of them named 'cpu_alarm', but with
> unique action per instance. You could then retrieve all these alarms at
> once with a proper query.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer-client] query option discard special characters

[ZhiQiang Fan]

Hi, developers,

I find that ceilometer-client applies strict rule on query option,
particularly, some special characters are not supported in key:value pairs,
such as ~, !, and etc

the regular expression used in ceilometerclient/v2/options.py is:
r'([[a-zA-Z0-9_.]+)([>https://bugs.launchpad.net/python-ceilometerclient/+bug/1314544 for more
detail

So, if we create resources in glance and nova, it may not be able to be
filtered out in ceilometer

for i.e.
# ceilometer sample-list -m instance -q 'metadata.display_name=special!key'
# ceilometer sample-list -m instance -q 'metadata.display_name=vm name'

the worse case is ceilometer-client will send wrong field since the parser
cannot work, so it will return 400 error!

I think ceilometer-client should not be so strict.

Any opinion?

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

[openstack-dev] [ceilometer] should we limit threshold value to be postive

[ZhiQiang Fan]

Hi, developers,

When I test the ceilometer threshold alarm, I find that there is no
limitation for the threshold value, which means we can set it to negative
value, but I didn't find any volume of meters will be negative, (if I'm
wrong, please let me know, thanks)

So, my question is: should we add such limitation, or keep current
situation because it is intended?

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

[openstack-dev] [ceilometer] review request 66006

[ZhiQiang Fan]

Hi, Ceilometer dev cores,

There is a patch https://review.openstack.org/#/c/66006/, which is
backported from 59669, aims at fixing bug :
https://bugs.launchpad.net/ceilometer/+bug/1257232 in havana branch, but it
is blocked by
"""
Alan Pevec
Feb 11

Patch Set 4: Do not merge

2013.2.2 freeze

"""

Since ceilometer 2013.2.3 has been released, I think such reason is not
correct any more, I have asked to remove the -2 in review comment, but get
no response

So I open a thread in mailing list to ask for help/advice

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

Re: [openstack-dev] [ceilometer] raise clientSideError or do for user

[ZhiQiang Fan]

thanks for the quick reply :)


On Mon, Apr 14, 2014 at 9:23 PM, Julien Danjou  wrote:

> On Mon, Apr 14 2014, ZhiQiang Fan wrote:
>
> > Hi, developers,
> >
> > For fixing bug https://launchpad.net/bugs/1304886, I uploaded a patch
> > https://review.openstack.org/#/c/86501/, when review this patch, there
> are
> > two different kinds of opinions, I don't know which is the better choice,
> > so I ask for help here.
> >
> > The patch aims at disallow user specify duplicate alarm ids in
> combination
> > rule to reduce unnecessary alarm evaluate. We can avoid such input in two
> > ways:
> >
> > * reject user's request with 400, so force user to provide unique list
> > * accept such request but remove duplicate ids for the user
> >
> > the problem is that
> > * the server side actually has no error, it just considers the efficiency
> > problem (and the efficiency improvement is tiny), so reject the request
> > seems a bit rude
> > * the user provide a bad request but we accept, which will cause the user
> > think he is doing a right thing, although he can check the return result
> > and find something different, but from my experience, I usually only
> check
> > response status code, and will not check each attribute carefully.
> >
> > here is an existent example of accept such problematical request which
> > provided by Ildiko Vancsa:
> >
> https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py#L904
> > or search 'def statistic' in that file if LOC is changed
> >
> > can you provide your opinion, or directly review that patch please?
>
> "Be conservative in what you do, be liberal in what you accept from
> others"
>
> So I would tend to convert the list to a set and not raise any error. If
> the user wants to have extra verification, it can compare what it sent
> to what it got in response.
>
> --
> Julien Danjou
> ;; Free Software hacker
> ;; http://julien.danjou.info
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] raise clientSideError or do for user

[ZhiQiang Fan]

Hi, developers,

For fixing bug https://launchpad.net/bugs/1304886, I uploaded a patch
https://review.openstack.org/#/c/86501/, when review this patch, there are
two different kinds of opinions, I don't know which is the better choice,
so I ask for help here.

The patch aims at disallow user specify duplicate alarm ids in combination
rule to reduce unnecessary alarm evaluate. We can avoid such input in two
ways:

* reject user's request with 400, so force user to provide unique list
* accept such request but remove duplicate ids for the user

the problem is that
* the server side actually has no error, it just considers the efficiency
problem (and the efficiency improvement is tiny), so reject the request
seems a bit rude
* the user provide a bad request but we accept, which will cause the user
think he is doing a right thing, although he can check the return result
and find something different, but from my experience, I usually only check
response status code, and will not check each attribute carefully.

here is an existent example of accept such problematical request which
provided by Ildiko Vancsa:
https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py#L904
or search 'def statistic' in that file if LOC is changed

can you provide your opinion, or directly review that patch please?

thanks

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

Re: [openstack-dev] [openstack][SUSE][Ceilometer] ceilometer service init script can be improved

[ZhiQiang Fan]

I confirm that after upgrade to ceilometer havana 2013.2.3 on sles 11 sp3,
these problems have been fixed, which means:

- restart long name ceilometer services no longer kill their brothers
(similar name process), and will not duplicate themself
- reboot host will no longer cause ceilometer-api quit and
ceilometer-collector fail

I will continue follow these problem just in case, but for now, they are
good

thanks for your great work!


On Wed, Mar 5, 2014 at 12:30 PM, ZhiQiang Fan  wrote:

> Hi, SUSE developers
>
> Thanks for your great work on OpenStack packaging for SUSE distribution.
>
> I have tested some functionality of ceilometer on sles 11 sp3, and have
> two minor problem, which can create critical availability problem, but can
> be easily fixed . They all locate in the service init script.
>
> * {start,check,kill}proc program base on process basename
>   this problem blocks alarm services, since ceilometer-alarm-evaluator and
> ceilometer-alarm-notifier have more than 15 prefix character exactly same,
> and blocks agent services in All-In-One scenario too,
> (ceilometer-agent-central & ceilometer-agent-compute)
>   Dirk Muller has provided a fix which using -p option to ensure the
> killproc will not affect another process, but I verify it on sles 11 sp3 in
> my all-in-one environment, and find that it does no longer kill other
> process, but it cannot kill its own process now, which means each time I
> restart the ceilometer-alarm-*, I get a new one but not replace the old one
>   I have a ugly workaround which simply shorten the ceilometer process
> name, it still works fine. But this problem needs to be fixed in upstream,
> by a better solution
>
> * ceilometer-{api,collector} depend on mongodb
>   mongodb is full-feature supported in havana (thanks to SUSE developer,
> they backport metaquery for sql backend, even it needs to be improved too),
> but I've already found that ceilometer-{api,collecor} cannot behavior
> normal when host boot, they both complain that cannot connect to database,
> api process will quit but collector process will stay broken and cannot
> recover itself anymore even mongodb is available after boot.
>   the problem may be quite simple, even though the two services specify
> the mongodb as a shoud-start service, but when host boot, mongodb may
> already start but in an unavailable state, which cause the two services
> fail. I've no idea how to solve this problem in a nice way, but I just
> sleep 5 seconds before startproc the service's process, then everything
> seems fine in my little environment. this workaround is ugly too, since it
> sleeps each time besides host boot.
>
> If you need any detail, I can provide more. These two problem need to be
> fixed seriously (maybe quickly) since it strongly affects feature
> availability and user experience
>
> Thanks
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][wsme][pecan] Need help for ceilometer havana alarm issue

[ZhiQiang Fan]

thank you very much

seems I should search the launchpad more carefully


On Thu, Mar 6, 2014 at 3:37 PM, Mehdi Abaakouk  wrote:

> Hi,
>
> On Thu, Mar 06, 2014 at 10:44:25AM +0800, ZhiQiang Fan wrote:
> > I already check the stable/havana and master branch via devstack, the
> > problem is still in havana, but master branch is not affected
> >
> > I think it is important to fix it for havana too, since some high level
> > application may depends on the returned faultstring. Currently, I'm not
> > sure mater branch fix it in pecan or wsme module, or in ceilometer itself
> >
> > Is there anyone can help with this problem?
>
> This is a duplicate bug of
> https://bugs.launchpad.net/ceilometer/+bug/1260398
>
> This one have already been fixed, I have marked havana as affected, to
> think about it if we cut a new havana version.
>
> Feel free to prepare the backport.
>
> Regards,
>
> --
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer][wsme][pecan] Need help for ceilometer havana alarm issue

[ZhiQiang Fan]

I already check the stable/havana and master branch via devstack, the
problem is still in havana, but master branch is not affected

I think it is important to fix it for havana too, since some high level
application may depends on the returned faultstring. Currently, I'm not
sure mater branch fix it in pecan or wsme module, or in ceilometer itself

Is there anyone can help with this problem?

thanks


On Tue, Feb 18, 2014 at 9:09 AM, ZhiQiang Fan  wrote:

> Hi,
>
> When I try to figure out the root cause of bug[1], I found that once
> wsme.exc.ClientSideError is triggerd when create an alarm, assume the
> faultstring is x, then if next http trigger a EntityNotFound(Exception)
> will get http response with faultstring equal to x.
>
> I trace the calling stack with a lot log, and the last log I got is in
> wsmeext.pecan.wsexpose, which showes that the dict which contains the
> faultstring is correct, it seems the problem occurs in formatting http
> response.
>
> env info:
> os: sles 11 sp3, ubuntu 12.04.3
> ceilometer: 2013.2.2, 2013.2.1
> wsme: cannot know, checked the egginfo and __init__ but got nothing
> pecan: forget...
>
> Please help, any information will be appreciated.
>
> Thanks!
>
> [1]: https://bugs.launchpad.net/ceilometer/+bug/1280036
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack][SUSE][Ceilometer] ceilometer service init script can be improved

[ZhiQiang Fan]

Hi, SUSE developers

Thanks for your great work on OpenStack packaging for SUSE distribution.

I have tested some functionality of ceilometer on sles 11 sp3, and have two
minor problem, which can create critical availability problem, but can be
easily fixed . They all locate in the service init script.

* {start,check,kill}proc program base on process basename
  this problem blocks alarm services, since ceilometer-alarm-evaluator and
ceilometer-alarm-notifier have more than 15 prefix character exactly same,
and blocks agent services in All-In-One scenario too,
(ceilometer-agent-central & ceilometer-agent-compute)
  Dirk Muller has provided a fix which using -p option to ensure the
killproc will not affect another process, but I verify it on sles 11 sp3 in
my all-in-one environment, and find that it does no longer kill other
process, but it cannot kill its own process now, which means each time I
restart the ceilometer-alarm-*, I get a new one but not replace the old one
  I have a ugly workaround which simply shorten the ceilometer process
name, it still works fine. But this problem needs to be fixed in upstream,
by a better solution

* ceilometer-{api,collector} depend on mongodb
  mongodb is full-feature supported in havana (thanks to SUSE developer,
they backport metaquery for sql backend, even it needs to be improved too),
but I've already found that ceilometer-{api,collecor} cannot behavior
normal when host boot, they both complain that cannot connect to database,
api process will quit but collector process will stay broken and cannot
recover itself anymore even mongodb is available after boot.
  the problem may be quite simple, even though the two services specify the
mongodb as a shoud-start service, but when host boot, mongodb may already
start but in an unavailable state, which cause the two services fail. I've
no idea how to solve this problem in a nice way, but I just sleep 5 seconds
before startproc the service's process, then everything seems fine in my
little environment. this workaround is ugly too, since it sleeps each time
besides host boot.

If you need any detail, I can provide more. These two problem need to be
fixed seriously (maybe quickly) since it strongly affects feature
availability and user experience

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

Re: [openstack-dev] [Ceilometer][SUSE] SUSE OpenStack Havana distribution is different with upstream

[ZhiQiang Fan]

thanks, Vincent

I already noticed that the critical bug is caused by a wrong backport, just
in the 
0001-enable-sql-metadata-query.patch<https://build.opensuse.org/package/view_file/Cloud:OpenStack:Havana/openstack-ceilometer/0001-enable-sql-metadata-query.patch?expand=1>line
124, session.flush() should be placed in line 110

Another question is that: How can I get the original version of community?
I know devstack is a good choice, but we want to install it via package
management system

Cheers


On Wed, Feb 26, 2014 at 8:58 PM, Vincent Untz  wrote:

> Hi,
>
> Le mercredi 26 février 2014, à 17:20 +0800, ZhiQiang Fan a écrit :
> > Hi, SUSE OpenStack developers,
> >
> > After install OpenStack Havana on SLES 11 SP3 following the
> > openstack-manuals' guide, I find that the
> > ceilometer/storage/impl_sqlalchemy.py has implemented the metaquey
> > functionality. However, the upstream, which means
> > github.com/openstack/ceilometer stable/havana branch doesn't implement
> that
> > feature yet.
> >
> > the ceilometer package version is 2013.2.2.dev13
> >
> > Here is my questions:
> >
> > 1. is this intent or just a mistake during package?
> > if it is intent, where can I get the distribution release notes?
>
> You can see the package at
>
> https://build.opensuse.org/package/show/Cloud:OpenStack:Havana/openstack-ceilometer
>
> I think this is added because of the
> 0001-enable-sql-metadata-query.patch patch (you can get some notes about
> history in the openstack-ceilometer.changes file)
>
> > 2. is this the only part which is different with community, or there are
> > other parts?
> > if it is not the only part, where can I get the whole diff note?
>
> See link above :-) Generally, the only "differences" are backports from
> Icehouse.
>
> > 3. where can I get help and how, if there is a bug in the different part
> > code?
> > actually, there is one, which caused by mysql foreign key, blocks
> > entire ceilometer-collector service.
>
> Feel free to get in touch with opensuse-cl...@opensuse.org, since this
> is where the packaging for OpenStack is discussed for openSUSE and SLES.
>
> (btw, with the build service, you can contribute any change you want to
> the package)
>
> Cheers,
>
> Vincent
>
> > This problem is really important (and a bit urgent), please help me.
> >
> > Thanks
>
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Les gens heureux ne sont pas pressés.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer][SUSE] SUSE OpenStack Havana distribution is different with upstream

[ZhiQiang Fan]

Hi, SUSE OpenStack developers,

After install OpenStack Havana on SLES 11 SP3 following the
openstack-manuals' guide, I find that the
ceilometer/storage/impl_sqlalchemy.py has implemented the metaquey
functionality. However, the upstream, which means
github.com/openstack/ceilometer stable/havana branch doesn't implement that
feature yet.

the ceilometer package version is 2013.2.2.dev13

Here is my questions:

1. is this intent or just a mistake during package?
if it is intent, where can I get the distribution release notes?

2. is this the only part which is different with community, or there are
other parts?
if it is not the only part, where can I get the whole diff note?

3. where can I get help and how, if there is a bug in the different part
code?
actually, there is one, which caused by mysql foreign key, blocks
entire ceilometer-collector service.

This problem is really important (and a bit urgent), please help me.

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

[openstack-dev] [OpenStack][Ceilometer] http header with large token problem

[ZhiQiang Fan]

Hi, developers

There is weired problem that when I try to verify the 8k http head problem
for ceilometer, I construct a very long (30k) token (use a real valid PKI
token as front part and copy several times), and use curl to request to
ceilometer api v2 statistic interface, but ** it returns 200 OK with real
data **, (I already set token_cache_time to -1 and restart the
ceilometer-api service)

So, my questions are:
* it should failed with 401, why 200 instead ?
* why ceilometer (or pecan) can enable such large http head
* is there any up bound for http head in ceilometer?
* if there is a up bound, can we configure it? I cannot find any related
config option in /etc/ceilometer/ceilometer.conf

Any help?

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

[openstack-dev] [Ceilometer][wsme][pecan] Need help for ceilometer havana alarm issue

[ZhiQiang Fan]

Hi,

When I try to figure out the root cause of bug[1], I found that once
wsme.exc.ClientSideError is triggerd when create an alarm, assume the
faultstring is x, then if next http trigger a EntityNotFound(Exception)
will get http response with faultstring equal to x.

I trace the calling stack with a lot log, and the last log I got is in
wsmeext.pecan.wsexpose, which showes that the dict which contains the
faultstring is correct, it seems the problem occurs in formatting http
response.

env info:
os: sles 11 sp3, ubuntu 12.04.3
ceilometer: 2013.2.2, 2013.2.1
wsme: cannot know, checked the egginfo and __init__ but got nothing
pecan: forget...

Please help, any information will be appreciated.

Thanks!

[1]: https://bugs.launchpad.net/ceilometer/+bug/1280036
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Policy Issue

[ZhiQiang Fan]

Hi,

I noticed that the Ceilometer project has no strict policy control, the
/etc/ceilometer/policy.json only has one single rule 'context_is_admin',
and for each specific resource operation, it will invoke acl.get_limit_to
and v2._verify_query_segregation to forbid non-admin role operate other
tenant's resources, so normal user has full privilege to CURD all resources
in his own tenant, which means it can delete the alarms which is created by
other users (verified in deployed Havana environment), this sounds not so
good.

So, is this loose policy limit designed purposely, or it just a simple
implementation for policy?

In other core projects (except heat), for i.e. Neutron, policy is very
detailed, resource operation policy even can forcus on an attribute. And
the verification is not defined in specific operation's code but call a
function and it will check the rules defined in policy.json.

So, is there any opportunity to implement more strict policy check, for
i.e. a normal user can read resources created by other users (to be
stricter, may disable this too), but read+write for his own?

I'd like to get some help or advise before create a blueprint

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

[openstack-dev] [api-site] how to switch the project version for api document

[ZhiQiang Fan]

Hi,

I noticed that API reference in
http://api.openstack.org/api-ref.htmldoesn't mention anything about
the version issue. For example, Ceilometer
has /v1 /v2 API, and /v2 is cross Havana and Icehouse, so if Icehouse adds
some new features which add new arguments to the v2 API, then how does the
reader tell that this argument is enable only in Icehouse?

For install guide, there are trunk and havana branches which can easily
change in browser URL [1], and I noticed that api-ref repo in github has
tag with 2013.1, 2013.2, and etc, so is there anyway to jump to 2013.2
version in browser just as install guide?

Thanks

-
[1]: I don't know is there anywhere has mentioned this but just try and get
this knowledge, the link from docs.openstack.org is
http://docs.openstack.org/havana/install-guide/install/zypper/content/,
then I change it to
http://docs.openstack.org/trunk/install-guide/install/zypper/content/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Hacking] unit test code is too less

[ZhiQiang Fan]

Hi, Dirk

If a line just with single print (which means a function name) does
nothing, I think it should be removed,

print$ cannot be detected by  "\bprint\s+[^\(]"

>>> import re
>>> print re.search(r"\bprint\s+[^\(]", "print")
None
>>> print re.search(r"\bprint(?:$|\s+[^\(])", "print")
<_sre.SRE_Match object at 0xb6c2bfa8>


On Thu, Jan 23, 2014 at 7:06 PM, Dirk Müller  wrote:

> Hi Zhi Qiang,
>
> > for i.e. the hacking rule h233 in hacking looks not so robust,
> >
> https://github.com/openstack-dev/hacking/blob/master/hacking/core.py#L345
> > it cannot detect
> >
> > \bprint$
> > \bprint >>>xxx, (\s+
>
> It currently detects both as a violation of the rule, which is IMHO
> correct. Please note that the behavior of
>
>   print
>
> depends on if its an operator (then it prints a newline) and a
> function (then it does nothing)
>
>
> Greetings,
> Dirk
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Hacking] unit test code is too less

[ZhiQiang Fan]

understand, thank you very much


On Thu, Jan 23, 2014 at 3:45 PM, Yuriy Taraday  wrote:

> Hello.
>
>
> On Thu, Jan 23, 2014 at 6:47 AM, ZhiQiang Fan wrote:
>>
>> I noticed that in openstack-dev/hacking project, there is very little
>> test code, is there any particular reason why it is in such situation?
>>
>
> Yes, there is. Every rule have a docstring that not only provides examples
> of good and bad code but also is run as a doctest here:
> https://github.com/openstack-dev/hacking/blob/master/hacking/tests/test_doctest.py
>
>
>> https://github.com/openstack-dev/hacking/blob/master/hacking/core.py#L345
>>  it cannot detect
>>
>> \bprint$
>> \bprint >>>xxx, (\s+
>>
>
> I'm not sure how can it not detect the second one since the regular
> expression used there to detect bad strings is  "\bprint\s+[^\(]" and it
> catches "print >>>xxx, (" string.
> The first one is a good catch though.
>
> If I want to improve this rule, how can I verify that my change is good?
>>
>
> Just change that regular expression as is needed and add a line to the
> docstring like these:
> Okay: print()
> H233: print
>
> Happy coding!
>
> --
>
> Kind regards, Yuriy.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Reducing pep8 ignores

[ZhiQiang Fan]

you can split H306 to several patches since it contains  so much files.

optional: It would be really nice if you can fix the unused import problem
(if exist) in the same time, this seems can be checked via IDE


On Wed, Jan 22, 2014 at 7:23 PM, Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> Hi all,
>
> we have an approved blueprint that concerns reducing number of ignored
> PEP8 and openstack/hacking style checks for heat (
> https://blueprints.launchpad.net/heat/+spec/reduce-flake8-ignored-rules).
> I've been already warned that enabling some of these rules will be quite
> controversial, and personally I do not like some of these rules myself
> either. In order to understand what is the opinion of the community, I
> would like to ask you to leave a comment on the blueprint page about what
> do you think about enabling these checks.
>
> The style rules being currently ignored are:
> F841 local variable 'json_template' is assigned to but never used
> H201 no 'except:' at least use 'except Exception:' (this actually checks
> for bare 'except:' lines, so 'except BaseException:' will pass too)
> H302 do not import objects, only modules (this I don't like myself as it
> can clutter the code beyond reasonable limit)
> H306 imports not in alphabetical order
> H404 multi line docstring should start with a summary
>
> Another question I have is how to proceed with such changes. I've already
> implemented H306 (order of imports) and am being now puzzled with how to
> propose such change to Gerrit. This change naturally touches many files
> (163 so far) and as such is clearly not suited for review in one piece. The
> only solution I currently can think of is to split it in 4-5-6 patches
> without actually changing tox.ini, and after all of them are merged, issue
> a final patch that updates tox.ini and any files breaking the rule that
> were introduced in between. But there is still a question on how Jenkins
> works with verify and merge jobs. Can it happen that we end up with code in
> master that does not pass pep8 check? Or there will be a 'race condition'
> between my final patch and any other that breaks the style rules? I would
> really appreciate any thoughts and comments about this.
>
> Best regards,
> Pavlo Shchelokovskyy.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Hacking] unit test code is too less

[ZhiQiang Fan]

Hi,

I noticed that in openstack-dev/hacking project, there is very little test
code, is there any particular reason why it is in such situation?

since hacking module is depended by almost all openstack projects, I think
hacking code should be tested well at least

for i.e. the hacking rule h233 in hacking looks not so robust,
https://github.com/openstack-dev/hacking/blob/master/hacking/core.py#L345
it cannot detect

\bprint$
\bprint >>>xxx, (\s+

If I want to improve this rule, how can I verify that my change is good?

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

[openstack-dev] [requirements][oslo] Upgrade six to 1.5.2?

[ZhiQiang Fan]

six 1.5.2 has been released on 2014-01-06, it provides urllib/urlparse
compatibility. Is there any plan to upgrade six to 1.5.2? (since it is
fresh new, may need some time to test)

six 1.4.1 is lack of urllib/urlparse support, so oslo-incubator/py3kcompat
is needed, and it is used in some projects, if we upgrade six, should we
remove py3k in the same time, or just leave those code there?

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

Re: [openstack-dev] [Ceilometer][Nova] basic setting for notification_driver

[ZhiQiang Fan]

Thank you for clarifying it.

But in my SLES environment, following the suse install guide:

# openstack-config --set /etc/nova/nova.conf DEFAULT
notification_driver nova.openstack.common.notifier.rpc_notifier
# openstack-config --set /etc/nova/nova.conf DEFAULT
notification_driver ceilometer.compute.nova_driver

the nova.openstack.common.notifier.rpc_notifier is overwrite by
ceilometer.compute.nova_notifier, but ceilometer meter-list still can
show instance and instance.flavor. I'm confused.




On Thu, Jan 16, 2014 at 3:49 AM, Doug Hellmann
wrote:

>
>
>
> On Wed, Jan 15, 2014 at 1:32 PM, ZhiQiang Fan  wrote:
>
>> Hi,
>>
>> When read Ceilometer install guide[1], the multi valued option
>> notification_driver is set to two drivers, My question is that is the first
>> one, which means nova.openstack.common.notifier.rpc_notifier, necessary?
>> what will happen if it is removed?
>>
>
> If the rpc notifier is not configured in nova's settings, then nova will
> not send notifications to the message bus and ceilometer will not have data
> to record about nova resources.
>
>
>
>> Note, it is not configured even in Nova installation, but is set in
>> Ceilometer compute agent configuration part.
>>
>
> The rpc notifier isn't required for nova to operate by itself, only for
> the integration with ceilometer.
>
> Doug
>
>
>
>>
>> I already read the link of SystemUsageData[2], NotificationSystem[3],
>> but still get no idea.
>>
>> Please help, thanks
>>
>> [1]
>> http://docs.openstack.org/havana/install-guide/install/apt/content/ceilometer-install-nova.html<http://docs.openstack.org/havana/install-guide/install/apt/content/ceilometer-install-nova.html>
>> [2] https://wiki.openstack.org/wiki/SystemUsageData
>> [3] https://wiki.openstack.org/wiki/NotificationSystem
>> --
>> blog: zqfan.github.com
>> git: github.com/zqfan
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer][Nova] basic setting for notification_driver

[ZhiQiang Fan]

Hi,

When read Ceilometer install guide[1], the multi valued option
notification_driver is set to two drivers, My question is that is the first
one, which means nova.openstack.common.notifier.rpc_notifier, necessary?
what will happen if it is removed?

Note, it is not configured even in Nova installation, but is set in
Ceilometer compute agent configuration part.

I already read the link of SystemUsageData[2], NotificationSystem[3], but
still get no idea.

Please help, thanks

[1]
http://docs.openstack.org/havana/install-guide/install/apt/content/ceilometer-install-nova.html
[2] https://wiki.openstack.org/wiki/SystemUsageData
[3] https://wiki.openstack.org/wiki/NotificationSystem
-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] kwargs explanation should be used when we raise webob.exc.WSGIHTTPException

[ZhiQiang Fan]

Hi, stackers,

In review patch: https://review.openstack.org/64099, I found that if we use
kwargs detail instead of explanation when we raise that WSGIHTTPException,
the http response body will generate 'message' using default explanation,
instead of what we expected which is detail=msg.

So I register bug: https://bugs.launchpad.net/nova/+bug/1264328 and
Kiyohiro Adach register https://bugs.launchpad.net/cinder/+bug/1264424 to
identify this problem

However, in https://review.openstack.org/#/c/64230/, Huang Zhiteng
mentioned that:
```
John mentioned this a few times, some customers may reply on this
'not-so-correct' API behavior for their automation. I'm not sure how
changes like this will affect them.
```

So I want to know what is the right action we should take, IMHO, we should
fix all of those statements in master branch, which means:

- raise webob.exc.HTTPXXX(_("message"))
- raise webob.exc.HTTPXXX(detail=_("message"))

should be replaced with raise webob.exc.HTTPXXX(explanation=_("message"))

What your opinion?

Thanks

-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutronclient] tox -epy27 failed because test_ssl

[ZhiQiang Fan]

Sometimes, when i run tox on neutronclient, the
test_ssl.TestSSL.test_client_manager_properly_creates_httpclient_instance
may fail. However, gate doesn't catch this problem, and even in my env, it
doesn't fail everytime, is there any other developer have meet same problem?

-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Requirements syncing job is live

[ZhiQiang Fan]

Hi, Sean Dague,

Thank you for the clarification.


On Wed, Oct 2, 2013 at 7:44 PM, Sean Dague  wrote:

> Requirements is a little different, because we actually know in advance
> that the code will work with the latest requirements before we propose the
> change to the projects, as the requirements changes are gated on
> tempest/devstack.
>
> proposed changes to oslo don't attempt to run them against all the
> projects (though... that would be interesting...) so we don't actually know
> that what's in oslo will work everywhere (and it often doesn't). So there
> autosync is not yet appropriate.
>
>
> On 10/02/2013 04:40 AM, ZhiQiang Fan wrote:
>
>> Hi, Roman,
>>
>> auto sync requirements is a good job.
>>
>> It is so good that I'm wondering if the oslo-incubator can do such job
>> too, because i noticed that there are some patches just update
>> oslo-incubator modules, (no related bug, just normal update, sorry i
>> cannot remember specific example), sometimes only one single module. I
>> think if some modules in oslo-incubator fix important bugs, new
>> wonderful features or just a series of stable enough commits, then the
>> maintainer can modify the HEAD(git commit hash id of that module stable
>> version, the oslo-incubator's real HEAD will always newer than it, sorry
>> for the confused term) of that module in conf file, then jenkins can
>> propose a patch to each project automatically, and  all project can be
>> aligned to the 'HEAD'.
>>
>> sorry, i didn't notice the other independent oslo libraries, i just hope
>> oslo-incubator can do this (unlike oslo.config can be installed
>> independent, only update requirement can do such job)
>>
>>
>> On Wed, Oct 2, 2013 at 4:01 PM, Roman Podolyaka > <mailto:rpodolyaka@mirantis.**com >> wrote:
>>
>> Hello ZhiQiang,
>>
>> I'm not sure what HEADs you mean: oslo-incubator doesn't contain git
>> submodules, but rather regular Python packages.
>>
>> On the other hand, oslo.version/oslo.messaging/**oslo.* are separate
>> libraries, having their own releases, so syncing of global
>> requirements will effectively make projects use newer versions of
>> those libs.
>>
>> Thanks,
>> Roman
>>
>>
>> On Wed, Oct 2, 2013 at 5:02 AM, ZhiQiang Fan > <mailto:aji.zq...@gmail.com>> wrote:
>>
>> great job! thanks
>>
>> (how about auto sync from oslo too?
>> - projects.txt: projects want to be automatically synced from oslo
>> - heads.txt: HEAD for each module in oslo
>>
>> whenever module maintainer think current module is strong enough
>> to publish, then he/she can edit the heads.txt of that module
>> line, then jenkins will propose a sync patch for projects listed
>> in projects.txt
>>
>> this behavior will be dangerous, since it may pass gate test
>> when merge but cause internal bug which is not well test coverd)
>>
>>
>> On Wed, Oct 2, 2013 at 1:27 AM, Monty Taylor
>> mailto:mord...@inaugust.com>> wrote:
>>
>> Hey all!
>>
>> The job to automatically propose syncs from the
>> openstack/requirements
>> repo went live today - as I'm sure you all noticed, since
>> pretty much
>> everyone got a patch of at least some size.
>>
>> The job works the same way as the translations job - it will
>> propose a
>> patch any time the global repo changes - but if there is
>> already an
>> outstanding change that has not been merged, it will simply
>> amend that
>> change. So there should only ever be one change per branch
>> per project
>> in the topic openstack/requirements submitted by the jenkins
>> user.
>>
>> If a change comes in and you say to yourself "ZOMG, that
>> version would
>> break us" - then you should definitely go and propose an
>> update to the
>> global list itself, which is in the global-requirements.txt
>> file in the
>> openstack/requirements repo.
>>
>> The design goal, as discussed at the last two summits, is
>> that we should
>> converge on alignment by the release a

Re: [openstack-dev] Requirements syncing job is live

[ZhiQiang Fan]

Hi, Roman,

auto sync requirements is a good job.

It is so good that I'm wondering if the oslo-incubator can do such job too,
because i noticed that there are some patches just update oslo-incubator
modules, (no related bug, just normal update, sorry i cannot remember
specific example), sometimes only one single module. I think if some
modules in oslo-incubator fix important bugs, new wonderful features or
just a series of stable enough commits, then the maintainer can modify the
HEAD(git commit hash id of that module stable version, the oslo-incubator's
real HEAD will always newer than it, sorry for the confused term) of that
module in conf file, then jenkins can propose a patch to each project
automatically, and  all project can be aligned to the 'HEAD'.

sorry, i didn't notice the other independent oslo libraries, i just hope
oslo-incubator can do this (unlike oslo.config can be installed
independent, only update requirement can do such job)


On Wed, Oct 2, 2013 at 4:01 PM, Roman Podolyaka wrote:

> Hello ZhiQiang,
>
> I'm not sure what HEADs you mean: oslo-incubator doesn't contain git
> submodules, but rather regular Python packages.
>
> On the other hand, oslo.version/oslo.messaging/oslo.* are separate
> libraries, having their own releases, so syncing of global requirements
> will effectively make projects use newer versions of those libs.
>
> Thanks,
> Roman
>
>
> On Wed, Oct 2, 2013 at 5:02 AM, ZhiQiang Fan  wrote:
>
>> great job! thanks
>>
>> (how about auto sync from oslo too?
>> - projects.txt: projects want to be automatically synced from oslo
>> - heads.txt: HEAD for each module in oslo
>>
>> whenever module maintainer think current module is strong enough to
>> publish, then he/she can edit the heads.txt of that module line, then
>> jenkins will propose a sync patch for projects listed in projects.txt
>>
>> this behavior will be dangerous, since it may pass gate test when merge
>> but cause internal bug which is not well test coverd)
>>
>>
>> On Wed, Oct 2, 2013 at 1:27 AM, Monty Taylor wrote:
>>
>>> Hey all!
>>>
>>> The job to automatically propose syncs from the openstack/requirements
>>> repo went live today - as I'm sure you all noticed, since pretty much
>>> everyone got a patch of at least some size.
>>>
>>> The job works the same way as the translations job - it will propose a
>>> patch any time the global repo changes - but if there is already an
>>> outstanding change that has not been merged, it will simply amend that
>>> change. So there should only ever be one change per branch per project
>>> in the topic openstack/requirements submitted by the jenkins user.
>>>
>>> If a change comes in and you say to yourself "ZOMG, that version would
>>> break us" - then you should definitely go and propose an update to the
>>> global list itself, which is in the global-requirements.txt file in the
>>> openstack/requirements repo.
>>>
>>> The design goal, as discussed at the last two summits, is that we should
>>> converge on alignment by the release at the very least. With this and
>>> the changes that exist now in the gate to block non-aligned
>>> requirements, once we get aligned, we shouldn't probably be too far out
>>> from each other moving forward.
>>>
>>> Additionally, the list of projects to receive updates is managed in a
>>> file, projects.txt, in the openstack/requirements repo. If you are
>>> running a project and would like to receive syncing patches, feel free
>>> to add yourself to the list.
>>>
>>> Enjoy!
>>> Monty
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> blog: zqfan.github.com
>> git: github.com/zqfan
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Requirements syncing job is live

[ZhiQiang Fan]

great job! thanks

(how about auto sync from oslo too?
- projects.txt: projects want to be automatically synced from oslo
- heads.txt: HEAD for each module in oslo

whenever module maintainer think current module is strong enough to
publish, then he/she can edit the heads.txt of that module line, then
jenkins will propose a sync patch for projects listed in projects.txt

this behavior will be dangerous, since it may pass gate test when merge but
cause internal bug which is not well test coverd)


On Wed, Oct 2, 2013 at 1:27 AM, Monty Taylor  wrote:

> Hey all!
>
> The job to automatically propose syncs from the openstack/requirements
> repo went live today - as I'm sure you all noticed, since pretty much
> everyone got a patch of at least some size.
>
> The job works the same way as the translations job - it will propose a
> patch any time the global repo changes - but if there is already an
> outstanding change that has not been merged, it will simply amend that
> change. So there should only ever be one change per branch per project
> in the topic openstack/requirements submitted by the jenkins user.
>
> If a change comes in and you say to yourself "ZOMG, that version would
> break us" - then you should definitely go and propose an update to the
> global list itself, which is in the global-requirements.txt file in the
> openstack/requirements repo.
>
> The design goal, as discussed at the last two summits, is that we should
> converge on alignment by the release at the very least. With this and
> the changes that exist now in the gate to block non-aligned
> requirements, once we get aligned, we shouldn't probably be too far out
> from each other moving forward.
>
> Additionally, the list of projects to receive updates is managed in a
> file, projects.txt, in the openstack/requirements repo. If you are
> running a project and would like to receive syncing patches, feel free
> to add yourself to the list.
>
> Enjoy!
> Monty
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] about bug create new task

[ZhiQiang Fan]

Hi,

I noticed that you've done some great work about the init testr problem,
thanks for your contribute.

There is something can be improved if you want, which means that:
you can create new task in a reported bug, just click "Also affects
project" and add new project.

This can help us to know what this bug spread in whole projects of
openstack, searching same problem in each project in launchpad takes some
extra effort to locate, which is not necessary and can be easily resolved
if good way is taken

I'm glad if you have time to fix same problem in other project.
Thanks

-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]All unittest passed but Jenkins failed

[ZhiQiang Fan]

thanks for your help


On Wed, Sep 11, 2013 at 10:38 PM, James E. Blair wrote:

> ZhiQiang Fan  writes:
>
> > currently, i don't know if it is coverage problem or something else.
> >
> > the direct cause is:
> >
> > sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post
> >
> > Sep  9 06:57:23 precise1 sudo:  jenkins : 3 incorrect password
> > attempts ; TTY=unknown ;
> > PWD=/home/jenkins/workspace/gate-neutron-python27 ; USER=root ;
> > COMMAND=ovs-vsctl --timeout=2 -- --columns=external_ids,name,ofport
> > find Interface
> external_ids:iface-id="71d9fa4c-f074-46bd-96af-8c592d37c160"
>
> This is because the unit test tried to run 'sudo'.  That's not allowed
> in unit tests, so it needs to be mocked out.
>
> > meanwhile, i found that:
> >
> > 2013-09-09 06:42:25.922 | + git fetch
> > http://zuul.openstack.org/p/openstack/neutron
> > refs/zuul/master/Z62b50e610b554304bde4aa2a9ea80193
> > 2013-09-09 06:42:26.747 | From
> http://zuul.openstack.org/p/openstack/neutron
> > 2013-09-09 06:42:26.747 |  * branch
> > refs/zuul/master/Z62b50e610b554304bde4aa2a9ea80193 -> FETCH_HEAD
> > 2013-09-09 06:42:26.751 | + git checkout FETCH_HEAD
> > 2013-09-09 06:42:26.954 | Warning: you are leaving 17 commits behind,
> > not connected to
> > 2013-09-09 06:42:26.954 | any of your branches:
> > 2013-09-09 06:42:26.954 |
> > 2013-09-09 06:42:26.954 |   62d0927 Avoid shadowing NeutronException
> > 'message' attribute
> > 2013-09-09 06:42:26.954 |   e26639b Merge "Replace assertEquals with
> > assertEqual"
> > 2013-09-09 06:42:26.954 |   5bae582 Load ML2 mech drivers as listed in
> > ml2_conf.ini
> > 2013-09-09 06:42:26.955 |   902dc88 Replace assertEquals with assertEqual
> > 2013-09-09 06:42:26.955 |  ... and 13 more.
> > 2013-09-09 06:42:26.955 |
> > 2013-09-09 06:42:26.955 | If you want to keep them by creating a new
> > branch, this may be a good time
> > 2013-09-09 06:42:26.956 | to do so with:
> > 2013-09-09 06:42:26.956 |
> > 2013-09-09 06:42:26.956 |  git branch new_branch_name
> > 62d09275d899237dc34cf50c81e99d50489212ff
> > 2013-09-09 06:42:26.956 |
> > 2013-09-09 06:42:26.962 | HEAD is now at 7cbd0f5... Improve
> dhcp_agent_scheduler
>
> You can ignore most of that; that's just Jenkins resetting its git repo
> from an earlier test run.  By the time it's finished, it says:
>
> >> 2013-09-09 06:42:26.962 | HEAD is now at 7cbd0f5... Improve
> dhcp_agent_scheduler
>
> Which is the important part.  You'll see that matches your local HEAD as
> well:
>
> > but in my local env:
> >
> > $ git log --pretty=format:"%h %s"
> >
> > 7cbd0f5 Improve dhcp_agent_scheduler
>
> -Jim
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron]All unittest passed but Jenkins failed

[ZhiQiang Fan]

currently, i don't know if it is coverage problem or something else.

the direct cause is:

sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post

Sep  9 06:57:23 precise1 sudo:  jenkins : 3 incorrect password
attempts ; TTY=unknown ;
PWD=/home/jenkins/workspace/gate-neutron-python27 ; USER=root ;
COMMAND=ovs-vsctl --timeout=2 -- --columns=external_ids,name,ofport
find Interface external_ids:iface-id="71d9fa4c-f074-46bd-96af-8c592d37c160"


meanwhile, i found that:

2013-09-09 06:42:25.922 | + git fetch
http://zuul.openstack.org/p/openstack/neutron
refs/zuul/master/Z62b50e610b554304bde4aa2a9ea80193
2013-09-09 06:42:26.747 | From http://zuul.openstack.org/p/openstack/neutron
2013-09-09 06:42:26.747 |  * branch
refs/zuul/master/Z62b50e610b554304bde4aa2a9ea80193 -> FETCH_HEAD
2013-09-09 06:42:26.751 | + git checkout FETCH_HEAD
2013-09-09 06:42:26.954 | Warning: you are leaving 17 commits behind,
not connected to
2013-09-09 06:42:26.954 | any of your branches:
2013-09-09 06:42:26.954 |
2013-09-09 06:42:26.954 |   62d0927 Avoid shadowing NeutronException
'message' attribute
2013-09-09 06:42:26.954 |   e26639b Merge "Replace assertEquals with
assertEqual"
2013-09-09 06:42:26.954 |   5bae582 Load ML2 mech drivers as listed in
ml2_conf.ini
2013-09-09 06:42:26.955 |   902dc88 Replace assertEquals with assertEqual
2013-09-09 06:42:26.955 |  ... and 13 more.
2013-09-09 06:42:26.955 |
2013-09-09 06:42:26.955 | If you want to keep them by creating a new
branch, this may be a good time
2013-09-09 06:42:26.956 | to do so with:
2013-09-09 06:42:26.956 |
2013-09-09 06:42:26.956 |  git branch new_branch_name
62d09275d899237dc34cf50c81e99d50489212ff
2013-09-09 06:42:26.956 |
2013-09-09 06:42:26.962 | HEAD is now at 7cbd0f5... Improve dhcp_agent_scheduler


but in my local env:

$ git log --pretty=format:"%h %s"

7cbd0f5 Improve dhcp_agent_scheduler
57ce39f Merge "Enclose command args in with_venv.sh"
9707c73 Merge "Imported Translations from Transifex"
45beae8 Merge "Fix IF checks on spawned green thread instance"
f7c55db Imported Translations from Transifex
0f81818 Merge "Mock midonetclient in test_midonet_lib"
fc0e7cd Fix IF checks on spawned green thread instance
e82f0eb Prevents 400 NVP errors caused by a None display_name
e26639b Merge "Replace assertEquals with assertEqual"
5bae582 Load ML2 mech drivers as listed in ml2_conf.ini
fe92e1e Mock midonetclient in test_midonet_lib
902dc88 Replace assertEquals with assertEqual


it seems they are not matched? 62d0927 Avoid shadowing
NeutronException 'message' attribute is not in my branch, but i
already rebase the latest master branch.


can anyone help me?


review: https://review.openstack.org/#/c/42457/7
log:
http://logs.openstack.org/57/42457/7/check/gate-neutron-python27/453c38f
console:
http://logs.openstack.org/57/42457/7/check/gate-neutron-python27/453c38f/console.html
 :


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Running unit tests (was: REST-based ML2 MechanismDriver)

[ZhiQiang Fan]

why -- is important? without it still can work (maybe not work perfectly?
or will miss something important?) on ubuntu12.04 py2.7.5


On Mon, Sep 2, 2013 at 1:59 AM, Akihiro Motoki  wrote:

> Please try:
>
>tox -e py27 -- neutron.tests.unit.test_l3_plugin
>
> "--" is important when using tox.
>
> run_tests.sh with a subset does not work for me too. I am not sure why.
> I didn't notice it since I usually use tox.
>
>
> On Mon, Sep 2, 2013 at 2:51 AM, Luke Gorrie  wrote:
> > Hi guys,
> >
> > Can someone tell me the best way currently to run a subset of Neutron
> unit
> > tests (e.g. ml2 ones)?
> >
> > The command I got the last time I asked has recently stopped working:
> >
> > On 6 June 2013 17:16, Luke Gorrie  wrote:
> >>
> >> The .venv/bin/python run_tests.py ... trick works for me after . I am in
> >> business!
> >
> >
> > I can run the full test suite with "tox" but haven't figured out how to
> run
> > only a subset of test cases. Hints would be really welcome!
> >
> > Cheers,
> > -Luke
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Akihiro MOTOKI 
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Running unit tests (was: REST-based ML2 MechanismDriver)

[ZhiQiang Fan]

tox neutron.tests.unit.ml2


On Mon, Sep 2, 2013 at 1:51 AM, Luke Gorrie  wrote:

> Hi guys,
>
> Can someone tell me the best way currently to run a subset of Neutron unit
> tests (e.g. ml2 ones)?
>
> The command I got the last time I asked has recently stopped working:
>
> On 6 June 2013 17:16, Luke Gorrie  wrote:
>
>> The .venv/bin/python run_tests.py ... trick works for me after . I am in
>> business!
>>
>
> I can run the full test suite with "tox" but haven't figured out how to
> run only a subset of test cases. Hints would be really welcome!
>
> Cheers,
> -Luke
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Proposal for Raksha, a Data Protection As a Service project

[ZhiQiang Fan]

+1


On Thu, Aug 29, 2013 at 6:12 AM, Murali Balcha  wrote:

>   Hello Stackers,
>
> We would like to introduce a new project Raksha, a Data Protection As a
> Service (DPaaS) for OpenStack Cloud.
>
> Raksha’s primary goal is to provide a comprehensive Data Protection for
> OpenStack by leveraging Nova, Swift, Glance and Cinder. Raksha has
> following key features:
>
>  1.   Provide an enterprise grade data protection for OpenStack based
> clouds
>
>  2.   Tenant administered backups and restores
>
>  3.   Application consistent backups
>
>  4.   Point In Time(PiT) full and incremental backups and restores
>
>  5.   Dedupe at source for efficient backups
>
>  6.   A job scheduler for periodic backups
>
>  7.   Noninvasive backup solution that does not require service
> interruption during backup window
>
>
>
> You will find the rationale behind the need for Raksha in OpenStack in its
> Wiki. The wiki also has the preliminary design and the API description.  Some
> of the Raksha functionality may overlap with Nova and Cinder projects and
> as a community lets work together to coordinate the features among these
> projects. We would like to seek out early feedback so we can address as
> many issues as we can in the first code drop. We are hoping to enlist the
> OpenStack community help in making Raksha a part of OpenStack.
>
> Raksha’s project resources:
>
> Wiki: https://wiki.openstack.org/wiki/Raksha
>
> Launchpad: https://launchpad.net/raksha
>
> Github: https://github.com/DPaaS-Raksha/Raksha (We will upload a
> prototype code in few days)
>
> If you want to talk to us, send an email to
> openstack-...@lists.launchpad.net with "[raksha]" in the subject or use
> #openstack-raksha irc channel.
>
>
>
> Best Regards,
>
> Murali Balcha
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][keystone][ldap] Bug unsupported operand type(s) for &: 'str' and 'int'

[ZhiQiang Fan]

actually, i only read the master branch, and there is no such file, you can
report a bug on keystone grizzly and submit your code, if you're granted


On Thu, Aug 22, 2013 at 5:21 PM, Qinglong.Meng wrote:

> I have fix it in my env.
> and you will find some hardcore in /identity/backend/ldap/core.py,,
>
>
> 2013/8/22 ZhiQiang Fan 
>
>> yes, i think it is a bug, because the api doesn't convert string to
>> correct type:
>> >>> True & 1
>> 1
>> >>> 'True' & 1
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> TypeError: unsupported operand type(s) for &: 'str' and 'int'
>>
>> Feel free to report a bug and may be you can try to fix it.
>>
>>
>> On Thu, Aug 22, 2013 at 3:51 PM, Qinglong.Meng wrote:
>>
>>> oh, yeah,
>>> here is the keystone log:
>>> http://paste.openstack.org/show/44857/
>>>
>>> Best Regards,
>>>
>>>
>>>
>>>
>>>
>>> 2013/8/22 ZhiQiang Fan 
>>>
>>>> your first reference (the log) is incorrect.
>>>>
>>>>
>>>> On Thu, Aug 22, 2013 at 2:55 PM, Qinglong.Meng 
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>> Os: Ubuntu 12.04 LTS
>>>>> keystone version: stable/grizzly
>>>>>
>>>>> After I deploy keystone with ldap backend (openldap), I got the
>>>>> issue about type in keystone.log, when I create user by  keystoneclient.
>>>>> Here are some docs:
>>>>> 1. keystone.log
>>>>> http://paste.openstack.org/
>>>>> 2. keystone.conf
>>>>> http://paste.openstack.org/show/44839/
>>>>> 3. slapd.conf
>>>>> http://paste.openstack.org/show/44843/
>>>>> 4. openstack.ldif
>>>>> http://paste.openstack.org/show/44844/
>>>>>
>>>>> And I think this is one bug, it's right?
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> --
>>>>>
>>>>> Lawrency Meng
>>>>> mail: mengql112...@gmail.com
>>>>> ___
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openst...@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>> ___
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev@lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> blog: zqfan.github.com
>>>> git: github.com/zqfan
>>>>
>>>> ___
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Lawrency Meng
>>> mail: mengql112...@gmail.com
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openst...@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> blog: zqfan.github.com
>> git: github.com/zqfan
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Lawrency Meng
> mail: mengql112...@gmail.com
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openst...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][keystone][ldap] Bug unsupported operand type(s) for &: 'str' and 'int'

[ZhiQiang Fan]

yes, i think it is a bug, because the api doesn't convert string to correct
type:
>>> True & 1
1
>>> 'True' & 1
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for &: 'str' and 'int'

Feel free to report a bug and may be you can try to fix it.


On Thu, Aug 22, 2013 at 3:51 PM, Qinglong.Meng wrote:

> oh, yeah,
> here is the keystone log:
> http://paste.openstack.org/show/44857/
>
> Best Regards,
>
>
>
>
>
> 2013/8/22 ZhiQiang Fan 
>
>> your first reference (the log) is incorrect.
>>
>>
>> On Thu, Aug 22, 2013 at 2:55 PM, Qinglong.Meng wrote:
>>
>>> Hi All,
>>> Os: Ubuntu 12.04 LTS
>>> keystone version: stable/grizzly
>>>
>>> After I deploy keystone with ldap backend (openldap), I got the
>>> issue about type in keystone.log, when I create user by  keystoneclient.
>>> Here are some docs:
>>> 1. keystone.log
>>> http://paste.openstack.org/
>>> 2. keystone.conf
>>> http://paste.openstack.org/show/44839/
>>> 3. slapd.conf
>>> http://paste.openstack.org/show/44843/
>>> 4. openstack.ldif
>>> http://paste.openstack.org/show/44844/
>>>
>>> And I think this is one bug, it's right?
>>>
>>> Best Regards,
>>>
>>> --
>>>
>>> Lawrency Meng
>>> mail: mengql112...@gmail.com
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openst...@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> blog: zqfan.github.com
>> git: github.com/zqfan
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Lawrency Meng
> mail: mengql112...@gmail.com
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openst...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Quantum]How to contribute LBaas driver?

[ZhiQiang Fan]

"""Where to post the code and where to require code review?"""

the following 2 links may help
- https://wiki.openstack.org/wiki/How_To_Contribute
- https://wiki.openstack.org/wiki/Gerrit_Workflow

good luck


On Thu, Aug 22, 2013 at 3:04 PM, HuYanrui  wrote:

> **
> Ilya, or other guys.
> As previous mail indicated, we are a Loadbanlancer vendor.
> We already developed our driver as Grizzly design requirement.
> Now the driver is under internal testing.
> Could you guys suggest what's the next move for contributing? Where to
> post the code and where to require code review?
>
> And we also notice that in Havana there are big changes in LBaas and seems
> sturcture also changed to support multi vendors.
> Is anything we vendor also need change to sync with OpenStack movement?
>
> - Original Message -
> *From:* Ilya Shakhat 
> *To:* OpenStack Development Mailing List
> *Sent:* Thursday, December 20, 2012 7:27 PM
> *Subject:* Re: [openstack-dev] [Quantum]How to contribute LBaas driver?
>
> Hi Hu,Â
>
> Community plan to develop driver for HAProxy and this driver will be
> included into Griizly LBaaS by default. Other drivers are not mandatory and
> may be developed by vendors (we hope they will do this). The API for
> drivers is not finished yet, draft version is in blueprint
> https://blueprints.launchpad.net/quantum/+spec/lbaas-driver-api We plan
> to complete the specification right after G2 milestone.Â
>
> If you want to contribute driver code, the workflow is following:Â
> Â * write a blueprint describing feature set implemented by driver (e.g.
> what types of protocols and health monitors are supported)
> Â * write code and unit tests
> Â * post code to review and pass it
> Overall these steps may take some time, but imho there are chances to get
> into G release.
>
> Thanks,
> Ilya
>
> 2012/12/20 HuYanrui 
>
>> **
>> Sam, or other guys can help answer this.
>> I see the new plan is to finish the develop before milestone of
>> grizzly-3(2012/2/21).
>> And in the session minutes, it will include driver of
>> F5,Citrix,Redware,Brocade.
>> Who will do the coding of these drivers? The company that owned the
>> device?
>> We are also contribute our driver based on our Load balance device(based
>> on new LBaas structure), is ther any oppotunity to catch the grizzly
>> schedule?
>> I know there will be some code review or testing time, right?
>> Â
>>
>>  - Original Message -
>> *From:* Samuel Bercovici 
>> *To:* OpenStack Development Mailing List
>>  *Sent:* Thursday, December 06, 2012 11:33 PM
>> *Subject:* Re: [openstack-dev] [Quantum]How to contribute LBaas driver?
>>
>>  Hi,
>>
>> **Â **
>>
>> The code is part of the standard Quantum trunk. 
>>
>> The blue prints and code containing LBaaS are part of the **new** one.***
>> *
>>
>> **Â **
>>
>> Regards,
>>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  -Sam.
>>
>> **Â **
>>
>> **Â **
>>
>> *From:* Gavin Mu [mailto:gavin...@gmail.com]
>> *Sent:* Thursday, December 06, 2012 5:27 PM
>> *To:* OpenStack Development Mailing List
>> *Subject:* Re: [openstack-dev] [Quantum]How to contribute LBaas driver?**
>> **
>>
>> **Â **
>>
>> Hi, llya,
>>
>> **Â **
>>
>> Is there an URL of the *new* LBaaS code repo? I did not find anything
>> about LBaaS in quantum code repo, and I am still puzzled with the *current*
>> status after reading that wiki...
>>
>> **Â **
>>
>> is the 
>> Quantum/LBaaS/API_1.0Â in
>> wiki for the *new* LBaaS? and what is the current status? just a design or
>> have had a runable implementation? I noticed that it is different with the
>> *old* Mirantis/openstack-lbaas one.
>>
>> **Â **
>>
>> I also noticed that there are several blueprints and also codereview
>> which seems related with LBaaS, for example, 
>> lbaas-restapi-tenant,
>> is this the *new* one? and currently what can we do if we want to
>> design/code our drivers for the *new* one?
>>
>> **Â **
>>
>> Thanks & Regards,
>>
>> Gavin
>>
>> On Thu, Dec 6, 2012 at 6:02 PM, Ilya Shakhat 
>> wrote:
>>
>> Mirantis/openstack-lbaas is an "old" version for Essex release. It is a
>> separate project and it was not incorporated with Openstack nor official
>> devstack. The "new" LBaaS is a part of Quantum module and it will be
>> included into upcoming Grizzly release. All information about it is on
>> http://wiki.openstack.org/Quantum/LBaaS
>>
>> **Â **
>>
>> Thanks,
>>
>> Ilya
>>
>> **Â **
>>
>> **Â **
>>
>> 2012/12/6 HuYanrui 
>>
>> Thanks for Ilya's kindly reply.
>>
>> I previously got the code from github
>> https://github.com/Mirantis/openstack-lbaas
>>
>> Seems it's at least 2 months not updated. Is this the old one?
>>
>> By search the file system of devstack, I did not find cooresponding file
>> "*driver*" like in previous github files.
>>
>> Seems I need read more in this link
>> http://wiki.opens

Re: [openstack-dev] [Openstack][keystone][ldap] Bug unsupported operand type(s) for &: 'str' and 'int'

[ZhiQiang Fan]

your first reference (the log) is incorrect.


On Thu, Aug 22, 2013 at 2:55 PM, Qinglong.Meng wrote:

> Hi All,
> Os: Ubuntu 12.04 LTS
> keystone version: stable/grizzly
>
> After I deploy keystone with ldap backend (openldap), I got the issue
> about type in keystone.log, when I create user by  keystoneclient.
> Here are some docs:
> 1. keystone.log
> http://paste.openstack.org/
> 2. keystone.conf
> http://paste.openstack.org/show/44839/
> 3. slapd.conf
> http://paste.openstack.org/show/44843/
> 4. openstack.ldif
> http://paste.openstack.org/show/44844/
>
> And I think this is one bug, it's right?
>
> Best Regards,
>
> --
>
> Lawrency Meng
> mail: mengql112...@gmail.com
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openst...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack][keystone][ssl] Help for configure keystone with ssl.

[ZhiQiang Fan]

2013.2 should be in havana?


On Wed, Aug 21, 2013 at 6:13 PM, Qinglong.Meng wrote:

> Hi All,
> Os: ubuntu 12.04 LTS
> keystone version: stable/grizzly
>
> Ｉ hava seen "keystone-manage ssl_setup"  in keystone tag 2013.2.b1.
> but I can't use it in my version.
> So I want to know:
> * how to configure ssl with keystone manual?
> * how to test configure is ok?
>
> Tks for you help.
>
> Best Regards,
>
> --
>
> Lawrency Meng
> mail: mengql112...@gmail.com
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openst...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] git commit message: change id will before bug/bp when first commit

[ZhiQiang Fan]

thank you


On Mon, Aug 19, 2013 at 12:52 AM, Jeremy Stanley  wrote:

> On 2013-08-18 14:25:22 +0800 (+0800), ZhiQiang Fan wrote:
> > When submit code review in gerrit, i have been recommended put
> > Fixes-Bug: #bug-id/Implement-Blueprint: #bp-desc before chang-id.
> > However, when first run git commit in a seperate patch branch,
> > the change-id will generate before bug/bp, it is automatically,
> > so i have to use git commit --amend to modify the commit message
> > and put bug/bp before chang-id.
> >
> > Is there any way to let Change-id generate after whole commit
> > message? (more precisely, after bug/bp.)
>
> Gerrit's Change-Id metadata header line doesn't need to be the very
> last line, it just needs to be one of the lines in the last
> paragraph of the commit message. This is standard for all metadata
> headers including things common elsewhere like Signed-Off-By but the
> same goes for our Fixes/Partial/Related-Bug and Implements-Blueprint
> metadata headers as well. When used they should always appear
> one-per-line in the final paragraph of the commit message, but their
> relative order is unimportant.
> --
> Jeremy Stanley
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Exceptions in neutron.extension

[ZhiQiang Fan]

thanks, Matt Riedemann


On Sun, Aug 18, 2013 at 9:19 PM, Matt Riedemann  wrote:

> I don't know what's right but for what it's worth I had cleaned up at
> least one case like this where the exception was in both common and an
> extension:
>
> *https://bugs.launchpad.net/neutron/+bug/1210276*<https://bugs.launchpad.net/neutron/+bug/1210276>
>
> Seems to me like if more than one extension need the same type of
> exception and the error message can be written such that it can be re-used
> across extensions and common code, it should live in common to avoid
> duplication.
>
>
>
> Thanks,
>
> *MATT RIEDEMANN*
> Advisory Software Engineer
> Cloud Solutions and OpenStack Development
> --
>  *Phone:* 1-507-253-7622 | *Mobile:* 1-507-990-1889*
> E-mail:* *mrie...@us.ibm.com* 
> [image: IBM]
>
> 3605 Hwy 52 N
> Rochester, MN 55901-1407
> United States
>
>
>
>
>
> From:ZhiQiang Fan 
> To:OpenStack Development Mailing List <
> openstack-dev@lists.openstack.org>,
> Date:08/17/2013 09:55 PM
> Subject:[openstack-dev] [Neutron] Exceptions in neutron.extension
> --
>
>
>
> Hi stackers,
>
> I notice that there are some exceptions defined in neutron.extension, and
> many exceptions are defined in neutron.common.exception. Why they are
> defined seperately?
>
> In my opinion:
>
> 1) extension will define exception which is only releated to this
> extension and is intended to exposed to the client
> 2) exception defined in common.exception will be processed inside neutron,
> (It may define some exception releated to specific extension but the
> exception will be handled inside neutron.)
>
> I think my understanding is not right, so anyone please help me.
>
> --
> blog: *zqfan.github.com* <http://zqfan.github.com/>
> git: *github.com/zqfan* <http://github.com/zqfan>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
blog: zqfan.github.com
git: github.com/zqfan
<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] git commit message: change id will before bug/bp when first commit

[ZhiQiang Fan]

Hi, stackers,

When submit code review in gerrit, i have been recommended put Fixes-Bug:
#bug-id/Implement-Blueprint: #bp-desc before chang-id. However, when first
run git commit in a seperate patch branch, the change-id will generate
before bug/bp, it is automatically, so i have to use git commit --amend to
modify the commit message and put bug/bp before chang-id.

Is there any way to let Change-id generate after whole commit message?
(more precisely, after bug/bp.)

Thanks

-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Exceptions in neutron.extension

[ZhiQiang Fan]

Hi stackers,

I notice that there are some exceptions defined in neutron.extension, and
many exceptions are defined in neutron.common.exception. Why they are
defined seperately?

In my opinion:

1) extension will define exception which is only releated to this extension
and is intended to exposed to the client
2) exception defined in common.exception will be processed inside neutron,
(It may define some exception releated to specific extension but the
exception will be handled inside neutron.)

I think my understanding is not right, so anyone please help me.

-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev