[openstack-dev] [javascript] project name
Hi, Michael, I tried to fix an issue on project name in https://review.openstack.org/#/c/321908/1 but one unit test fails and I haven't figure it out yet. Could you help me to clarify the rule for project name? It seems it could be coming from the following 1. generator.appname => normalized parent directory name 2. project name entered by user 3. project name in .gitreivew -- Yujun __ OpenStack Development Mailing 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] failed to show graph topology on graph without root
Hi Eylon, Could you please provide the query and data which will reproduce this issue? -- Yujun On Thu, May 26, 2016 at 10:44 PM Malin, Eylon (Nokia - IL) < eylon.ma...@nokia.com> wrote: > Hi all, > > I use vitrage without any root graph (In my case there is no root). > Until few days ago I was able to request topology of type graph with no > problems. > But I can't, I got 404, and the log says it can't find openstack.cluster > node. > > I think it have the problems since these commits : > I1189047849f714d8435414cc48098d71837b3ed0, > I1438713136c0177282e8ee8e19a651af5590feef > > > Eylon > > __ > OpenStack Development Mailing 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] input erroneous `vitrage_id` in `vitrage rca show`API or `vitrage topology show` API
Hi, all I'm not sure if vitrage follows the RESTful API. In RESTful API, it is reasonable to return 404 error when the requested resource does not exist. If we want to display a friendly message, it could be implemented in front end. The backend API should remain simple and consistent since we may have different consumers, e.g. a CLI who does not understand error message at all. -- Yujun ZHANG On Wed, May 25, 2016 at 2:57 PM Afek, Ifat (Nokia - IL) wrote: > Hi dwj, > > > > I’m passing the question (and answer) to openstack mailing list. > > > > You are right. In case of an invalid vitrage id, we should not return HTTP > 404 error. I think the correct behavior would be to return a nice error > message like “Alarm XYZ does not exist”. > > You can open a bug about it. > > > > Thanks, > > Ifat. > > > > *From:* dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] > *Sent:* Wednesday, May 25, 2016 9:24 AM > *To:* Weyl, Alexey (Nokia - IL); Afek, Ifat (Nokia - IL); Rosensweig, > Elisha (Nokia - IL); Shamir, Ohad (Nokia - IL) > *Subject:* input erroneous `vitrage_id` in `vitrage rca show`API or > `vitrage topology show` API > > > > > Hi folks, > > `vitrage rca show` has the positional arguments: alarm_id > > `vitrage topology show` API has the optional arguments: --root > > They all means the `vitrage_id` in vertex, and those APIs also call the > function of `*graph_query_vertices*(*self*, query_dict=None, root_id=None, > depth=None, > direction=Direction.BOTH)` > > But if the user input the erroneous `vitrage_id` which was not exist in > the nodes, > Do the APIs all need to return the HTTP 404 error? > > See the code: > > https://github.com/openstack/vitrage/blob/master/vitrage/graph/algo_driver/networkx_algorithm.py#L43 > > Do we need to unify the return value as a empty graph in function ` > *graph_query_vertices*` > if the root is not be found or the root_data don't match the query? > Or leave it, don't modify, return the HTTP 404? > > Thanks. > > The error log: > stack@cloud:~$ vitrage rca show 'ALARM:nagios:cloud:test' > Unknown Error (HTTP 404) > > 2016-05-25 12:26:08.734 10742 DEBUG > vitrage.entity_graph.api_handler.entity_graph_api [-] EntityGraphApis > get_rca root:ALARM:nagios:cloud:test get_rca > /opt/stack/vitrage/vitrage/entity_graph/api_handler/entity_graph_api.py:114 > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher [-] > Exception during message handling: u'ALARM:nagios:cloud:test' > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher > Traceback (most recent call last): > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher File > "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", > line 138, in _dispatch_and_reply > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher > incoming.message)) > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher File > "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", > line 185, in _dispatch > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher > return self._do_dispatch(endpoint, method, ctxt, args) > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher File > "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", > line 127, in _do_dispatch > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher > result = func(ctxt, **new_args) > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher File > "/opt/stack/vitrage/vitrage/entity_graph/api_handler/entity_graph_api.py", > line 120, in get_rca > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher > direction=Direction.IN) > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher File > "/opt/stack/vitrage/vitrage/graph/algo_driver/networkx_algorithm.py", line > 43, in graph_query_vertices > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher > root_data = self.graph._g.node[root_id] > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher > KeyError: u'ALARM:nagios:cloud:test' > 2016-05-25 12:26:08.735 10742 ERROR oslo_messaging.rpc.dispatcher > 2016-05-25 12:26:08.759 10742 ERROR oslo_messaging._drivers.common [-] > Returning exception u'ALARM:nagios:cloud:test' to caller > > BR, > dwj > > > > > > 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
Re: [openstack-dev] [javascript] Seeking contributors, js-generator-openstack
Hi, all I'm happy to join the js-generator-openstack project. We have listed the todos in story board on https://storyboard.openstack.org/#!/project/842 Please feel free to take them and make contribution. -- Yujun Zhang On Mon, May 23, 2016 at 11:46 PM Michael Krotscheck wrote: > Good idea. Since we've already got a storyboard project, let's start there. > > Michael > > On Fri, May 20, 2016 at 4:02 PM Zhang Yujun > wrote: > >> Hi, Michael >> >> As you are no longer alone now, we'd better to put things in your head >> onto documents so that everybody who wish to contribute will know where to >> go. >> >> Besides the technical roadmap, I think we shall need a space for issue >> tracking and proposal discussion. After we make the project more open to >> the community, it won't be long that more developers join this project. >> >> That's my basic thoughts for the moment. >> >> -- >> Yujun >> >> On Sat, May 21, 2016 at 1:10 AM Michael Krotscheck >> wrote: >> >>> Hi there! >>> >>> Well, the first thing we need is other reviewers, which is the fastest >>> way to become a core :). The project page right now is the README.md >>> file in the project itself. The main reason for this is that the target >>> audience - javascript engineers - usually find that first via NPM. Most of >>> the Todo items there have already been done, actually, so the next step >>> would be to really identify what this project needs to accomplish, group it >>> into major categories, and start working on it. Off the top of my head, >>> here's a list: >>> >>> >>>1. Dependency synchronization: Keep a list of semver >>>global-dependencies.json at the root of the project, and update a >>> project's >>>dependencies if the versions are out of sync. >>>2. Eslint invocation. Infra's Common Testing Interface states that >>>all javascript projects must support 'npm run lint', using >>>eslint-config-openstack. The generator should add/update this to any >>>project it's run in. >>>3. nsp invocation. Not strictly necessary, but a postinstall scan of >>>the project for publicly known vulnerabilities is always a good thing. >>> >>> After these pieces, the next step becomes more complicated, as we need >>> to choose whether the user is creating a web application, or a node >>> application. This then allows us to switch out which test harness and >>> runner we're using, so that the `npm test` command can be consistent. Once >>> this lands, we can start talking about project src/dist directories, how to >>> best use gulp in each project type, and actual project templates :). >>> >>> Is there something in particular you'd like to work on? >>> >>> Michael >>> >>> >>> On Thu, May 19, 2016 at 12:39 AM Zhang Yujun >>> wrote: >>> >>>> Hi, Michael, >>>> >>>> I have several project experience in JavaScript and please let me know >>>> how I could help on this project? >>>> >>>> Is there a project page? >>>> >>>> Or we shall getting started with gerrit review? >>>> >>>> -- >>>> Yujun >>>> >>>> On Wed, May 18, 2016 at 11:45 PM Michael Krotscheck < >>>> krotsch...@gmail.com> wrote: >>>> >>>>> Hello everyone! >>>>> >>>>> The js-generator-openstack project has been incubated under >>>>> openstack-infra, and is seeking contributors (and cores). The purpose of >>>>> the project is as follows: >>>>> >>>>>- Help manage common project configuration aspects, such as >>>>>licenses, gerrit, authors, and more. >>>>>- Assist in keeping dependencies up-to-date and synchronized >>>>>across javascript projects (JS equivalent of global requirements). >>>>>- Provide all the necessary hooks for OpenStack's JavaScript >>>>>Common Testing Interface. >>>>>- Suggest common tools to use for tasks such as linting, unit >>>>>testing, functional testing, and more. >>>>>- (Newton Stretch) Provide a quick way of bootstrapping a new >>>>>CORS-consuming OpenStack UI. >>>>> >>>>> I'm looking for help- firstly, because right
Re: [openstack-dev] [javascript] Seeking contributors, js-generator-openstack
Hi, Michael As you are no longer alone now, we'd better to put things in your head onto documents so that everybody who wish to contribute will know where to go. Besides the technical roadmap, I think we shall need a space for issue tracking and proposal discussion. After we make the project more open to the community, it won't be long that more developers join this project. That's my basic thoughts for the moment. -- Yujun On Sat, May 21, 2016 at 1:10 AM Michael Krotscheck wrote: > Hi there! > > Well, the first thing we need is other reviewers, which is the fastest way > to become a core :). The project page right now is the README.md file in > the project itself. The main reason for this is that the target audience - > javascript engineers - usually find that first via NPM. Most of the Todo > items there have already been done, actually, so the next step would be to > really identify what this project needs to accomplish, group it into major > categories, and start working on it. Off the top of my head, here's a list: > > >1. Dependency synchronization: Keep a list of semver >global-dependencies.json at the root of the project, and update a project's >dependencies if the versions are out of sync. >2. Eslint invocation. Infra's Common Testing Interface states that all >javascript projects must support 'npm run lint', using >eslint-config-openstack. The generator should add/update this to any >project it's run in. >3. nsp invocation. Not strictly necessary, but a postinstall scan of >the project for publicly known vulnerabilities is always a good thing. > > After these pieces, the next step becomes more complicated, as we need to > choose whether the user is creating a web application, or a node > application. This then allows us to switch out which test harness and > runner we're using, so that the `npm test` command can be consistent. Once > this lands, we can start talking about project src/dist directories, how to > best use gulp in each project type, and actual project templates :). > > Is there something in particular you'd like to work on? > > Michael > > > On Thu, May 19, 2016 at 12:39 AM Zhang Yujun > wrote: > >> Hi, Michael, >> >> I have several project experience in JavaScript and please let me know >> how I could help on this project? >> >> Is there a project page? >> >> Or we shall getting started with gerrit review? >> >> -- >> Yujun >> >> On Wed, May 18, 2016 at 11:45 PM Michael Krotscheck >> wrote: >> >>> Hello everyone! >>> >>> The js-generator-openstack project has been incubated under >>> openstack-infra, and is seeking contributors (and cores). The purpose of >>> the project is as follows: >>> >>>- Help manage common project configuration aspects, such as >>>licenses, gerrit, authors, and more. >>>- Assist in keeping dependencies up-to-date and synchronized across >>>javascript projects (JS equivalent of global requirements). >>>- Provide all the necessary hooks for OpenStack's JavaScript Common >>>Testing Interface. >>>- Suggest common tools to use for tasks such as linting, unit >>>testing, functional testing, and more. >>>- (Newton Stretch) Provide a quick way of bootstrapping a new >>>CORS-consuming OpenStack UI. >>> >>> I'm looking for help- firstly, because right now I'm the only person >>> who's willing to review JavaScript amongst the various infra cores, and I'd >>> really like more eyeballs on this project. Secondly, because I know that >>> I'm not the only person who has opinions about how we should be doing >>> JavaScript things. >>> >>> Come on over to >>> https://review.openstack.org/#/q/project:openstack-infra/js-generator-openstack+status:open >>> and >>> help me out, would ya? If you've got questions, I'm active in the >>> #openstack-javascript channel. >>> >>> Michael >>> >> __ >>> OpenStack Development Mailing 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.
Re: [openstack-dev] [javascript] Seeking contributors, js-generator-openstack
Hi, Michael, I have several project experience in JavaScript and please let me know how I could help on this project? Is there a project page? Or we shall getting started with gerrit review? -- Yujun On Wed, May 18, 2016 at 11:45 PM Michael Krotscheck wrote: > Hello everyone! > > The js-generator-openstack project has been incubated under > openstack-infra, and is seeking contributors (and cores). The purpose of > the project is as follows: > >- Help manage common project configuration aspects, such as licenses, >gerrit, authors, and more. >- Assist in keeping dependencies up-to-date and synchronized across >javascript projects (JS equivalent of global requirements). >- Provide all the necessary hooks for OpenStack's JavaScript Common >Testing Interface. >- Suggest common tools to use for tasks such as linting, unit testing, >functional testing, and more. >- (Newton Stretch) Provide a quick way of bootstrapping a new >CORS-consuming OpenStack UI. > > I'm looking for help- firstly, because right now I'm the only person who's > willing to review JavaScript amongst the various infra cores, and I'd > really like more eyeballs on this project. Secondly, because I know that > I'm not the only person who has opinions about how we should be doing > JavaScript things. > > Come on over to > https://review.openstack.org/#/q/project:openstack-infra/js-generator-openstack+status:open > and > help me out, would ya? If you've got questions, I'm active in the > #openstack-javascript channel. > > Michael > __ > OpenStack Development Mailing 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
