Meeting time： 2015.August.11th 1:00~2:00
Chairperson： Serg Melikyan, PTL from Mirantis
Meeting summary：
1.Migrating to yaql 1.0 status.
PIC: Stan Lagun
Status: New yaql engine should be fully functional at the moment.
The yaql rc2 will be released at once.
In the requirements.txt of Murano, the community decide to pin yaql==1.0.0rc2.
Let folks to test with rc2 and if everything work fine,
we will make rc2 to be released and merged in Murano.
Action: Kirill Zaitsev will write an email to encourage murano team and murano users to test new yaql.
Links: https://review.openstack.org/#/c/211678
2.Glance Artifact Repository(glance v3) transition status.
PIC: Alexander Tivelkov
What's Glance Artifact Repository?
Artifact Extend Glance's functionality to store not only the VM images but any other artifacts, i.e binary objects accompanied with composite metadata.
Glance should become a catalog of such artifacts, providing capabilities to store, search and retrieve their artifacts, their metadata and associated binary objects.
VM images are one example of artifacts, but artifacts could also be Murano Application Packages, Mistral Workbooks, Heat templates or Solum Plan Files.
Each type of artifact corresponds to its own plug-in (module), which defines the artifact’s custom metadata fields, BLOB kinds, importing logic, and so on.
Users will work with artifacts through a unified interface similar to the one used for Nova images.
Each installed module will have a name correspondent with the REST API.
For example, a Murano application catalog (apps) could be /v3/artifacts/apps.
Action: There is a bunch of bugs in glance reported related to Artifact filtering by version,
Ativelkov is working on bugs , and plugin for Murano is published.
The code in python-muranoclient has to wait till the fixes are in place.
(till release an experimatal version of python-glanceclient with v3 support)
The plan is to close the glance bugs later this week, so we may proceed.
We'll have to add artifacts support to python-muranoclient afterwards.
Link: https://www.mirantis.com/blog/openstack-glances-artifacts/
3.Research Oslo.log library 1.8
Status: TRACE is a logging keyword that is understood by most logging tools.
OpenStack has repurposed this in the past to not be TRACE logging
but instead be used whenever a Stacktrace was dumped.
Stack traces should be logged at ERROR level (they currently aren't).
TRACE should be defined as log level 5 in python (which is lower than DEBUG),
and LOG.trace support have already be added to Oslo.log library 1.8.
LOG.trace can then be used for deep tracing of code.
The log level is like this:
Critical > Error > Warning > Info > Debug > Trace
Link: https://github.com/openstack/openstack-specs/blob/master/specs/log-guidelines.rst