Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state()

[Yujun Zhang (ZTE)]

I have almost understood it thanks to your explanation.

The confusion is mainly caused by the naming. I guess the main reason is
that the scope evolves but the naming is not updated with it.

For example

   1. `vitrage_aggregated_state` actually applies for both resource state
   and alarm severity as defined in `value_properties`. So
   `vitrage_aggregated_values` could be a better name.
   2. For data source in static configuration, we may use `static.yaml` as
   a fallback. The name `default.yaml` will mislead user that it should be
   applied to data source configured in "types" but without a values
   configuration.
   3. The UNDEFINED value is named UNDEFINED_DATASOURCE = "undefined
   datasource", it is not a consistent type of severity and state enumeration.
   4. The behavior for data source defined in static without values
   configuration and data source defined in "types" without values
   configuration are inconsistent. The former will fallback to `default.yaml`
   but the latter will lead to undefined value.

I know it is there for historical reasons and current developers may
already get used to it, but it gives new contributors too many surprises.

What do you think? Shall we amend them?

On Tue, Jan 9, 2018 at 11:29 PM Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi,
>
>
>
> I agree that the code is confusing…
>
>
>
> This is part of a change that was made in order to support default states
> for static entities. For example, in the static configuration yaml file you
> can add entities of types ‘switch’ and ‘br-ex’. In the past, in order to
> support states for these new types, you needed to add switch.yaml and
> br-ex.yaml under /etc/vitrage/datasources_values, which you would most
> likely copy from another datasource. Now, we have under
> /etc/vitrage/datasources_values a default.yaml file that is used for all
> static entities.
>
>
>
> Back to the code, I believe this is the logic:
>
>
>
> · If the datasource is part of ‘types’ (as defined in
> vitrage.conf) and has states configuration – use it. This is the normal
> behavior.
>
> · If the datasource is not part of ‘types’, we understand that it
> was defined in a static configuration file. Use the default states
> configuration. I assume that it is somehow handled in the first part of the
> if statement (I’m not so familiar with that code)
>
> · If neither is true – it means that the datasource is “real” and
> not static, and was defined in vitrage.conf types. And it also means that
> its states configuration is missing, so the state is UNDEFINED.
>
>
>
> And to your questions:
>
>
>
>1. the data source is not defined -> the default states should be used
>2. data source defined but state config not exist -> UNDEFINED state
>3. data source defined, state config exist but the state is not found.
>-> I believe that somewhere in the first part of the if statement you will
>    get UNDEFINED
>
>
>
>
>
> Hope that’s more clear now. It might be a good idea to add some comments
> to that function…
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
>
>
> *From: *"Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Tuesday, 9 January 2018 at 8:34
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [vitrage] rules in
> vitrage_aggregated_state()
>
>
>
> Forgot to paste the link to the related code:
>
>
>
>
> https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61
>
>
>
>
>
>
>
> On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>
> wrote:
>
> Hi root causers
>
>
>
> I have been inspecting the code about aggregated state recently and have a
> question regarding the rules.
>
>
>
> The "not" operator in the if clause confuses me. If it is not a configured
> data source, how do we apply the aggregation rules? It seems this is
> handled in else clause.
>
>
>
> if datasource_name in self.datasources_state_confs or \
>
> datasource_name *not* in self.conf.datasources.types: 
>...
>
> else:
>
> self.category_normalizer[vitrage_category].set_aggregated_value(
>
> new_vertex, self.UNDEFINED_DATASOURCE)
>
> self.category_normalizer[vitrage_category].set_operat

Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state()

[Yujun Zhang (ZTE)]

Forgot to paste the link to the related code:

https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61



On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>
wrote:

> Hi root causers
>
> I have been inspecting the code about aggregated state recently and have a
> question regarding the rules.
>
> The "not" operator in the if clause confuses me. If it is not a configured
> data source, how do we apply the aggregation rules? It seems this is
> handled in else clause.
>
> if datasource_name in self.datasources_state_confs or \
> datasource_name *not* in self.conf.datasources.types: 
>...
>
> else:
> self.category_normalizer[vitrage_category].set_aggregated_value(
> new_vertex, self.UNDEFINED_DATASOURCE)
> self.category_normalizer[vitrage_category].set_operational_value(
> new_vertex, self.UNDEFINED_DATASOURCE)
>
>
> There are some test case describing the expected behavior. But I couldn't 
> understand the design philosophy behind it. What is expected when
>
>1. the data source is not defined
>2. data source defined but state config not exist
>3. data source defined, state config exist but the state is not found.
>
> Could somebody shed some light on it?
>
>
>
> --
> Yujun Zhang
>


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

[openstack-dev] [vitrage] rules in vitrage_aggregated_state()

[Yujun Zhang (ZTE)]

Hi root causers

I have been inspecting the code about aggregated state recently and have a
question regarding the rules.

The "not" operator in the if clause confuses me. If it is not a configured
data source, how do we apply the aggregation rules? It seems this is
handled in else clause.

if datasource_name in self.datasources_state_confs or \
datasource_name *not* in self.conf.datasources.types:
  ...

else:
self.category_normalizer[vitrage_category].set_aggregated_value(
new_vertex, self.UNDEFINED_DATASOURCE)
self.category_normalizer[vitrage_category].set_operational_value(
new_vertex, self.UNDEFINED_DATASOURCE)


There are some test case describing the expected behavior. But I
couldn't understand the design philosophy behind it. What is expected
when

   1. the data source is not defined
   2. data source defined but state config not exist
   3. data source defined, state config exist but the state is not found.

Could somebody shed some light on it?



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

Re: [openstack-dev] [infra] support graphviz in document publishing

[Yujun Zhang (ZTE)]

On Tue, Nov 14, 2017 at 5:05 AM Antoine Musso  wrote:

> Hello,
>
> I had some success with http://blockdiag.com/ which, IIRC, is pure
> python. It supports various kind of graphs (block, sequences, network ...).
>
> The few I did were for Zuul:
> https://docs.openstack.org/infra/zuul/user/gating.html
>
> In sphinx that looks like:
>
> .. blockdiag::
>
>   blockdiag foo {
> node_width = 40;
> span_width = 40;
> A <- B <- C <- D <- E;
>   }
>
>
> sphinxcontrib-blockdiag
> https://pypi.python.org/pypi/sphinxcontrib-blockdiag
>
> Might be worth looking at if you want something simpler than graphviz
> and to not depend on it.
>

Really nice diagram and syntax. I will surely consider it for some workflow
in the specification.

Thank you for the recommendation, Antoine

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

Re: [openstack-dev] [infra] support graphviz in document publishing

[Yujun Zhang (ZTE)]

On Mon, Nov 13, 2017 at 5:41 PM Andreas Jaeger  wrote:

> You can easily include them for any repository - add the python
> requirements to test-requirments and add the binary requirements to
> bindep.txt - as explained in
> https://docs.openstack.org/infra/manual/drivers.html#package-requirements


Thanks Andreas.

Besides the dependency you mentioned, I just realized that we need also to
add the extension to sphinx conf[1] to make it effective.

https://review.openstack.org/#/c/518196/8/doc/source/conf.py
-- 
Yujun Zhang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [infra] support graphviz in document publishing

[Yujun Zhang (ZTE)]

Hi, all

Sometimes a picture worths thousands word. I wonder if it is possible to
support graphviz in https://docs.openstack.org/

What I expect is to include a dot file and render it as a picture in HTML
output. The syntax is simple

.. graphviz:: aggregate-equivalent-alarms.files/example.dot

And should be supported by sphinx graphviz plugin[2]

See full example[1]. Currently I render the picture offline and include it
manually in the document. It would be much more convenient for developer if
the extension is added to document build job.

[1]:
https://review.openstack.org/#/c/518196/5/proposals/aggregate-equivalent-alarms.rst
[2]: http://www.sphinx-doc.org/en/stable/ext/graphviz.html

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

[openstack-dev] [oslo][oslo.middleware] when will next release arrive

[Yujun Zhang (ZTE)]

Hi oslo cores,

It has been more than one month since last release of oslo.middleware
(3.30.0 on July 18th). I wonder when will next release arrive.

I'm asking it because some bug fix[1] is depending the patch sets to be
released[2].

[1]: https://review.openstack.org/#/c/487388/
[2]: https://review.openstack.org/#/c/487454/

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

[openstack-dev] [vitrage] status of blueprint crud-templates

[Yujun Zhang (ZTE)]

Hi, root causers :-)

We recently starts to looking into the CRUD of templates to allow loading
them when vitrage is up. It seems there is already one blueprint
registered[1] for exactly the same purpose.

Is there any detailed design about it? Do you have already some ideas in
mind?

[1] https://blueprints.launchpad.net/vitrage/+spec/crud-templates

-- 
Yujun Zhang
__
OpenStack Development Mailing 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] Nominating Yujun Zhang to Vitrage core

[Yujun Zhang (ZTE)]

Thanks all.

It is my pleasure to work with you in Vitrage project :-)

--
Yujun

On Mon, Jun 26, 2017 at 4:34 PM Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi,
>
>
>
> I added Yujun Zhang to the vitrage-core team. Yujun, Welcome J
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
> *From: *דני אופק 
> *Date: *Monday, 26 June 2017 at 11:00
>
>
>
> +1
>
>
>
> On Mon, Jun 26, 2017 at 7:45 AM, Weyl, Alexey (Nokia - IL/Kfar Sava) <
> alexey.w...@nokia.com> wrote:
>
> +1
>
>
>
> > -Original Message-
> > From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
> > Sent: Sunday, June 25, 2017 3:18 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> >
> > Hi,
> >
> > I’d like to nominate Yujun Zhang to the Vitrage core team.
> >
> > In the last year Yujun has made a significant contribution in
> Vitrage[1], both
> > by adding new features and by reviewing other people’s work. He has an
> > extensive knowledge of the Vitrage architecture and code, and I believe
> he
> > would make a great addition to our team.
> >
> > Best Regards,
> > Ifat.
> >
> > [1]
> > https://review.openstack.org/#/q/owner:zhang.yujunz%2540zte.com.cn+pr
> > ojects:openstack/vitrage+is:merged
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Yujun Zhang
__
OpenStack Development Mailing 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] First Vitrage Pike release by the end of this week

[Yujun Zhang (ZTE)]

Is it done yet?

How to fetch the released version for downstream developing?

On Tue, Jun 6, 2017 at 2:17 PM Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi,
>
> Pike-2 milestone is at the end of this week, and although we are not
> working by the milestones model (we are working by a
> cycle-with-intermediary model) we need to have the first Vitrage Pike
> release by the end of this week.
>
> I would like to release vitrage, python-vitrageclient and
> vitrage-dashboard tomorrow. Any objections? Please let me know if you think
> something has to be changed/added before the release.
>
> Also, we need to add release notes for the newly added features. This list
> includes (let me know if I missed something):
>
> vitrage
> • Vitrage ID
> • Support ‘not’ operator in the evaluator templates
> • Performance improvements
> • Support entity equivalences
> • SNMP notifier
>
> python-vitrageclient
> • Multi tenancy support
> • Resources API
>
> vitrage-dashboard
> • Multi tenancy support – Vitrage in admin menu
> • Added ‘search’ option in the entity graph
>
> Please add a release notes file for each of your features (I’ll send an
> explanation in a separate mail), or send me a few lines of the feature’s
> description and I’ll add it.
>
> Thanks,
> Ifat.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Yujun Zhang
__
OpenStack Development Mailing 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] Gate issues

[Yujun Zhang (ZTE)]

We have encountered similar issue also in OPNFV.

It seems to be a problem of setuptools 36.0.0 and it is now removed from
pypi. Hope it resolves the vitrage gate tests as well.

See discussion in https://github.com/pypa/setuptools/issues/1042


On Thu, Jun 1, 2017 at 11:08 PM Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi,
>
>
>
> Note that we are currently having problems with the Vitrage gate tests,
> related to python-setuptools. Other projects experience similar problems.
> We hope to fix it by the beginning of next week.
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Yujun Zhang
__
OpenStack Development Mailing 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] error handling

[Yujun Zhang (ZTE)]

On Thu, Jun 1, 2017 at 10:49 PM Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

So for now we agree that we need to add a UI for configuration information
> and datasources status.
>
>
Sounds good. In order to implement in UI, we shall also need api to expose
them right?

-- 
Yujun Zhang
__
OpenStack Development Mailing 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] error handling

[Yujun Zhang (ZTE)]

On Tue, May 30, 2017 at 3:59 PM Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi Yujun,
>
>
>
> You started an interesting discussion. I think that the distinction
> between an operational error and a programmer error is correct and we
> should always keep that in mind.
>
>
>
> I agree that having an overall design for error handling in Vitrage is a
> good idea; but I disagree that until then we better let it crash.
>
>
>
> I think that Vitrage is made out of many pieces that don’t necessarily
> depend on one another. For example, if one datasource fails, everything
> else can work as usual – so why crash? Similarly, if one template fails to
> load, all other templates can still be activated.
>

This usually or always happens during initialization phase, doesn't it? It
is a period with human inspecting and should be detected in the deployment
or user acceptance test. So if something fails, it is better to isolate
them before continue running, e.g. correct the invalid template, invalid
data source configuration or remove the template and disable the data
source. This is because such error is permanent and they won't recover
automatically.

Here we need to distinguish the error that data source is temporarily
unavailable due to network connection issue or data source not up yet. In
this case, I agree we'd better start the rest component and perform a retry
periodically until it recovers.


> Another aspect is that the main purpose of Vitrage is to provide insights.
> In case of a failure in one datasource/template, some of the insights might
> be missing. But this will not lead to inaccurate behavior or to wrong
> actions being executed in the system. IMO, we should give the user as much
> information as possible given that we have only part of the input.
>

I agree, if enough insights could be provided by the running system. We can
improve the handling of permanent error. What is even better is supporting
of a hot load for the components and templates.

What I don't like much is sometimes errors are handled but without enough
details. In this case, a crash with trace stack is more useful than a user
"friendly" message like "failed to start xxx component" or "invalid
configuration file" (I'm not talking about vitrage, it is quite common in
many projects)

My preference is "good error handling" > "no error handling" > "bad error
handling". Though it is difficult to distinguish what is a good error
handling and what is bad...

Regarding the use cases that you mentioned:
>
>
>
>1. invalid configuration file
>
> [Ifat] This should depend on the specific configuration. If keystone is
> misconfigured, nothing will work of course. But if for example Zabbix is
> misconfigured, Vitrage should work and show the topology and the non-Zabbix
> alarms.
>

Agree. It should be handled in a different way regarding what kind of error
and how critical it is.


>
>1. failed to communicate with data source
>
> [Ifat] I think that the error should be logged, and all other datasources
> should work as usual.
>

Yes, and it would be good to have a retry mechanism


>
>1. malformed data from data source
>
> [Ifat] I think that the error should be logged, and all other datasources
> should work as usual. This problem means we must modify the code in the
> datasource itself, but until then Vitrage should work, right?
>
Yes, I think it is possible when the data source version changes and we
should discard the data and indicate the error. The other part should not
be affected.


>1. failed to execute an action
>
> [Ifat] Again, that’s a problem that requires code changes; but why fail
> other actions?
>

What I meant here is temporary failure, e.g. when you try to mark host down
but not able to reach it due to network connection issue or other reasons


>1. ...
>
> BTW, it might be a good idea to add API/UI for showing the configuration
> and the status of the datasources. We all know that errors in the log files
> are often ignored…
>

Sure, the errors I mentioned above is what the system operators could
encounter even with a correct configuration and not related to software
bugs. Display them in UI would be very helpful. The log files are more for
the engineers to analyse the root cause.


> Best Regards,
>
> Ifat.
>
>
>
>
>
> *From: *"Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Monday, 29 May 2017 at 16:13
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>

[openstack-dev] [vitrage] error handling

[Yujun Zhang (ZTE)]

Brought up by a recent code review, I think it worth a thorough discussion
about the error handling rule.

I once read an article[1] from Joyent and it impressed me on the
distinguish between *Operational* errors vs. *programmer* errors. The
article is written for nodejs, but the principle also applies for other
programming language.

The basic rule recommended by Joyent is
Handling operational errors
(Not) handling programmer errors
There is also one rule in openstack style guide line[2] close to this idea.

[H201] Do not write except:, use except Exception: at the very least. When
catching an exception you should be as specific so you don’t mistakenly
catch unexpected exceptions.

I do think before we have a well designed error handling, it is better to
let it crash. It is dangerous to hide the errors and keep the system
running in undetermined states.

So the question is *what kind of operational errors are we facing in
vitrage?* I can think of something like

   1. invalid configuration file
   2. failed to communicate with data source
   3. malformed data from data source
   4. failed to execute an action
   5. ...

Maybe this could be the first step for the error handling design.

[1]: https://www.joyent.com/node-js/production/design/errors
[2]: https://docs.openstack.org/developer/hacking/

-- 
Yujun Zhang
__
OpenStack Development Mailing 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] trouble installing Nagios on devstack on ubuntu 16.04 ...

[Yujun Zhang (ZTE)]

One easy way could be writing a scenario to raise deduced alarm based on a
simple rule, e.g. when a host is discovered, raise an alarm saying host is
up.

Waines, Greg 于2017年5月4日 周四04:35写道：

> I don’t think I saw any responses to this.
>
>
>
> Alternative question ... so I’ve got vitrage up and running fine ...
>
>
>
> What’s the easiest way to generate an alarm against a host ?   ( OTHER
> than NAGIOS, due to problem in original email ) ???
>
>
>
> let me know any ideas,
>
> Greg.
>
>
>
>
>
> *From: *Greg Waines 
> *Date: *Tuesday, May 2, 2017 at 9:03 AM
> *To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [vitrage] trouble installing Nagios on
> devstack on ubuntu 16.04 ...
>
>
>
> Hey ... I’m working thru the ‘Vitrage - Getting Started Guide’
>
>
>
> https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html
>
>
>
> Was able to get vitrage up and running and enabled in horizon ... on
> ubuntu 16.04 .
>
>  ( I tried on ubuntu 14.04 and ‘./stack.sh’ warned that it had not
> been tested on trusty (14.04), I FORCE=yes it ... but it failed. )
>
>
>
>
>
> Now trying to install Nagios in devstack
>
>
> https://docs.openstack.org/developer/vitrage/nagios-devstack-installation.html
>
>
>
> BUT it doesn’t seem like there is an OMD package available for ubuntu
> 16.04 ... and the trusty (14.04) package won’t install due to dependency
> issues.
>
>
>
>
>
>
>
> Any suggestions ?
>
>
>
> Greg.
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Yujun Zhang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [vitrage] use case repository

[Yujun Zhang (ZTE)]

Hi root causers,

Use case repository is considered as one of the very important subject to
work on in Pike release[1].

I wonder what kind of use cases we have deployed/validated in vitrage, no
matter in production or experimental, and where can I find related
information?

[1]: https://wiki.openstack.org/wiki/Vitrage/RoadMap#Very_important

-- 
Yujun Zhang
__
OpenStack Development Mailing 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] [stackalytics] user correction seems not effective

[Yujun Zhang (ZTE)]

Hi, Trinath

What failure are you referring to exactly? It seems all jobs passed
normally.

I know there are some error message in the console logs, but that seems to
be expected failures for negative test cases.

On Mon, Mar 20, 2017 at 12:16 PM Trinath Somanchi <trinath.soman...@nxp.com>
wrote:

Jenkins is throwing some Failures in new submissions. That might be an
issue.

Get Outlook for iOS <https://aka.ms/o0ukef>

------
*From:* Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>
*Sent:* Monday, March 20, 2017 8:47:30 AM
*To:* shak...@gmail.com
*Cc:* OpenStack Development Mailing List (not for usage questions); 张玉军
*Subject:* [openstack-dev] [stackalytics] user correction seems not
effective

Hi, Ilya

I submitted a patch for user correction[1] several months ago. It is
supposed to reset the Email list of user `zhangyujun`. But it seems not
effective from the response of stackalytics api.

curl http://stackalytics.com/api/1.0/users/zhangyujun

{"user": {"launchpad_id": "zhangyujun", "user_id": "zhangyujun", "seq":
65434, "company_link": "EasyStack", "text": "Zhang
Yujun", "companies": [{"company_name": "ZTE Corporation", "end_date":
1474588800}, {"company_name": "EasyStack", "end_date": 0}], "id":
"zhangyujun", "static": true, "gerrit_id": "zhangyujun", "user_name":
"Zhang Yujun", "emails": [*"zhangyujun.d...@gmail.com
<zhangyujun.d...@gmail.com>", "zhangyu...@gmail.com <zhangyu...@gmail.com>"*,
"284517...@qq.com", "zhangyujun+...@gmail.com", "yujun.zh...@easystack.cn",
"zhang.yuj...@zte.com.cn"]}}

The email address in red should be removed if the patch works as expected.

Is there any way I can make further investigation on this issue? The log
message from the stackalytics server might be helpful.

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

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

-- 
Yujun Zhang
__
OpenStack Development Mailing 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] [stackalytics] user correction seems not effective

[Yujun Zhang (ZTE)]

Hi, Ilya

I submitted a patch for user correction[1] several months ago. It is
supposed to reset the Email list of user `zhangyujun`. But it seems not
effective from the response of stackalytics api.

curl http://stackalytics.com/api/1.0/users/zhangyujun

{"user": {"launchpad_id": "zhangyujun", "user_id": "zhangyujun", "seq":
65434, "company_link": "EasyStack", "text": "Zhang
Yujun", "companies": [{"company_name": "ZTE Corporation", "end_date":
1474588800}, {"company_name": "EasyStack", "end_date": 0}], "id":
"zhangyujun", "static": true, "gerrit_id": "zhangyujun", "user_name":
"Zhang Yujun", "emails": [*"zhangyujun.d...@gmail.com
", "zhangyu...@gmail.com "*,
"284517...@qq.com", "zhangyujun+...@gmail.com", "yujun.zh...@easystack.cn",
"zhang.yuj...@zte.com.cn"]}}

The email address in red should be removed if the patch works as expected.

Is there any way I can make further investigation on this issue? The log
message from the stackalytics server might be helpful.

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

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

[openstack-dev] [vitrage] what is "API to register on Vitrage notificaitons"

[Yujun Zhang (ZTE)]

Hi root causers

I want to confirm some detail about one subject in vitrage Pike roadmap


   - API to register on Vitrage notificaitons


Is it linked to blueprint
https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications ?

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