Re: [openstack-dev] [tripleo] Deprecated Parameters Warning
Thanks Emilien. Now, the warning message for using a deprecated message is available for CLI. Sample message from CI [1] looks like below: 2017-07-14 19:45:09 | WARNING: Following parameters are deprecated and still defined. Deprecated parameters will be removed soon! 2017-07-14 19:45:09 | NeutronL3HA The next step is to add a warning (or rather error) message if a deployment contains a parameter which is not part of the plan (including custom templates). I will work on it. Regards, Saravanan KR [1] http://logs.openstack.org/77/479277/6/check-tripleo/gate-tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024/fb07fd6/logs/undercloud/home/jenkins/overcloud_deploy.log.txt.gz#_2017-07-14_19_45_09 On Tue, Jun 6, 2017 at 9:47 PM, Emilien Macchi wrote: > On Tue, Jun 6, 2017 at 6:53 AM, Saravanan KR wrote: >> Hello, >> >> I am working on a patch [1] to list the deprecated parameters of the >> current plan. It depends on a heat patch[2] which provides >> parameter_group support for nested stacks. The change is to add a new >> workflow to analyze the plan templates and find out the list of >> deprecated parameters, identified by parameter_groups with label >> "deprecated". >> >> This workflow can be used by CLI and UI to provide a warning to the >> user about the deprecated parameters. This is only the listing, >> changes are required in tripleoclient to invoke and and provide >> warning. I am sending this mail to update the group, to bring >> awareness on the parameter deprecation. > > I find this feature very helpful, specially with all the THT > parameters that we have and that are moving quite fast over the > cycles. > Thanks for working on it! > >> Regards, >> Saravanan KR >> >> [1] https://review.openstack.org/#/c/463949/ >> [2] https://review.openstack.org/#/c/463941/ >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Emilien Macchi > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Deriving Parameters from Introspection Data
On Sun, Jul 16, 2017 at 6:10 AM, Don maillist wrote: > Looks interesting. Wish I had this or something like it now for Newton and > OVS 2.6.1 which just dropped. Wondering why you don't include the grub > command line? KernelArgs parameter which will have iommu and huge page args are derived as part of this workflow, which will be applied to grub. Are you looking for any specific parameter? > > Do you have a stand alone utility? Not as of now. But we are looking in to the possibility of developing a utility tool for using it for Newton. I will post it when we have it. Regards, Saravanan KR > > Best Regards, > Don > > On Thu, Jul 6, 2017 at 4:10 AM, Saravanan KR wrote: >> >> Hello, >> >> DPDK is integrated with TripleO deployment during the newton cycle. >> From then on, we used to get queries on how to decide the right >> parameters for the deployment, which cpus to choose, how much memory >> to allocate and there on. >> >> In Pike, a new feature "derive parameters", has been brought in to >> help operators to automatically derive the parameters from the >> introspection data. I have created a 2 mins demo [1] to illustrate the >> feature integrated with CLI. This demo is created by integrating the >> in-progress patches. Let me know if you have any comments. >> >> The feature is almost at the last leg with the help from many folks. >> Following are the list of patches pending: >> https://review.openstack.org/#/c/480525/ (tripleoclient) >> https://review.openstack.org/#/c/468989/ (tripleo-common) >> https://review.openstack.org/#/c/471462/ (tripleo-common) >> >> Regards, >> Saravanan KR >> >> [1] https://asciinema.org/a/127903 >> >> __ >> OpenStack Development Mailing 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-dev] [Mogan]Tasks update of Mogan Project
Hi, We are glad to present this week's tasks update of Mogan. See the details below: Essential Priorities == 1. Track resources using placement service (liusheng, zhenguo) blueprint: https://blueprints.launchpad.net/mogan/+spec/track-resources-using-placement spec: https://review.openstack.org/#/c/475700/ merged code: https://review.openstack.org/#/c/476325/ https://review.openstack.org/#/c/477426/ https://review.openstack.org/#/c/477826/ https://review.openstack.org/#/c/478357/ https://review.openstack.org/#/c/478361/ https://review.openstack.org/#/c/478403/ https://review.openstack.org/#/c/478405/ https://review.openstack.org/#/c/478406/ 2. Node aggregates (liudong, zhangyang, zhenguo) blueprint: https://blueprints.launchpad.net/mogan/+spec/node-aggregate spec: https://review.openstack.org/#/c/470927/ 3.Server groups and scheduler hints(liudong, liusheng) blueprint: https://blueprints.launchpad.net/mogan/+spec/server-group-api-extension https://blueprints.launchpad.net/mogan/+spec/support-schedule-hints spec: None code: scheduler hints: https://review.openstack.org/#/c/463534/ 4. Adopt servers (wanghao, litao) blueprint: https://blueprints.launchpad.net/mogan/+spec/manage-existing-bms spec: https://review.openstack.org/#/c/459967/ merged code: https://review.openstack.org/#/c/479660/ 5. Valence integration (zhenguo, shaohe, luyao, Xinran) blueprint: https://blueprints.launchpad.net/mogan/+spec/valence-integration spec: https://review.openstack.org/#/c/441790/3/specs/pike/approved/valence-integration.rst 6. support runnig api server under uwsgi code: https://review.openstack.org/#/c/482057/ __ OpenStack Development Mailing 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] Idea of adding the language index to individual release notes
# moving from personal emails to openstack-dev ML
Thanks Doug for the advise.
openstackdocstheme looks a better place to support the language index
for individual release note pages.
I will look into how we can support it in openstackdocstheme.
At now, the releasenote is built as a separate sphinx project, so the
openstackdocstheme support would be straight-forward just by checking
the availability of PO files for individual languages.
Once we move the doc build to more unified way, we might need more
fine-grained way to control the language index.
We can start some simple approach and then enhance it gradually.
2017-07-11 23:35 GMT+09:00 Doug Hellmann :
>
> On Jul 11, 2017, at 9:18 AM, Andreas Jaeger wrote:
>
> On 2017-07-11 14:43, Akihiro Motoki wrote:
>
> Hi Doug, Ian, Andreas,
>
> I proposed a patch to add the language index to all release notes files.
> https://review.openstack.org/#/c/481850/
>
> Your feedback would be appreciated.
> Thanks Andreas for the initial feedback too.
>
> Release notes files are usually not accessed through index.html
> and release notes of individual releases are accessed directly as they
> are linked from releases.openstack.org.
> I think it is useful to have the language list for all release notes files
> so that readers can easily find translated versions.
>
> The similar approach is being proposed to the i18n guide.
> https://review.openstack.org/#/c/479472/
> Sample output is like this:
> http://docs-draft.openstack.org/72/479472/6/check/gate-i18n-tox-doc-publish-docs/91e920e//publish-docs/i18n/latest/
>
>
> Doug,
>
> here's one thing to look into when moving release-notes into main build
> - how to translate them. Do we translate the release notes separately
> (we can do that since each file is a separate translatable target) or
> only the full guide ?
>
> 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
>
>
> I replied on the review, but in case you didn’t see that message:
>
> I like the idea of doing this, but I'm not sure this is the right
> implementation, for 2 reasons:
>
> 1. We are going to have to solve a similar problem for content in the
> doc/source directories for projects (installation guides, especially).
> 2. The special releasenotes build job will go away when we merge it into
> doc/source and use the single unified job.
>
> Do you think it would be possible to do something in the openstackdocstheme
> to add the necessary links?
>
> Perhaps we can continue this discussion on openstack-dev?
>
> 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-dev] [Dragonflow] Weekly meetings time change
Hi, Please note that the weekly meeting times have changed. We have changed to an alternating schedule, once on Monday 19:00 UTC (Tomorrow, and every two weeks), and once on Monday 8:00 UTC (Starting next week). Thanks, Omer Anson. __ OpenStack Development Mailing 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] Collectd notification isn't shown on the Vitrage Graph
Hi Volodymyr,
According to the vitrage-collector.log, when the alarm is cleared it has a
different message:
Raise alarm:
{'vitrage_datasource_action': 'update', 'resource_name': u'qvo818dd156-be',
u'severity': u'WARNING', u'plugin': u'ovs_events', 'vitrage_entity_type':
'collectd', u'id': u'd211725834f26fa268016d8b23adf7d7', 'vitrage_sample_date':
'2017-07-14 07:31:21.405670+00:00', u'host': u'silpixa00399503', u'time':
1500017481.363748, u'collectd_type': u'gauge', u'plugin_instance':
u'qvo818dd156-be', u'type_instance': u'link_status', 'vitrage_event_type':
u'collectd.alarm.warning', u'message': u'link state of "qvo818dd156-be"
interface has been changed to "DOWN"', 'resource_type': u'neutron.port'}
Clear alarm:
{'vitrage_datasource_action': 'update', 'resource_name': u'qvo818dd156-be',
u'severity': u'OK', u'plugin': u'ovs_events', 'vitrage_entity_type':
'collectd', u'id': u'd211725834f26fa268016d8b23adf7d7', 'vitrage_sample_date':
'2017-07-14 07:31:35.851112+00:00', u'host': u'silpixa00399503', u'time':
1500017495.841522, u'collectd_type': u'gauge', u'plugin_instance':
u'qvo818dd156-be', u'type_instance': u'link_status', 'vitrage_event_type':
u'collectd.alarm.ok', u'message': u'link state of "qvo818dd156-be" interface
has been changed to "UP"', 'resource_type': u'neutron.port'}
The ‘message’ is converted to the name of the alarm, which is considered part
of its unique key. If the message is changed from “DOWN” to “UP”, we don’t
recognize that it’s the same alarm.
Any idea how this can be solved? Can you modify the message so it will be the
same in both cases? Or is there another field that can uniquely identify the
alarm?
Thanks,
Ifat.
From: "Mytnyk, VolodymyrX"
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Friday, 14 July 2017 at 10:56
To: "OpenStack Development Mailing List (not for usage questions)"
Cc: "Tahhan, Maryam"
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the
Vitrage Graph
Hi Ifat,
Thank you for fixing the issue. The patch works and I’m able to
map the alarm to port now. Also, as a workaround, I was able to fix/resolve the
issue by creating the static datasource (attached static_port.yaml) and
disabling the neutron port datasource in the vitrage.conf.
Another issue that I still observe is the deleting of the alarm from the graph
when OK collectd notification is sent (port is becomes up). Currently, it is
not removed from the entity graph. Is it an issue in the Vitrage too? Attaching
all logs (collected using the fix provided by you).
The 3rd issue is the Vitrage-Mistral integration, but I will describe this as a
separate mail thread.
Thanks and Regards,
Volodymyr
From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Thursday, July 13, 2017 5:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Tahhan, Maryam
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the
Vitrage Graph
Hi Volodymyr,
I believe that this change[1] will fix your problem.
[1] https://review.openstack.org/#/c/482212/
Best Regards,
Ifat.
From: "Mytnyk, VolodymyrX"
mailto:volodymyrx.myt...@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 11 July 2017 at 12:48
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Cc: "Tahhan, Maryam" mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the
Vitrage Graph
Hi Ifat,
Thank you for investigating the issue.
The port name is unique on the graph. The ovs port name in collectd ovs_events
plugin is identified by the ‘plugin_instance’ notification field.
Thanks and Regards,
Volodymyr
From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Tuesday, July 11, 2017 12:00 PM
To: OpenStack Development Mailing List (not for usage questions)
mailto:openstack-dev@lists.openstack.org>>
Cc: Tahhan, Maryam mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the
Vitrage Graph
Hi Volodymyr,
I’m working on this issue.
One question: is the port name, as defined by ‘plugin_instance’, supposed to be
unique in the graph? If not, then how do you uniquely identify the port (in
collectd)?
Thanks,
Ifat.
From: "Mytnyk, VolodymyrX"
mailto:volodymyrx.myt...@intel.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, 7 July 2017 at 13:27
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Cc: "Tahhan, Maryam" mailto:maryam.tah...@intel.com>>
Subject: Re: [openstack-dev] [Vitrage] Collectd notification isn't shown on the
Vitrage Graph
Hi Ifat,
I’ve tested the template file modi
Re: [openstack-dev] [Vitrage] Vitrage-Mistral integration problem
Hi Volodymyr, The Vitrage-Mistral integration is still WIP, so it is possible that something was broken. I hope to finish the development in a few days, and I will definitely check your patch as part of it. I’ll update you once I’m done. Best Regards and thanks for the patch, Ifat. From: "Mytnyk, VolodymyrX" Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Friday, 14 July 2017 at 11:43 To: "OpenStack Development Mailing List (not for usage questions)" Cc: "Tahhan, Maryam" Subject: [openstack-dev] [Vitrage] Vitrage-Mistral integration problem Hi Ifat, The Vitrage notifier fails to start with mistral plugin (applied the patch from https://review.openstack.org/#/c/461265/2 ) due to the following errors (see attached logs for more details): 2017-07-14 09:06:26.135 174776 ERROR vitrage File "/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2942, in _get_opt_info 2017-07-14 09:06:26.135 174776 ERROR vitrage raise NoSuchOptError(opt_name, group) 2017-07-14 09:06:26.135 174776 ERROR vitrage NoSuchOptError: no such option auth_url in group [service_credentials] For some reason, the auth_url option in service_credentials group of vitrage.conf is not available for the mistral plugin. I suppose, the problem happens because of https://github.com/openstack/vitrage/commit/b744994b987e5c4466f91cb863090a5a2236e453 commit. The problem can be resolved by applying the attached patch (workaround crated by me) that allows Vitrage to start and integrate it with Mistral properly. Is it an issue in the Mistral plugin or some addition configuration are required for the Vitrage/Mistral to work together? Thanks and Regards, Volodymyr __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
