from:"Kirill Zaitsev"

Re: [openstack-dev] [kuryr][Release-job-failures] Release of openstack/kuryr-tempest-plugin failed

2017-06-20 Thread Kirill Zaitsev

Looks like kuryr-tempest-plugin doesn’t have a voting docs job for regular 
commits. I’ve added https://review.openstack.org/#/c/475901/ and 
https://review.openstack.org/#/c/475904/ to fix the issue.


Regards, Kirill

On 20 June 2017 at 21:51:49, Doug Hellmann (d...@doughellmann.com) wrote:

It looks like the kuryr-tempest-plugin repository has a documentation
job set up but no documentation.

http://logs.openstack.org/1e/1ee40b0f0ee4e92209b8ccff6d74f4980f6234ab/release/kuryr-tempest-plugin-docs-ubuntu-xenial/7f096fd/console.html#_2017-06-20_17_03_00_590629

--- Begin forwarded message from jenkins ---
From: jenkins 
To: release-job-failures 
Date: Tue, 20 Jun 2017 17:08:35 +
Subject: [Release-job-failures] Release of openstack/kuryr-tempest-plugin failed

Build failed.

- kuryr-tempest-plugin-tarball 
http://logs.openstack.org/1e/1ee40b0f0ee4e92209b8ccff6d74f4980f6234ab/release/kuryr-tempest-plugin-tarball/791b9b2/
 : SUCCESS in 3m 00s
- kuryr-tempest-plugin-tarball-signing 
http://logs.openstack.org/1e/1ee40b0f0ee4e92209b8ccff6d74f4980f6234ab/release/kuryr-tempest-plugin-tarball-signing/f74ada9/
 : SUCCESS in 42s
- kuryr-tempest-plugin-pypi-both-upload 
http://logs.openstack.org/1e/1ee40b0f0ee4e92209b8ccff6d74f4980f6234ab/release/kuryr-tempest-plugin-pypi-both-upload/43ac1e9/
 : SUCCESS in 30s
- kuryr-tempest-plugin-announce-release 
http://logs.openstack.org/1e/1ee40b0f0ee4e92209b8ccff6d74f4980f6234ab/release/kuryr-tempest-plugin-announce-release/65d7a48/
 : SUCCESS in 5m 07s
- propose-kuryr-tempest-plugin-update-constraints 
http://logs.openstack.org/1e/1ee40b0f0ee4e92209b8ccff6d74f4980f6234ab/release/propose-kuryr-tempest-plugin-update-constraints/8b85c19/
 : SUCCESS in 23s
- kuryr-tempest-plugin-docs-ubuntu-xenial 
http://logs.openstack.org/1e/1ee40b0f0ee4e92209b8ccff6d74f4980f6234ab/release/kuryr-tempest-plugin-docs-ubuntu-xenial/7f096fd/
 : FAILURE in 3m 32s

--- End forwarded message ---

__
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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Kirill Zaitsev

Not touching the separate gerrit topic, but I genuinely like the "community" 
name. In my opinion it very well covers the "projects not governed by TC" 
definition.

Regards, Kirill

> Le 15 июня 2017 г. à 18:28, Davanum Srinivas  a écrit :
> 
>> On Thu, Jun 15, 2017 at 11:17 AM, gordon chung  wrote:
>> 
>> 
>>> On 15/06/17 10:57 AM, Thierry Carrez wrote:
>>> Jeremy Stanley wrote:
> 
> I'm still unconvinced a term is needed for this. Can't we just have
> "OpenStack Projects" (those under TC governance) and "everything
> else?" Why must the existence of any term require a term for its
> opposite?
>>> Well, we tried that for 2.5 years now, and people are still confused
>>> about which projects are an Openstack project and what are not. The
>>> confusion led to the perception that everything under openstack/ is an
>>> openstack project. It led to the perception that "big tent" means
>>> "anything goes in" or "flea market".
>> 
>> regardless of terminology, i'm not entirely certain what everyone's
>> definition of an openstack project and > it> project is. additionally, what the purpose of this categorization is?
> 
> The purpose (my 2 cents) is to highlight what projects are under
> governance and those that are not.
> 
> Maybe we should call those not under governance as "community"
> projects, aggregate these under say community.openstack.org also run a
> second gerrit instance (community-git.openstack.org ?) so the
> separation is clear and distinct.
> 
> Thanks,
> Dims
> 
>> 
>> --
>> 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
> 
> 
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> 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] [murano][barbican] Encrypting sensitive properties

2017-05-31 Thread Kirill Zaitsev

As long as this integration is optional (i.e. no barbican — no encryption) It 
feels ok to me. We have a very similar integration with congress, yet you can 
deploy murano with or without it.

As for the way to convey this, I believe metadata attributes were designed to 
answer use-cases like this one. see 
https://docs.openstack.org/developer/murano/appdev-guide/murano_pl/metadata.html
 for more info.

Regards, Kirill

> Le 25 мая 2017 г. à 18:49, Paul Bourke  a écrit :
> 
> Hi all,
> 
> I've been looking at a blueprint[0] logged for Murano which involves 
> encrypting parts of the object model stored in the database that may contain 
> passwords or sensitive information.
> 
> I wanted to see if people had any thoughts or preferences on how this should 
> be done. On the face of it, it seems Barbican is a good choice for solving 
> this, and have read a lengthy discussion around this on the mailing list from 
> earlier this year[1]. Overall the benefits of Barbican seem to be that we can 
> handle the encryption and management of secrets in a common and standard way, 
> and avoid having to implement and maintain this ourselves. The main drawback 
> for Barbican seems to be that we impose another service dependency on the 
> operator, though this complaint seems to be in some way appeased by 
> Castellan, which offers alternative backends to just Barbican (though unsure 
> right now what those are?). The alternative to integrating Barbican/Castellan 
> is to use a more lightweight "roll your own" encryption such as what Glance 
> is using[2].
> 
> After we decide on how we want to implement the encryption there is also the 
> question of how best to expose this feature to users. My current thought is 
> that we can use Murano attributes, so application authors can do something 
> like this:
> 
> - name: appPassword
>  type: password
>  encrypt: true
> 
> This would of course be transparent to the end user of the application. Any 
> thoughts on both issues are very welcome, I hope to have a prototype in the 
> next few days which may help solidify this also.
> 
> Regards,
> -Paul.
> 
> [0] 
> https://blueprints.launchpad.net/murano/+spec/allow-encrypting-of-muranopl-properties
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/110192.html
> [2] 
> https://github.com/openstack/glance/blob/48ee8ef4793ed40397613193f09872f474c11abe/glance/common/crypt.py
> 
> __
> 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] [murano]An error occured when I executed environment-deploy

2017-02-28 Thread Kirill Zaitsev

Well, looks like you don’t have murano-api endpoint in keystone service
catalog. Have you tried adding it?

-- 
Kirill Zaitsev


On 28 February 2017 at 09:05:34, 渥美 慶彦 (atsumi.yoshih...@po.ntts.co.jp)
wrote:

Hi everyone,

I tried to execute "environment-deploy", but failed.
2017-02-27 15:40:21.066 13046 ERROR murano.common.engine [-]
keystoneauth1.exceptions.catalog.EndpointNotFound: Endpoint for
unknown service
(Omitted)

auth_uri is equal to that one in nova.conf.
I refered to
http://egonzalez.org/murano-in-rdo-openstack-manual-installation/
after "Import ApacheHttpServer package".
Do you have information?

My environment:
CentOS 7
OpenStack Mitaka(Packstack), including Heat
Murano[
openstack-murano-api-2.0.0-2.el7.noarch
python2-muranoclient-0.8.6-1.el7.noarch
openstack-murano-common-2.0.0-2.el7.noarch
openstack-murano-engine-2.0.0-2.el7.noarch
openstack-murano-doc-2.0.0-2.el7.noarch
](yum install)
Base Murano package:tag2.0.0

Thank you.
-- 

NTTソフトウェア株式会社
クラウド＆セキュリティ事業部 第一事業ユニット
渥美 慶彦（Atsumi Yoshihiko）
〒220-0012
横浜市西区みなとみらい4-4-5 横浜アイマークプレイス13F
TEL：045-212-7539
FAX：045-212-9800
E-mail：atsumi.yoshih...@po.ntts.co.jp



__
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] [yaql] Yaql validating performance

2017-01-17 Thread Kirill Zaitsev

I think fuel team encountered similar problems, I’d advice asking them
around. Also Stan (author of yaql) might shed some light on the problem =)

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 17 January 2017 at 15:11:52, lương hữu tuấn (tuantulu...@gmail.com)
wrote:

Hi,

We are now using yaql in mistral and what we see that the process of
validating yaql expression of input takes a lot of time, especially with
the big size input. Do you guys have any information about performance of
yaql?

Br,

@Nokia/Tuan
__
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] [murano] No meetings on 12.27 and 01.3 due to holidays

2016-12-26 Thread Kirill Zaitsev

Fellow murano developers, I suggest we skip the next two meetings due to
holidays =)


-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
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] [murano] Removing Ekaterina Chernova and Filip Blaha from cores

2016-11-22 Thread Kirill Zaitsev

Implemented

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

Le 17 novembre 2016 à 18:28:19, Kirill Zaitsev (kzait...@mirantis.com) a écrit:

I’m proposing to remove Ekaterina Chernova and Filip Blaha from the list of 
murano cores. They both have been very active in the previous cycles, but their 
focus have shifted and we haven’t seen much activity in Newton and Ocata.
If the situation would change — I would be very happy to welcome back both 
Ekaterina and Filip to murano core team. I would also like to express my thanks 
for all the hard work Ekaterina and Filip has put into murano. Hope to see you 
back in future.

You can find statistics info here 
http://stackalytics.com/?module=murano-group=all_id=filip.bl...@hpe.com
and here: 
http://stackalytics.com/?module=murano-group=all_id=efedorova 
Ekaterina is also core in murano-milestone (i.e. stable branches), so this also 
implies removing her from the group too.

If you have any thoughts or objections to this decision — please voice them.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] Nominating Felipe Monteiro for murano core

2016-11-22 Thread Kirill Zaitsev

Done.

Congratulations Felipe! =)

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

Le 17 novembre 2016 à 18:06:47, Serg Melikyan (smelik...@mirantis.com) a écrit:

+1

On Thu, Nov 17, 2016 at 5:54 AM, Alexander Tivelkov <ativel...@mirantis.com> 
wrote:
+1

On Thu, Nov 17, 2016 at 4:29 PM Kirill Zaitsev <kzait...@mirantis.com> wrote:
Hello team, I would like to nominate Felipe for murano core.
His and his teams work on increasing murano unit test coverage in Newton and 
Ocata has allowed us to reach astonishing 85%
I would like to personally thank Felipe for his dedication to making murano a 
more mature and stable project!
You can view statistics for his work here: 
http://stackalytics.com/?metric=commits=ocata=murano-group_id=felipe.monte...@att.com

Please respond with +1/-1 on the candidate =)

-- 
Kirill Zaitsev
Sent with Airmail
__
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
--
Regards,
Alexander Tivelkov

__
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




--
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979
__  
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  


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] Removing Ekaterina Chernova and Filip Blaha from cores

2016-11-17 Thread Kirill Zaitsev

I’m proposing to remove Ekaterina Chernova and Filip Blaha from the list of 
murano cores. They both have been very active in the previous cycles, but their 
focus have shifted and we haven’t seen much activity in Newton and Ocata.
If the situation would change — I would be very happy to welcome back both 
Ekaterina and Filip to murano core team. I would also like to express my thanks 
for all the hard work Ekaterina and Filip has put into murano. Hope to see you 
back in future.

You can find statistics info here 
http://stackalytics.com/?module=murano-group=all_id=filip.bl...@hpe.com
and here: 
http://stackalytics.com/?module=murano-group=all_id=efedorova 
Ekaterina is also core in murano-milestone (i.e. stable branches), so this also 
implies removing her from the group too.

If you have any thoughts or objections to this decision — please voice them.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] Nominating Felipe Monteiro for murano core

2016-11-17 Thread Kirill Zaitsev

Hello team, I would like to nominate Felipe for murano core.
His and his teams work on increasing murano unit test coverage in Newton and 
Ocata has allowed us to reach astonishing 85%
I would like to personally thank Felipe for his dedication to making murano a 
more mature and stable project!
You can view statistics for his work here: 
http://stackalytics.com/?metric=commits=ocata=murano-group_id=felipe.monte...@att.com

Please respond with +1/-1 on the candidate =)

-- 
Kirill Zaitsev
Sent with Airmail

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [Murano] No meetings on Oct 25 and Nov 1 due to summit

2016-10-19 Thread Kirill Zaitsev

Most of the team is going to attend summit, so there will be no meeting on
Oct 25
I would also suggest skipping meeting on Nov 1, since afaik a lot of folks
would still be travelling by that time (myself included). Unless someone’s
volunteering to chair and has specific agenda — let’s skip Nov 1 also.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
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] [murano] [all] Ocata Design Summit - Proposed slot allocation

2016-09-15 Thread Kirill Zaitsev

Your email says, that in Murano we have:
1 fb 3wr

This might be an error on my side, because I believe I’ve requested 1 fb 1wr in 
the questionnaire.

I’m not really sure we’ll be able to utilize that much time (In Austin our 2d 
wr was just a bit too much to be honest) I’m asking to downgrade our slots to 
1fb 1wr and suggest we spend the rest of our time on X-Project activities 
instead.

I'd also ask to not overlap Murano and Community App Catalog sessions if that 
is possible.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 13 septembre 2016 at 11:50:35, Thierry Carrez (thie...@openstack.org) wrote:

Murano: 1fb 3wr 


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano][ptl] Announcing my candidacy for PTL for Murano for the Ocala cycle

2016-09-14 Thread Kirill Zaitsev

Hello everyone, here is my announcement to run for Murano PTL for Ocata.

It has been my pleasure to serve as Murano PTL in Newton and I would like to 
offer my services to the team and the community once more. Looking back at all 
the challenges and achievements of Newton cycle I feel very proud to be part of 
Murano. We’ve made a great step forward in integrating with glare and have set 
up (now green) glare-integration jobs for nearly every murano component. Work 
on both multi-region apps and app development framework took a leap forward and 
they’re nearly finished. We’ve started work on supporting and documenting 
installation of murano from RDO and UCA. And those are just the tip of the 
iceberg.

Here are few challenges and changes I’d like to implement in Ocata

* Switch murano to ‘release-with-intermediary’ model. Probably the biggest 
change on the list. The rationale behind this change is to make releases more 
frequent and less in size to give our users access to new features faster. 
Release automation through openstack/releases repository has dramatically 
reduced the cost of making a release and would allow us to concentrate more on 
features, release often and get user feedback sooner. Secondary activity here 
would be to allow current murano support installations of a previous version of 
OpenStack. This is already the case API-wise, but might pose a certain 
challenge code-wise.

* Continue work and support of murano packages for major distributions. We have 
awesome packages for Debian (thanks zigo!), but we also need to have up-to-date 
UCA and RDO packages. This will be twice as important with the new release 
model. Furthermore we’d need to incorporate these installation guides into our 
documentation. The final goal here is to make them to be the default way to 
install murano.

* Documentation. As a continuation of #2 — there’s quite some work we need to 
do regarding our docs. App Framework, Garbage Collection, Multi-region apps, 
Installation from packages, YAQL library (even though it’s not part of murano) 
— all these features need some documentation love shead onto them. 

* Continue with the App Catalog and Glare integrations. We’ve had some progress 
in both directions, but there is still a lot to be done. Hopefuly with glare 
moving to a separate repository and AppCatalog-Glare integration underway we’ll 
be able to finally switch to v1 Glare API in Ocata

* We’re halfway there with the OSC integration and I’d really love to see it 
finished during Ocata and finally release the 1.0.0 client as soon as that is 
done. =)

Regardless of the election result — I’m looking forward to Ocata and would try 
my best to help Murano and the community around it thrive.

Cheers, Kirill (kzaitsev_ws)

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] [app-catalog] [ffe] App Catalog dashboards patches are ready

2016-09-07 Thread Kirill Zaitsev

Hi!

As the title says here are the patches that set up app-catalog-ui and 
murano-dashboard to work under common panel structure [1] Repositories would 
now share a couple of small config files to allow both dashboards be installed 
independently, if needed [2], [3]

Here is also a small script I used to fetch a clean install 
http://paste.openstack.org/show/567659/ [4] (you would obviously need to change 
your OPENSTACK_HOST ip)

I already got some positive feedback on the murano side of patches, but I am 
holding them back till I get some feedback on the app-catalog-ui side. I’d like 
to kindly ask Kevin and Chris to take a look at the patches and new structure 
and provide some feedback. We still have time before RC1 and I really hope to 
see this land in Newton =)


[1] https://review.openstack.org/#/q/topic:bp/catalog-dashboard-reorg 
[2] 
https://review.openstack.org/#/c/335725/6/app_catalog/enabled/_50_dashboard_catalog.py
[3] 
https://review.openstack.org/#/c/335725/6/app_catalog/enabled/_60_panel_group_browse.py
[4] http://paste.openstack.org/show/567659/ 

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [Murano] FFE for dependency-driven multi-step resource deallocation

2016-09-01 Thread Kirill Zaitsev

Garbage collection bp addresses a very important piece of tech debt and is 
required for app framework to work correctly. Therefore I’m granting this one.

ETA for code to be merged is next week. I've also updated topic link to 
https://review.openstack.org/#/q/topic:bp/dependency-driven-resource-deallocation,n,z
 to match the one in the blueprint.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 1 septembre 2016 at 16:13:28, Nikolay Starodubtsev 
(nstarodubt...@mirantis.com) wrote:

Hi all,
I'd like to request a feature freeze exception for dependency-driven multi-step 
resource deallocation[0].
We've merged an initial commit for it [1] and a spec[2]. That's what we have on 
review [3]. The of patches on review is about bugs related to this feature, and 
only one add some new functional [4]. ETA for the work to be done is the first 
half of next week.

Links:
[0]: 
https://blueprints.launchpad.net/murano/+spec/dependency-driven-resource-deallocation
[1]: https://review.openstack.org/351125
[2]: https://review.openstack.org/336497
[3]: https://review.openstack.org/#/q/topic:gc-collect
[4]: https://review.openstack.org/364090
                                  
Nikolay Starodubtsev
Software Engineer
Mirantis Inc.

Skype: dark_harlequine1
__  
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  


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano][app-catalog] FFE request for dashboard reorg

2016-09-01 Thread Kirill Zaitsev

I would like to request an FFE for murano/appcatalog-dashboard-reorg 
https://blueprints.launchpad.net/murano/+spec/catalog-dashboard-reorg
A little back story: we’ve agreed to start merging murano-dashboard and 
app-catalog-ui under the same structure back in Austin. For app-catalog-ui the 
process is pretty easy and straightforward, since it’s mostly a js/angular 
style plugin to horizon. But for murano-dashboard it required a bit more work 
with tests and renames. The job is finished there, i.e we have green set of 
patches for murano-dashboard 
https://review.openstack.org/#/q/topic:bp/catalog-dashboard-reorg Here is the 
link to the etherpad we used to coordinate the activities 
https://etherpad.openstack.org/p/apps-dashboard-structure 

What still needs to be done: update app-catalog-ui for the new structure (a 
pretty straightforward patch) and make sure, that both parties agree on the new 
structure of the dashboard.

Overall I see the changes as mostly safe and not bringing any new 
features/functionalities to the dashboard.

My ETA for landing the code/agreeing on the new structure is end of next week. 

Since I’m the one who should approve this FFE from murano side — I’m going to 
consider it granted for murano, unless there are some objections. Feel free to 
sound your concerns if any =)

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [heat][yaql] Deep merge map of lists?

2016-08-30 Thread Kirill Zaitsev

FYI: we’re in the process of doing almost that =) 
Here is a link for yaql doc commits 
https://review.openstack.org/#/q/status:open+project:openstack/yaql+branch:master+topic:yaqldocs

We plan to have it finished and published in time for N release and Barcelona =)

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 30 août 2016 at 23:55:18, Zane Bitter (zbit...@redhat.com) wrote:

On 30/08/16 12:18, Jiří Stránský wrote:
>
> Hmm yea that's strange, because YAQL has a test case for reduce() with 5
> items:
>
> https://github.com/openstack/yaql/blob/f71a0305089997cbfa5ff00f660920711b04f39e/yaql/tests/test_queries.py#L337-L339

If YAQL people are reading this, I suggest you should immediately  
replace your absurdly awful documentation[1] with the contents of these  
test files.

[1] http://yaql.readthedocs.io/en/latest/language_description.html

__
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


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] NoMethodRegisteredException when deploying Murano environment

2016-08-24 Thread Kirill Zaitsev

Hi, it’s impossible to say without knowing what application you’re trying to 
deploy. Also this mailing list is not the best place for usage questions =) 
Please come to our IRC channel #murano — we would try to help you find what 
went wrong.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 24 août 2016 at 05:57:32, wuhan (wuhan9...@163.com) wrote:

listNeutronExtensions

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] Separating guides from murano developers documentation

2016-08-23 Thread Kirill Zaitsev

It’s always hard to chip away from your code, even from documentation =))) But 
if that is the way most OpenStack projects do and if it would make our install 
docs more visible — I agree with the idea.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 16 août 2016 at 23:19:39, Serg Melikyan (smelik...@mirantis.com) wrote:

Hi folks,  

at this moment all murano documentation (including admin & user  
guides) is published only in one place [0], but actually all other  
projects store there only developer documentation and guides are  
separated. I propose to follow same model with murano documentation.  
What do you think?  

References:  
[0] docs.openstack.org/developer/murano/  

--  
Serg Melikyan, Development Manager at Mirantis, Inc.  
http://mirantis.com | smelik...@mirantis.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  


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano][glare] Should we make glare jobs voting

2016-08-23 Thread Kirill Zaitsev

With 3d milestone and feature freeze just behind the corner and all the talks 
about glare moving to a separate repo/project — I’m wondering if we should make 
our glare-integration jobs voting?

Our gate-tempest-dsvm-murano-glare-backend is pretty stable at this point and 
has helped us find at least 1 legitimate bug in glare integration, while our 
3d-party CI glare jobs are still not running the tests properly and require a 
bit more love before turning them on.
At the same time I’m looking forward to moving to glare api v1.0 and this would 
mean these jobs would have to be re-worked, the moment we switch.

So right now I’m slightly inclined to leave the jobs non-voting and make them 
voting as soon as we switch to glare v1. This would require some discipline 
with not merging the patches, that break glare integration, but would save us 
the hassle of turning the job up and down. But I would also like to ask for 
teams opinion on the matter.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

2016-08-09 Thread Kirill Zaitsev

 Undoubtedly, in the short term it will be painful, but I believe that in the 
long run Glare will win.

Let’s hope that projects, that use Glare would also win from this decision. =)

It seems to me, that murano is currently the only one that has been actively 
trying to incorporate glare into it’s development process. We have a 
(non-voting) integration job with glare backend. The split probably means, that 
devstack (and thus dsvm job) installations would be run via plugin from new 
repository. I would like to ask glance and glare teams to approach the process 
responsibly and not remove the code until it’s ready to be used from the new 
repo.

I’m going to echo Tim’s concerns and suggest that glare team put packaging and 
ease of use/deployment high on the list of new projects priorities.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 5 août 2016 at 21:11:12, Mikhail Fedosin (mfedo...@mirantis.com) wrote:

Thank you all for your responses!

From my side I can add that our separation is a deliberate step. We pre-weighed 
all pros and cons and our final decision was that moving forward as a new 
project is the lesser of two evils.

Also, I want to say, that Glare was designed as an open project and we want to 
build a good community with members from different companies. Glare suppose to 
be a backend for Heat (and therefore TripleO), App-Catalog, Tacker and 
definitely Nova. In addition we are considering the possibility of storage 
Docker containers, which may be useful for Magnum.

Then, I think that comparison between Image API and Artifact API is not 
correct. Moreover, in my opinion Image API imposes artificial constraints. Just 
imagine that your file system can only store images in JPG format (more 
precisely, it could store any data, but it is imperative that all files must 
have the extension ".jpg"). Likewise Glance - I can put there any data, it can 
be both packages and templates, as well as video from my holiday. And this 
interface, though not ideal, may not work for all services. But those 
artificial limitations that have been created, do Glance uncomfortable even for 
storing images.

On the other hand Glare provides unified interface for all possible binary data 
types. If we take the example with filesystem, in Glare's case it supports all 
file extensions, folders, history of file changes on your disk, data validation 
and conversion, import/export files from different computers and so on. These 
features are not presented in Glance and I think they never will, because of 
deficiencies in the architecture. 

For this reason I think Glare's adoption is important and it will be a huge 
step forward for OpenStack and the whole community.

Thanks again! If you want to support us, please vote for our talk on Barcelona 
summit - https://www.openstack.org/summit/barcelona-2016/vote-for-speakers/ 
Search "Glare" and there will be our presentation.

Best,
Mike 

On Fri, Aug 5, 2016 at 5:22 PM, Jonathan D. Proulx <j...@csail.mit.edu> wrote:

I don't have a strong opinion on the split vs stay discussion. It
does seem there's been sustained if ineffective attempts to keep this
together so I lean toward supporting the divorce.

But let's not pretend there are no costs for this.

On Thu, Aug 04, 2016 at 07:02:48PM -0400, Jay Pipes wrote:
:On 08/04/2016 06:40 PM, Clint Byrum wrote:

:>But, if I look at this from a user perspective, if I do want to use
:>anything other than images as cloud artifacts, the story is pretty
:>confusing.
:
:Actually, I beg to differ. A unified OpenStack Artifacts API,
:long-term, will be more user-friendly and less confusing since a
:single API can be used for various kinds of similar artifacts --
:images, Heat templates, Tosca flows, Murano app manifests, maybe
:Solum things, maybe eventually Nova flavor-like things, etc.

The confusion is the current state of two API's, not having a future
integrated API.

Remember how well that served us with nova-network and neutron (né
quantum).

I also agree with Tim's point.  Yes if a new project is fully
documented and integrated well into packaging and config management
implementing it is trivial, but history again teaches this is a long
road.

It also means extra dev overhead to create and mange these
supporting structures to hide the complexity from end users. Now if
the two project are sufficiently different this may not be a
significant delta as the new docs and config management code would be
need in the old project if the new service stayed stayed there.

-Jon

__
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

Re: [openstack-dev] [heat] [yaql] Evaluate YAQL expressions in the yaqluator

2016-08-05 Thread Kirill Zaitsev

Hi and thanks for your continued support for yaql =) 

Please take note, that we’re currently have a big effort in updating and 
writing yaql documentation (I hope we’ll get it done and ready for barcelona). 
Feel free to propose a short article to official yaql docs about yaqluator ;)

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 29 juillet 2016 at 09:08:41, Elisha, Moshe (Nokia - IL) 
(moshe.eli...@nokia.com) wrote:

Hi,

I saw that starting the Newton release - Heat supports yaql function[1].
I think this will prove to be very powerful and very handy.

I wanted to make sure you are familiar with the yaqluator[2] as it might be 
useful for you.

yaqluator – is a free online YAQL evaluator.
* Enter a YAML / JSON and a YAQL expression and evaluate to see the result.
* There is a catalog of commonly used OpenStack API responses to run YAQL 
expressions against.
* It is open-source[3] and any contribution is welcome.

I hope you will find it useful.


[1] http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#yaql
[2] http://yaqluator.com
[3] https://github.com/ALU-CloudBand/yaqluator

__  
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  


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] PTL on vacation

2016-07-22 Thread Kirill Zaitsev

Hi team, I’d like to inform you, that I would be on vacation during next week 
and a half and would like to appoint some of my deputies =)


During this cycle I’m acting as a release liaison, so in my absence I would 
like Victor Ryzhenkin (freerunner) to act as one and be responsible for 
supervising our releases, if any.

As for IRC community meetings — I’m leaving Nikolay Starodubtsev (Nikolay_St) 
and Valerii Kovalchuk (vakovalchuk) to chair the next two meetings. I also 
suggest to skip the next meeting, unless some agenda items are added. Guys, 
please don’t forget to send a message next week, if you decide to follow this 
suggestion.


As for myself — I’ll be obviously less active, but I should have some internet 
access and would still check email and answer questions on reviews, just at a 
slower rate. =)

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [horizon] Plugin stability, failing tests etc.

2016-07-20 Thread Kirill Zaitsev

Initially I don’t think I like the idea of making master-horizon job non-voting 
for murano-dashboard.

Here are some reasons: 
1) We would still need to fix murano-dashboard to work with master 
horizon (since we would need to be released together)
2) The breakage would be less visible
3) I can imagine a situation when a change would pass on master but 
would not pass on a previous stable point release (even worse this release can 
be n3). Say we’re trying to use some function/feature, that has just landed.

Those are my initial ideas about this, have give it a bit more time, to think 
more carefully.

BTW, I can fetch the numbers on how many times murano-dashboard gate was broken 
by changes in horizon, during M and N cycles, if you’re interested. Also for 
murano-dashboard we run our integration selenium tests as a 3d-party CI, so 
technically we’re not blocked by the job not working, in case we need to land 
some security patch. =)

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 20 juillet 2016 at 17:10:46, Rob Cresswell (robert.cressw...@outlook.com) 
wrote:

Yes, it would mean changing your requirements after a release. So, for example 
you might run two gate tests:

- A voting Horizon-stable/milestone test, (or both)
- A non-voting Horizon-master test

That gives you a lot of control over making your tests passing (multiple 
patches to make the Horizon-master test pass, or all in one patch set alongside 
the horizon-milestone test bump), rather than random failures each week. You'd 
still be able to track the failures as they come in, but they won't break your 
gate each time.

I don't think where horizon (the library) lives would change how you version 
against it. We don't currently have any plans to separate the two; while we 
realise its a desirable change, weighing the work and risk involved in the 
split architecture vs the end result, we've chosen to work on other higher 
priority items for now (performance, filtering improvements, angular work etc.)

Rob

On 20 July 2016 at 13:38, Hayes, Graham <graham.ha...@hpe.com> wrote:
On 20/07/2016 10:16, Rob Cresswell wrote:
> Hey all,
>
> So we've had a few issues with plugin stability recently, and its
> apparent that many plugins are building off Horizon master as a
> dependency. I would really advise against this. A more manageable
> development process may be to:
>
> - Base stable plugins against a stable release of Horizon
> - Base WIP versions/new plugins off the last Horizon milestone, b2 in
> this case, and then bump the version and capture issues within the same
> patch. This should prevent random breakages, and should allow you to
> just look at the release notes for that milestone.

So this would mean changing tox.ini or requirements files after each
horizon release?

This dovetails nicely with the other thread about how we should be doing
cross project interactions.

What would be best, would be having horizon released as a separate
library on pypi like the clients and oslo libs.

Then openstack-dashboard, and all the plugins could rely on the same
base library, without hacks like:

   deps =
     -r{toxinidir}/requirements.txt
     -r{toxinidir}/test-requirements.txt
     http://tarballs.openstack.org/horizon/horizon-master.tar.gz

in tox.ini or

   # Testing Requirements
   http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon

in (test-)requirements.txt

Is that on roadmap?

> On the Horizon side, we've moved our FF a week earlier, so I think that
> week combined with the usual RC period should be enough time to fix
> bugs. We'll aim to make sure our release notes are complete with regards
> to breaking issues for plugins, and deprecate appropriately.
>
> Rob

__
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  

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] Mascot for murano

2016-07-18 Thread Kirill Zaitsev

Let’s hop on the mascot craze train and choose one for murano, shall we? For 
those out of loop, please see http://www.openstack.org/project-mascots =)

Feel free to add suggestions, leave +1/-1 votes here 
https://etherpad.openstack.org/p/murano-mascot 


-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [release][documentation][telemetry][murano][trove] missing milestones

2016-07-15 Thread Kirill Zaitsev

We’re in the process of tearing down murano apps into separate production grade 
apps and murano-examples, that are only good as, well examples. So we do not 
intend to include murano-apps as a deliverable in this cycle. (Would probably 
need to update the release model for it as soon as possible next cycle)

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 15 juillet 2016 at 16:38:06, Doug Hellmann (d...@doughellmann.com) wrote:

We have a few deliverables without any milestone tags for this  
release cycle, yet (see the list below). They are at risk of being  
excluded from the final release for failing to prepare releases  
under the cycle-with-milestone release model.  

Please propose 0b2 tags by the end of the day, or let us know  
officially that you do not intend to include these deliverables  
this cycle.  

Thanks,  
Doug  

training-labs (Documentation)  
aodh (Telemetry)  
ceilometer (Telemetry)  
murano-apps (murano)  
trove-image-builder (trove)  

__  
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  


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [app-catalog][murano] Dashboards

2016-07-06 Thread Kirill Zaitsev

Back in Austin we’ve agreed to start bringing murano-dashboard and 
app-catalog-ui horizon dashboards closer to each other. See the etherpad [1] 
for more context and to refresh what we’ve been talking about. Since 
murano-dashboard is mostly a python project and app-catalog-ui is mostly a 
javascript/angular project moving them now to a single code base doesn’t make 
much sense to me =) However we can start working towards moving under a common 
namespace/dashboard in horizon.

In Austin we agreed to see if that is possible/feasible to do. I’ve uploaded 
two patches for review [2] that do exactly that. Both of them are currently 
WIP, but despite that they show that we can fit our panels under one 
horizon-dashboard (I took the liberty of naming it «Applications"). There is 
also a short gif, that shows my dev horizon environment [3].

We haven’t decided the exact layout in Austin, so I would like to kickstart 
that discussion. I’ve drafted a small etherpad[4], that I suggest we could use 
to share ideas.

Would really appreciate if you guys would find a couple of minutes of your time 
to think about the layout for our dashboards and put those thoughts in the 
etherpad.

P.S. The other part where we agreed to collaborate on naming was the OSC 
command namespaces. I do remember talking about the names, but can’t remember 
if we have agreed on anything specific. So this might be a good opportunity to 
also figure this question out.

[1] https://etherpad.openstack.org/p/AUS-app-catalog 
[2] https://review.openstack.org/#/q/topic:applications-dashboard  
[3] https://www.dropbox.com/s/26sfxpoc9hd8gi7/shared_dashboard.gif?dl=0  
[4] https://etherpad.openstack.org/p/apps-dashboard-structure 

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] Fail to install murano in Pro environment / Ansible cookbook for murano

2016-07-04 Thread Kirill Zaitsev

Hi Alioune!

Can you please share which versions of murano and existing cloud do you have? 

I would bet that you’re using stable/liberty murano, or earlier. The code you 
mentioned has been refactored in stable/mitaka [1] This was done, because 
oslo.messaging has merged a commit [2], that changed a couple of interfaces 
murano used. This commit AFAIK triggered a major version release of 
oslo.messaging (5.0.0). At least according to gerrit 5.0.0 is the 1st release 
it is included in.
Then again in stable/liberty the upper constraint for oslo.messaging was 2.5.0 
[3]. However it is not capped in requirements. [4]

So the problem here (and that’s my educated guess =)) is that tox is installing 
way too recent version of oslo.messaging library for murano to use on 
stable/liberty. A quick solution for your case would be to downgrade your 
oslo.messaging to 2.5.0

A longer and better solution would be to teach our tox to honor 
upper-constraints for stable branches, I guess, since they’re not always 
backward compatible as we may see.
Hope this helps!

Also, please note, that this ML is not for usage questions — the question is 
more suited for openst...@lists.openstack.org 
Or you can come to #murano in IRC =) We try to keep it alive and you’ll be able 
to get answers quicker.

[1] 
https://review.openstack.org/#/q/Ied7acaeed6edde17d2d6f073c304021e22811409,n,z 
[2] https://review.openstack.org/#/c/297988/ 
[3] 
https://github.com/openstack/requirements/blob/stable/liberty/upper-constraints.txt#L196
[4] 
https://github.com/openstack/requirements/blob/stable/liberty/global-requirements.txt#L90
 
-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 4 juillet 2016 at 17:34:40, Alioune (baliou...@gmail.com) wrote:

Hi all,

I'm trying to install murano in existing openstack platform following [1].
So the installation process fails at step [2] with this error.
Any suggestion for solving that ?
Is there existing murano playbook for easy deployment with ansible ?


You can find my murano.conf in [3]

[1] http://docs.openstack.org/developer/murano/install/manual.html

[2] sudo  tox -e venv -- murano-api --config-file ./etc/murano/murano.conf

[3] 
https://drive.google.com/file/d/0B-bfET74f0WZd2N6WGR0Szh1UUE/view?usp=sharing


ERROR:
2016-07-04 14:06:59.960 9251 WARNING keystonemiddleware.auth_token [-] Use of 
the auth_admin_prefix, auth_host, auth_port, auth_protocol, identity_uri, 
admin_token, admin_user, admin_password, and admin_tenant_name configuration 
options was deprecated in the Mitaka release in favor of an auth_plugin and its 
related options. This class may be removed in a future release.
2016-07-04 14:06:59.960 9251 WARNING keystonemiddleware.auth_token [-] 
Configuring admin URI using auth fragments was deprecated in the Kilo release, 
and will be removed in the N release, use 'identity_uri\ instead.
2016-07-04 14:07:00.252 9251 CRITICAL murano [-] TypeError: __init__() takes 
exactly 3 arguments (5 given)
2016-07-04 14:07:00.252 9251 ERROR murano Traceback (most recent call last):
2016-07-04 14:07:00.252 9251 ERROR murano   File ".tox/venv/bin/murano-api", 
line 10, in 
2016-07-04 14:07:00.252 9251 ERROR murano sys.exit(main())
2016-07-04 14:07:00.252 9251 ERROR murano   File 
"/home/vagrant/murano/murano/cmd/api.py", line 66, in main
2016-07-04 14:07:00.252 9251 ERROR murano 
launcher.launch_service(server.get_notification_service())
2016-07-04 14:07:00.252 9251 ERROR murano   File 
"/home/vagrant/murano/murano/common/server.py", line 235, in 
get_notification_service
2016-07-04 14:07:00.252 9251 ERROR murano NOTIFICATION_SERVICE = 
_prepare_notification_service(str(uuid.uuid4()))
2016-07-04 14:07:00.252 9251 ERROR murano   File 
"/home/vagrant/murano/murano/common/server.py", line 219, in 
_prepare_notification_service
2016-07-04 14:07:00.252 9251 ERROR murano [s_target], endpoints, None, True)
2016-07-04 14:07:00.252 9251 ERROR murano TypeError: __init__() takes exactly 3 
arguments (5 given)
2016-07-04 14:07:00.252 9251 ERROR murano
ERROR: InvocationError: '/home/vagrant/murano/.tox/venv/bin/murano-api 
--config-file etc/murano/murano.conf'
_ summary 
_
ERROR:   venv: commands failed
__  
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  


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano][release] Changing murano-agent release model to cycle-with-intermediary

2016-06-27 Thread Kirill Zaitsev

Hello team,

Currently murano-agent has 'cycle-with-milestones' release model, i.e. the same 
as murano and murano-dashboard. 
At the same time the project does not really receive a lot of updates to 
justify such model. In fact it is developed a lot like our python-muranoclient 
is and we intend it to be backward compatible.
I’ve pushed a change for review [1], but would like to get some opinions before 
giving it a go

P.S. going to add this to agenda for our next community meeting, but feel free 
to comment here or in the review.


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


-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano][murano-apps] FQNs of murano apps/classes

2016-06-27 Thread Kirill Zaitsev

TL,DR version: 
Murano team is using io.murano namespace for murano Core Library, it should not 
be used for apps; We’ve updated our murano apps to use org.openstack and/or 
com.mirantis where applicable [1]. If you’re developing a murano app — please 
pick a relevant namespace.

Long Version:
In MuranoPL packages and classes have FQNs, Fully Qualified Names. This is done 
to allow developers of apps distinguish between different implementations of 
the same thing. For example we might have a VM-based MySQL [2] and a 
docker-based MySQL classes [3]. The idea of FQNs is quite similar to the idea 
of namespaces from Java, for example.

Until very recently we(murano-team) have been using ‘io.murano’ prefix for all 
of our apps. Originally this namespace was designed to contain only ‘core’ 
murano classes, but then we’ve added a couple of apps, and a couple more and 
eventually we’ve been using the namespace all over. This lead to app developers 
from outside the core murano team to copy this practice and use ‘io.murano’ 
prefix in their own apps (Since all the apps start with ‘io.murano’ one would 
make a logical solution, that he should also start his/her app with 
‘io.murano’). This defeats the idea of having multiple independent 
implementations with different FQN, so we’re updating our apps to remove this 
prefix. It will probably take some time to update apps on app.openstack.org, 
but apps in murano-apps have already been updated accordingly.

The same idea applies to murano plugins, that extend core library with new 
functionality. This work is described in corresponding spec [4] (it’s quite 
short, so if you’re writing a murano-plugin, please give it a read) and will be 
implemented by this commit [5]. The goal here is also to remove 
‘io.murano.extensions’ from the class names of the plugins. Old names are 
deprecated, but would be supported.

So, if you’re developing a murano app, please don’t use 'io.murano' as the 
prefix for your app’s FQN, but rather choose a more appropriate one. 
'org.openstack' might be a good choice. And if your company plans to invest 
into supporting the app — it might be a good idea to put it’s name there.


[1] 
https://review.openstack.org/#/q/status:merged+project:openstack/murano-apps+branch:master+topic:bp/fix-fqn-usage
 
[2] 
https://git.openstack.org/cgit/openstack/murano-apps/tree/MySQL/package/manifest.yaml#n15
[3] 
https://git.openstack.org/cgit/openstack/murano-apps/tree/Docker/Applications/MySQL/package/manifest.yaml#n15
[4] 
https://specs.openstack.org/openstack/murano-specs/specs/newton/approved/plugin-fqn-rename.html
[5] https://review.openstack.org/#/c/332875/

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [Fuel] Merge IRC channels

2016-06-26 Thread Kirill Zaitsev

Just wanting to share an opinion:

We in murano had similar discussion about a year ago, and ultimately decided 
that it’s not worth the work to rename #murano into #openstack-murano, support 
the deprectated channel, edit documents, and move people around. After all 
there is #heat #tacker and #tripleo See for yourself: 
https://wiki.openstack.org/wiki/IRC

BTW looks like none of the #fuel-X channels is on the list. Since you’re making 
the changes it might be a good idea to update the wiki =) 

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 25 June 2016 at 12:40:17, Roman Prykhodchenko (m...@romcheg.me) wrote:

Since Fuel is a part of OpenStack now, should we rename #fuel to 
#openstack-fuel?

- romcheg
24 черв. 2016 р. о 18:49 Andrew Woodward <xar...@gmail.com> написав(ла):

There is also #fuel-devops

I never liked having all the channels, so +1

On Fri, Jun 24, 2016 at 4:25 AM Anastasia Urlapova <aurlap...@mirantis.com> 
wrote:
Vova,
please don't forget merge #fuel-qa into a #fuel 

On Fri, Jun 24, 2016 at 1:55 PM, Vladimir Kozhukalov <vkozhuka...@mirantis.com> 
wrote:
Nice. #fuel-infra is to merged as well.

Vladimir Kozhukalov

On Fri, Jun 24, 2016 at 1:50 PM, Aleksandra Fedorova <afedor...@mirantis.com> 
wrote:
And +1 for #fuel-infra

As of now it will be more useful if infra issues related to project will be 
visible for project developers. We don't have much infra-related traffic on IRC 
for now, and we will be able to split again if we got it.

On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov <vkozhuka...@mirantis.com> 
wrote:
Dear colleagues,

We have a few IRC channels but the level of activity there is quite low.

#fuel
#fuel-dev
#fuel-python
#fuel-infra

My suggestion is to merge all these channels into a single IRC channel #fuel.
Other #fuel-* channels are to be deprecated.

What do you think of this?


Vladimir Kozhukalov

__
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




--
Aleksandra Fedorova
Fuel CI Engineer
bookwar

__
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
--
--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community

__
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  


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] [murano-apps] Murano apps core changes

2016-06-17 Thread Kirill Zaitsev

Done, 

Sergey, feel free to add whoever you consider necessary in the group.

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 14 June 2016 at 14:21:18, Kirill Zaitsev (kzait...@mirantis.com) wrote:

Last week a patch [1] has been landed, that added murano-apps-core group, 
responsible for murano-apps repositories. Right now this group only includes 
murano-core. As a continuation of transition of responsibilities for 
murano-apps (started here [2]) I’m going to add Sergey Kraynev, who is leading 
the murano-apps separation initiative and allow him to nominate/add members to 
the team.

There is also one person, whom I would like to nominate for murano-apps-core 
myself — Dmytro Dovbii. Of all the murano team he has one of the greatest 
expertise with murano apps, and his contribution to their development and 
support is hard to underestimate [3]. I believe, that Dmytro would make a good 
foundation for the murano-apps-core team.

If there are no objections to these steps — I’m going to implement them by the 
end of this week.

[1] https://review.openstack.org/#/c/323340/ 
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-May/096268.html 
[3] http://stackalytics.com/?release=all=commits=murano-apps 

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

2016-06-17 Thread Kirill Zaitsev

Thanks everyone. Changes have been implemented.

--
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 17 June 2016 at 10:13:22, Omar Shykhkerimov (oshykhkeri...@mirantis.com)
wrote:

+1, agree with this proposition

On Thu, Jun 16, 2016 at 3:08 PM, Victor Ryzhenkin <vryzhen...@mirantis.com>
wrote:
It’s great to see this happen!
+1 for adding both! Well deserved, folks!

Also agreed to remove Steve from murano-core.

--
Victor Ryzhenkin
Quality Assurance Engineer
freerunner on #freenode

От 16 июня 2016 г. в 14:51:23, Tetiana Lashchova (tlashch...@mirantis.com)
написал:

+1 for both

On Thu, Jun 16, 2016 at 11:26 AM, Nikolay Starodubtsev
<nstarodubt...@mirantis.com> wrote:
+1
Well deserved!
Nikolay Starodubtsev
Software Engineer
Mirantis Inc.

Skype: dark_harlequine1

2016-06-15 19:42 GMT+03:00 Serg Melikyan <smelik...@mirantis.com>:
+1

Finally!

On Wed, Jun 15, 2016 at 3:33 AM, Ihor Dvoretskyi <idvorets...@mirantis.com>
wrote:
+1 for Alexander Tivelkov.

Good effort.

On Wed, Jun 15, 2016 at 1:08 PM, Artem Silenkov <asilen...@mirantis.com> wrote:
Hello!

Regards,
Artem Silenkov
---
paas-team

On Wed, Jun 15, 2016 at 12:56 PM, Dmytro Dovbii <ddov...@mirantis.com> wrote:
+1

15 июня 2016 г. 6:47 пользователь "Yang, Lin A" <lin.a.y...@intel.com> написал:

+1 both for Alexander Tivelkov and Zhu Rong. Well deserved.

Regards,
Lin Yang

On Jun 15, 2016, at 3:17 AM, Kirill Zaitsev <kzait...@mirantis.com> wrote:

Hello team, I want to annonce the following changes to murano core team:

1) I’d like to nominate Alexander Tivelkov for murano core. He has been part of
the project for a very long time and has contributed to almost every part of
murano. He has been fully committed to murano during mitaka cycle and continues
doing so during newton [1]. His work on the scalable framework architecture is
one of the most notable features scheduled for N release.

2) I’d like to nominate Zhu Rong for murano core. Last time he was nominated I
-1’ed the proposal, because I believed he needed to start making more
substantial contributions. I’m sure that Zhu Rong showed his commitment [2] to
murano project and I’m happy to nominate him myself. His work on the separating
cfapi from murano api and contributions headed at addressing murano’s technical
debt are much appreciated.

3) Finally I would like to remove Steve McLellan[3] from murano core team.
Steve has been part of murano from very early stages of it. However his focus
has since shifted and he hasn’t been active in murano during last couple of
cycles. I want to thank Steve for his contributions and express hope to see him
back in the project in future.

Murano team, please respond with +1/-1 to the proposed changes.

[1] http://stackalytics.com/?user_id=ativelkov=marks
[2] http://stackalytics.com/?metric=marks_id=zhu-rong
[3] http://stackalytics.com/?user_id=sjmc7
--
Kirill Zaitsev
Software Engineer
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

--
Best regards,

Ihor Dvoretskyi

--
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979

__
OpenStack Development Mailing List (not for usage questio

[openstack-dev] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

2016-06-14 Thread Kirill Zaitsev

Hello team, I want to annonce the following changes to murano core team:

1) I’d like to nominate Alexander Tivelkov for murano core. He has been part of 
the project for a very long time and has contributed to almost every part of 
murano. He has been fully committed to murano during mitaka cycle and continues 
doing so during newton [1]. His work on the scalable framework architecture is 
one of the most notable features scheduled for N release.

2) I’d like to nominate Zhu Rong for murano core. Last time he was nominated I 
-1’ed the proposal, because I believed he needed to start making more 
substantial contributions. I’m sure that Zhu Rong showed his commitment [2] to 
murano project and I’m happy to nominate him myself. His work on the separating 
cfapi from murano api and contributions headed at addressing murano’s technical 
debt are much appreciated.

3) Finally I would like to remove Steve McLellan[3] from murano core team. 
Steve has been part of murano from very early stages of it. However his focus 
has since shifted and he hasn’t been active in murano during last couple of 
cycles. I want to thank Steve for his contributions and express hope to see him 
back in the project in future.


Murano team, please respond with +1/-1 to the proposed changes.

[1] http://stackalytics.com/?user_id=ativelkov=marks
[2] http://stackalytics.com/?metric=marks_id=zhu-rong
[3] http://stackalytics.com/?user_id=sjmc7
-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [murano] [murano-apps] Murano apps core changes

2016-06-14 Thread Kirill Zaitsev

Last week a patch [1] has been landed, that added murano-apps-core group, 
responsible for murano-apps repositories. Right now this group only includes 
murano-core. As a continuation of transition of responsibilities for 
murano-apps (started here [2]) I’m going to add Sergey Kraynev, who is leading 
the murano-apps separation initiative and allow him to nominate/add members to 
the team.

There is also one person, whom I would like to nominate for murano-apps-core 
myself — Dmytro Dovbii. Of all the murano team he has one of the greatest 
expertise with murano apps, and his contribution to their development and 
support is hard to underestimate [3]. I believe, that Dmytro would make a good 
foundation for the murano-apps-core team.

If there are no objections to these steps — I’m going to implement them by the 
end of this week.

[1] https://review.openstack.org/#/c/323340/ 
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-May/096268.html 
[3] http://stackalytics.com/?release=all=commits=murano-apps 

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] [stable][all] Tagging kilo-eol for "the world"

2016-06-06 Thread Kirill Zaitsev

I’ve submitted a request to release all the unreleased code we still have
for murano repositories https://review.openstack.org/#/c/325359/ ; It would
be really great if we could get one final release before EOL’ing kilo in
murano, murano-dashboard, murano-agent and python-muranoclient, if that is
possible. After that I believe kilo branches in those repos are ready to be
EOL’ed and deleted.

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 3 June 2016 at 09:26:58, Tony Breeds (t...@bakeyournoodle.com) wrote:

On Thu, Jun 02, 2016 at 08:31:43PM +1000, Tony Breeds wrote:
> Hi all,
> In early May we tagged/EOL'd several (13) projects. We'd like to do a
> final round for a more complete set. We looked for projects meet one or
more
> of the following criteria:
> - The project is openstack-dev/devstack, openstack-dev/grenade or
> openstack/requirements
> - The project has the 'check-requirements' job listed as a template in
> project-config:zuul/layout.yaml
> - The project is listed in governance:reference/projects.yaml and is
tagged
> with 'release:managed' or 'stable:follows-policy' (or both).

So We've had a few people opt into EOL'ing which is great.

I've Moved the lists from paste.o.o to a gist. The reason for that is I can
update them, the URL doesn't change and there is a revision history (or
sorts).

The 2 lists are now at:
https://gist.github.com/tbreeds/7de812a5d363fab4bd425beae5084c87

Given that there are now only 39 repos that are not (yet) EOL'ing I'm
inclined
to default to EOL'ing everything that that isn't a deployment project.

That is to say I'm suggesting that:
openstack/cloudkitty cloudkitty 1
openstack/cloudkitty-dashboard cloudkitty 1
openstack/cloudpulse BigTent
openstack/compute-hyperv BigTent
openstack/fuel-plugin-purestorage-cinder BigTent
openstack/group-based-policy BigTent 4
openstack/group-based-policy-automation BigTent
openstack/group-based-policy-ui BigTent
openstack/murano-apps murano 3
openstack/nova-solver-scheduler BigTent
openstack/openstack-resource-agents BigTent
openstack/oslo-incubator oslo
openstack/powervc-driver BigTent 1
openstack/python-cloudkittyclient cloudkitty 1
openstack/python-cloudpulseclient BigTent
openstack/python-group-based-policy-client BigTent
openstack/swiftonfile BigTent
openstack/training-labs Documentation
openstack/yaql BigTent 2

Get added to the EOL list.

With the following hanging back for a while as they might need small tweaks
based on the kilo-eol tag.

openstack/cookbook-openstack-bare-metal Chef OpenStack
openstack/cookbook-openstack-block-storage Chef OpenStack
openstack/cookbook-openstack-client Chef OpenStack
openstack/cookbook-openstack-common Chef OpenStack
openstack/cookbook-openstack-compute Chef OpenStack
openstack/cookbook-openstack-dashboard Chef OpenStack
openstack/cookbook-openstack-data-processing Chef OpenStack
openstack/cookbook-openstack-database Chef OpenStack
openstack/cookbook-openstack-identity Chef OpenStack
openstack/cookbook-openstack-image Chef OpenStack
openstack/cookbook-openstack-integration-test Chef OpenStack
openstack/cookbook-openstack-network Chef OpenStack
openstack/cookbook-openstack-object-storage Chef OpenStack
openstack/cookbook-openstack-ops-database Chef OpenStack
openstack/cookbook-openstack-ops-messaging Chef OpenStack
openstack/cookbook-openstack-orchestration Chef OpenStack
openstack/cookbook-openstack-telemetry Chef OpenStack
openstack/openstack-ansible OpenStackAnsible
openstack/openstack-chef-repo Chef OpenStack
openstack/packstack BigTent

Yours Tony.
__
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] [stable][all][murano] Tagging kilo-eol for "the world"

2016-06-03 Thread Kirill Zaitsev

I’d like to ask to keep murano-apps kilo branch alive. It’s indeed not a
deployable project, but a collection of reference apps for murano. While no
active development happens for murano on kilo itself anymore, the apps repo
is intended to provide reference application for kilo users.

Is it possible for us to keep that branch alive?

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 3 June 2016 at 09:26:58, Tony Breeds (t...@bakeyournoodle.com) wrote:

to default to EOL'ing everything that that isn't a deployment project.
__
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] [murano] No weekly meetings on April 26th and May 3d

2016-04-22 Thread Kirill Zaitsev

Due to summit, long flights and holidays, that happen in Russia and Ukraine 
early in May there would be no weekly meetings on 26th and 3d.

-- 
Kirill Zaitsev
Software Engineer
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] [murano] Fw:Extending API via Plugins

2016-03-31 Thread Kirill Zaitsev

I’d like to add my 2 cents for this:

It’s really hard to read through the changes on pastes. May I ask you to submit 
it on gerrit for review as a WIP patch? This would allow us to give you proper 
feedback.
I +1 Serg’s idea to add a formal spec for this change. May I ask you to submit 
one to murano-specs repo?

If you have any questions on the process of implementing these — feel free to 
come to #murano on IRC or to one of our weekly meetings 
https://wiki.openstack.org/wiki/Meetings/MuranoAgenda (feel free to add your 
ideas to agenda items).

I’m including [murano] in the title to get correct folks’s attention =)

-- 
Kirill Zaitsev
Mirantis, Inc

On 30 March 2016 at 20:33:54, Serg Melikyan (smelik...@mirantis.com) wrote:

Hi wangzhh,

I think this look reasonable, but I would prefer to have a proper spec for this 
feature. I generally like to have extendable API in Murano.

On Thu, Mar 24, 2016 at 8:49 PM, 王正浩 <wang...@awcloud.com> wrote:
I'm sorry that I forgot to tell you murano-paste.ini should be modified to
...
[app:apiv1app]
paste.app_factory = murano.api.v1.router:APIRouterV1.factory
...
And the file [4] is murano/api/v1/extensions_base.py 
 
-- Original --
From:  "王正浩"<wang...@awcloud.com>;
Date:  Fri, Mar 25, 2016 11:10 AM
To:  "List"<OpenStack-dev@lists.openstack.org>;
Cc:  "smelikyan"<smelik...@mirantis.com>;
Subject:  Extending API via Plugins
 
Hi Serg Melikyan,
I don't know much about CF Broker API. I'm sorry that I
have no real use-case. But here is a test one which I plan to
complete.

I modified murano/common/wsgi.py[0], murano/api/v1/router.py[1],
added
...
murano.api.v1.extensions =
    test = murano.api.v1.extensions.test:testAPI
...
to the setup.cfg[2]. Imply the class testAPI[3].
The class testAPI  inherit a base class APIExtensionBase[4].
I'll show you my code.
P.S. I copied it from nova. So there are some extra code, hope you don't mind.
[0] http://paste.openstack.org/show/491841/
[1] http://paste.openstack.org/show/491840/
[2] http://paste.openstack.org/show/491842/
[3] http://paste.openstack.org/show/491845/
[4] http://paste.openstack.org/show/491843/



--
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979
__  
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] [release][all][ptl] release process changes for official projects

2016-03-29 Thread Kirill Zaitsev

My immediate question is — when would this be merged? Is it a good idea to 
alter this during the final RC week and before mitaka release, rather than 
implement this change early in the Newton cycle and let people release their 
final release the old way?

-- 
Kirill Zaitsev
Murano Team
Software Engineer
Mirantis, Inc

On 29 March 2016 at 19:46:08, Doug Hellmann (d...@doughellmann.com) wrote:

During the Mitaka cycle, the release team worked on automation for  
tagging and documenting releases [1]. For the first phase, we focused  
on official teams with the release:managed tag for their deliverables,  
to keep the number of projects manageable as we built out the tools  
and processes we needed. That created a bit of confusion as official  
projects still had to submit openstack/releases changes in order  
to appear on the releases.openstack.org website.  

For the second phase during the Newton cycle, we are prepared to  
expand the use of automation to all deliverables for all official  
projects. As part of this shift, we will be updating the Gerrit  
ACLs for projects to ensure that the release team can handle the  
releases and branching. These updates will remove tagging and  
branching rights for anyone not on the central release management  
team. Instead of tagging releases and then recording them in the  
releases repository after the tag is applied, all official teams  
can now use the releases repo to request new releases. We will be  
reviewing version numbers in all tag requests to ensure SemVer is  
followed, and we won't release libraries late in the week, but we  
will process releases regularly so there is no reason this change  
should have a significant impact on your ability to release frequently.  

If you're not familiar with the current release process, please  
review the README.rst file in the openstack/releases repository.  
Follow up here on the mailing list or in #openstack-release if you  
have questions.  

The project-config change to update ACLs and correct issues with  
the build job definitions for official projects is  
https://review.openstack.org/298866  

Doug  

[1] 
http://specs.openstack.org/openstack-infra/infra-specs/specs/centralize-release-tagging.html
  

__  
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] Newton Design Summit - Proposed slot allocation

2016-03-19 Thread Kirill Zaitsev

Is it too late to ask for a half-day Contributors Meetup for murano?

We had an extremely successful contributors meetup in Tokyo and I guess it is 
an error on our side, that we have not requested one for in Austin.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 16 March 2016 at 12:57:30, Thierry Carrez (thie...@openstack.org) wrote:

Hi PTLs,  

Here is the proposed slot allocation for project teams at the Newton  
Design Summit in Austin. This is based on the requests the mitaka PTLs  
have made, space availability and project activity & collaboration needs.  

| fb: fishbowl 40-min slots  
| wr: workroom 40-min slots  
| cm: Friday contributors meetup  
| | full: full day, half: only morning or only afternoon  

Neutron: 9fb, cm:full  
Nova: 18fb, cm:full  
Fuel: 3fb, 11wr, cm:full  
Horizon: 1fb, 7wr, cm:half  
Cinder: 4fb, 5wr, cm:full  
Keystone: 5fb, 8wr; cm:full  
Ironic: 5fb, 5wr, cm:half  
Heat: 4fb, 8wr, cm:half  
TripleO: 2fb, 3wr, cm:half  
Kolla: 4fb, 10wr, cm:full  
Oslo: 3fb, 5wr  
Ceilometer: 2fb, 7wr, cm:half  
Manila: 2fb, 4wr, cm:half  
Murano: 1fb, 2wr  
Rally: 2fb, 2wr  
Sahara: 2fb, 6wr, cm:half  
Glance: 3fb, 5wr, cm:full  
Magnum: 5fb, 5wr, cm:full  
Swift: 2fb, 12wr, cm:full  
OpenStackClient: 1fb, 1wr, cm:half  
Senlin: 1fb, 5wr, cm:half  
Monasca: 5wr  
Trove: 3fb, 6wr, cm:half  
Dragonflow: 1fb, 4wr, cm:half*  
Mistral: 1fb, 3wr  
Zaqar: 1fb, 3wr, cm:half  
Barbican: 2fb, 6wr, cm:half  
Designate: 1fb, 5wr, cm:half  
Astara: 1fb, cm:full  
Freezer: 1fb, 2wr, cm:half  
Congress: 1fb, 3wr  
Tacker: 1fb, 3wr, cm:half  
Kuryr: 1fb, 5wr, cm:half*  
Searchlight: 1fb, 2wr  
Cue: no space request received  
Solum: 1fb, 1wr  
Winstackers: 1wr  
CloudKitty: 1fb  
EC2API: 2wr  

Infrastructure: 3fb, 4wr, cm:day**  
Documentation: 4fb, 4wr, cm:half  
Quality Assurance: 4fb, 4wr, cm:day**  
PuppetOpenStack: 2fb, 3wr, cm:half  
OpenStackAnsible: 1fb, 8wr, cm:half  
Release mgmt: 1fb, cm:half  
Security: 3fb, 2wr, cm:half  
ChefOpenstack: 1fb, 2wr  
Stable maint: 1fb  
I18n: cm:half  
Refstack: 3wr  
OpenStack UX: 2wr  
RpmPackaging: 1fb***, 1wr  
App catalog: 1fb, 2wr  
Packaging-deb: 1fb***, 1wr  

*: shared meetup between Kuryr and Dragonflow  
**: shared meetup between Infra and QA  
***: shared fishbowl between RPM packaging and DEB packaging, for  
collecting wider packaging feedback  

We'll start working on laying out those sessions over the available  
rooms and time slots. Most of you have communicated constraints together  
with their room requests (like Manila not wanting overlap with Cinder  
sessions), and we'll try to accommodate them the best we can. If you  
have extra constraints you haven't communicated yet, please reply to me  
ASAP.  

Now is time to think about the content you'd like to cover during those  
sessions and fire up those newton etherpads :)  

Cheers,  

--  
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

[openstack-dev] [murano] PTL Candidacy

2016-03-14 Thread Kirill Zaitsev

I would like to announce my candidacy for murano PTL

Those of you, who joined Murano during lastest couple of cycles probably bumped 
into me on the IRC. And those of you, who have been with Murano for a long time 
probably know me as an active reviewer/contributor and release manager for 
Mitaka cycle. I hope this allows me to spare the introductions =)

Working on Murano and being part of Murano and larger OpenStack communities is 
definitely the most engaging and exciting thing I’ve ever done in my career. 
I’m really excited to work with all the smart folks, who put their hard work 
into making murano robust and mature OpenStack project as well as guiding the 
newcomers and seeing new talents join our communities. I’m feeling lucky to 
have the opportunity to dedicate my time and efforts to Murano as a PTL.

Here are a few topics I would like murano project to concentrate on during 
Newton cycle:
Tighter integration with Glare and wider adoption of app versioning. We’ve had 
murano-glare integration implemented in Kilo and in Newton I would like to see 
Glare become the default storage option for murano application packages. This 
would include glare-related integration jobs and closer communication with 
glare community to track and reflect on changes, that are coming to glare 
project. That is going to be one substantial step further to allow Murano apps 
and more importantly Core Library be versioned and distributed in such manner.
Tighter integration with Community App Catalog. From the very beginning of the 
Community App Catalog project I believed, that integration with it is essential 
for Murano’s growth and further development. I’ve been working on implementing 
a fully fledged API for Community App Catalog and plan to continue those 
efforts. This should allow murano to replace current repository-based 
integration with a more robust and mature API approach. Another important 
integration point is the UIs of the murano-dashboard and app-catalog-ui. Seeing 
those work and evolve together is something I’m keen to see.
Continue with multi-region and multi-cloud efforts. In Mitaka cycle we’ve made 
it possible to deploy murano environments into particular region of an OS cloud 
with Murano. That’s a great start, but there is a long road ahead. We would 
need to add more fine-grained control, allow deploying particular apps of the 
environment into different regions, allow single app to spawn resources in 
different regions as well as different clouds. We would need to add UI for this 
features. The road ahead is long, yet exciting!
OSC client integration. I’ve been extremely happy to serve as Outreachy mentor 
for Murano this cycle. My mentee managed to build a foundation of an OSC 
plugin, which I believe should be turned into a full-grown OSC integration and 
become the default CLI for Murano in Newton.
Finalise py3 transition. Not much to say here. We’ve done great job from not 
supporting py3 in Liberty to having client and dashboard py3 compatible in 
Mitaka. The finish line is just a few steps ahead and I’m intending to make 
those steps in Newton.

I’m feeling that Murano as a project has gained some substantial momentum and 
I’m excited to have the opportunity to push us forward.


Cheers, Kirill (kzaitsev)__
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] [Murano] [FFE] Support for Magnum Plugin

2016-03-14 Thread Kirill Zaitsev

I’m going to advocate for this FFE. Even though it’s very late to ask for FFE, 
I believe, that this commit is very low-risk/high reward (the plugin is not 
enabled by default). I believe that code is in good shape (I remember +2 it at 
some point) and would very much like to see this in.

Serg, do you have any objections?

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 14 March 2016 at 11:55:46, Madhuri (madhuri.ra...@gmail.com) wrote:

Hi All,

I would like to request a feature freeze exception for "Magnum/Murano 
rationalization" [1], Magnum app to deploy Kubernetes/Mesos/Swarm cluster. The 
patch is on review[2].
I am looking for your decision about considering this change for a FFE.

[1] https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization
[2] https://review.openstack.org/#/c/269250/

Regards,
Madhuri
__  
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] [app-catalog] Nominating Kirill Zaitsev to App Catalog Core

2016-03-09 Thread Kirill Zaitsev

Thanks everyone, this is an honor and great responsibility. I would do my best 
as App Catalog Core. 

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 9 March 2016 at 05:50:53, Christopher Aedo (d...@aedo.net) wrote:

On Thu, Mar 3, 2016 at 1:10 PM, Christopher Aedo <d...@aedo.net> wrote:  
> I'd like to propose Kirill Zaitsev to the core team for app-catalog  
> and app-catalog-ui.  
> Kirill has been actively involved with the Community App Catalog since  
> nearly the beginning of the project, and more recently has been doing  
> the heavy lifting around implementing GLARE for a new backend.  
>  
> I think he would be an excellent addition - please vote, thanks!  

I failed to set a deadline here, but expected no one would object to  
this proposal. It's been nearly a week so I feel safe in welcoming  
Kirill as an app-catalog core - congrats!  

-Christopher  

__  
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] [Fuel] [murano] [yaql] yaql.js

2016-03-03 Thread Kirill Zaitsev

(and thus port YAQL to JS)

FYI, you’re not the first one to have that idea. =)

We have https://review.openstack.org/#/c/159905/3 an initial draft of how YAQL 
may look on JS. It’s outdated, but most certainly can be revived and finished 
if you have interest in helping us make it happen. =)

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 2 March 2016 at 14:01:57, Vitaly Kramskikh (vkramsk...@mirantis.com) wrote:

Oh, so there is a spec. I was worried that this patch has 
"WIP-no-bprint-assigned-yet" string in the commit message, so I thought there 
is no spec for it. So the commit message should be updated to avoid such 
confusion.

It's really good I've seen this spec. There are plans to overhaul UI data 
format description which we use for cluster and node settings to solve some 
issues and implement long-awaited features like nested structures, so we might 
also want to deprecate our expression language and also switch to YAQL (and 
thus port YAQL to JS).

2016-03-02 17:17 GMT+07:00 Vladimir Kuklin <vkuk...@mirantis.com>:
Vitaly

Thanks for bringing this up. Actually the spec has been on review for almost 2 
weeks: https://review.openstack.org/#/c/282695/. Essentially, this is not 
introducing new DSL but replacing the existing one with more powerful 
extendable language which is being actively developed within OpenStack and is 
already a part of other projects (Murano, Mistral), which has much more 
contributors, can return not only boolean but any arbitrary collections. So it 
means that we want to deprecate current Expression language that you wrote and 
replace it with YAQL due to those reasons. You are not going to extend this 
Expression-based language in 3 weeks up to level of support of extensions, 
method overloading, return of arbitrary collections (e.g. we also want to 
calculate cross-depends and requires fields on the fly which require for it to 
return list of dicts) and support of this stuff on your own, are you?

On Wed, Mar 2, 2016 at 10:09 AM, Vitaly Kramskikh <vkramsk...@mirantis.com> 
wrote:
I think it's not a part of best practices to introduce changes like 
https://review.openstack.org/#/c/279714/ (adding yet another DSL to the 
project) without a blueprint and review and discussion of the spec.

2016-03-02 2:19 GMT+07:00 Alexey Shtokolov <ashtoko...@mirantis.com>:
Fuelers,

I would like to request a feature freeze exception for "Unlock settings tab" 
feature [0]

This feature being combined with Task-based deployment [1] and LCM-readiness 
for Fuel deployment tasks [2] unlocks Basic LCM in Fuel. We conducted a 
thorough redesign of this feature and splitted it into several granular changes 
[3]-[6] to allow users to change settings on deployed, partially deployed, 
stopped or erred clusters and further run redeployment using a particular graph 
(custom or calculated based on expected changes stored in DB) and with new 
parameters.

We need 3 weeks after FF to finish this feature.  
Risk of not delivering it after 3 weeks is low.

Patches on review or in progress:
https://review.openstack.org/#/c/284139/
https://review.openstack.org/#/c/279714/
https://review.openstack.org/#/c/286754/
https://review.openstack.org/#/c/286783/

Specs:
https://review.openstack.org/#/c/286713/
https://review.openstack.org/#/c/284797/
https://review.openstack.org/#/c/282695/
https://review.openstack.org/#/c/284250/


[0] https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab
[1] https://blueprints.launchpad.net/fuel/+spec/enable-task-based-deployment
[2] https://blueprints.launchpad.net/fuel/+spec/granular-task-lcm-readiness
[3] https://blueprints.launchpad.net/fuel/+spec/computable-task-fields-yaql
[4] https://blueprints.launchpad.net/fuel/+spec/store-deployment-tasks-history
[5] https://blueprints.launchpad.net/fuel/+spec/custom-graph-execution
[6] https://blueprints.launchpad.net/fuel/+spec/save-deployment-info-in-database

--
---
WBR, Alexey Shtokolov

__
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




--
Vitaly Kramskikh,
Fuel UI Tech Lead,
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




--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com
www.mirantis.ru
vkuk...@mirantis.com

__
OpenStack Development Mailing List (not for usage ques

Re: [openstack-dev] [all][i18n] Liaisons for I18n

2016-02-29 Thread Kirill Zaitsev

Have just updated myself as a murano liaison. Would be happy to help with 
i18n’ing murano-dashboard!

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 29 February 2016 at 12:29:15, Ying Chun Guo (guoyi...@cn.ibm.com) wrote:

Just noticed the previous mail is not in good format.
Send again for your reading easily.
Sorry for the inconveniency.

---
Hello,

Mitaka translation will start soon, from this week.
In Mitaka translation, IBM full time translators will join the
translation team and work with community translators.
With their help, I18n team is able to cover more projects.
So I need liaisons from dev projects who can help I18n team to work
compatibly with development team in the release cycle.

I especially need liaisons in below projects, which are in Mitaka translation 
plan:
nova, glance, keystone, cinder, swift, neutron, heat, horizon, ceilometer.
 
I also need liaisons from Horizon plugin projects, which are ready in 
translation website:
trove-dashboard, sahara-dashboard,designate-dasbhard, magnum-ui, 
monasca-ui, murano-dashboard and senlin-dashboard.
I need liaisons tell us whether they are ready for translation from project 
view.
 
As to other projects, liaisons are welcomed too.

Here are the descriptions of I18n liaisons:
- The liaison should be a core reviewer for the project and understand the i18n 
status of this project.
- The liaison should understand project release schedule very well.
- The liaison should notify I18n team happens of important moments in the 
project release in time.
For example, happen of soft string freeze, happen of hard string freeze, and 
happen of RC1 cutting.
- The liaison should take care of translation patches to the project, and make 
sure the patches are
successfully merged to the final release version. When the translation patch is 
failed, the liaison
should notify I18n team.

If you are interested to be a liaison and help translators,
input your information here: 
https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n .

Best regards
Ying Chun Guo (Daisy)




__  
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] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

2016-02-27 Thread Kirill Zaitsev

A small followup on murano-dashboard. We have just added i18n support during 
mitaka cycle, and I believe, that murano-dashboard is ready for being 
translated.
There is a https://review.openstack.org/#/c/277874/ cleanup commit, however, 
that I really hope would land before the string freeze. (it removes lot’s of 
unnecessary noise in marked strings and squashes near-identical strings to one)

We’re going to follow string freeze guidelines for murano (since we now have 
our projects translated). And since murano-dashboard follows 
release:cycle-with-milestones the RC1 date is going to be more or less the same 
as horizon’s 

Would be happy to help if you have any more questions.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 26 February 2016 at 08:19:30, Akihiro Motoki (amot...@gmail.com) wrote:

Daisy,

I can followup trove- and sahara- dashboard.
I don't think I can track the status of all of others. This is the
reason I used 'seem' in the past emails.
I suggest to check a release model which each project adopts at
http://governance.openstack.org/reference/projects/index.html.

2016-02-26 9:52 GMT+09:00 Ying Chun Guo <guoyi...@cn.ibm.com>:
> Thank you, Akihiro.
>
> Can you help me to understand these plugin projects are release together
> with Horizon or they have their own release schedule ?
> I mean, do they meet soft freeze/hard freeze/RC1 cutting at the same time
> for Horizon project ?
>
> Best regards
> Ying Chun Guo (Daisy)
>
>
> Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/26 01:00:15:
>
>> From: Akihiro Motoki <amot...@gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev@lists.openstack.org>
>> Date: 2016/02/26 01:04
>
>
>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>> ready for translation in Mitaka?
>>
>> 2016-02-25 19:47 GMT+09:00 Andreas Jaeger <a...@suse.com>:
>> > On 2016-02-25 11:40, Ying Chun Guo wrote:
>> >> Thank you, Akihiro.
>> >> The projects listed below are all in translation website except
>> >> desginate-dasbhard.
>> >
>> > Typo, it' designate, see
>> > https://translate.openstack.org/project/view/designate-dashboard
>>
>> Thanks for the follow-up.
>> Yeah. I typed designate-dashboard and made a mistake :-(
>>
>> >
>> >> Whether these projects can get translated in Mitaka depends.
>> >> Let's discuss with team.
>> >
>> > Andreas
>> >
>> >> Best regards
>> >> Ying Chun Guo (Daisy)
>> >>
>> >>
>> >> Akihiro Motoki <amot...@gmail.com> wrote on 2016/02/23 15:56:39:
>> >>
>> >>> From: Akihiro Motoki <amot...@gmail.com>
>> >>> To: "OpenStack Development Mailing List (not for usage questions)"
>> >>> <openstack-dev@lists.openstack.org>
>> >>> Date: 2016/02/23 16:00
>> >>> Subject: Re: [openstack-dev] [horizon][i18n] Any Horizon plugins
>> >>> ready for translation in Mitaka?
>> >>>
>> >>> Hi Daisy,
>> >>>
>> >>> AFAIK the following horizon plugins are ready for translation.
>> >>> I tested and confirmed translations of these two work well with
>> >>> Japanese.
>> >>> A minor improvement on devstack or other stuff are in progress but it
>> >>> does not affect translation.
>> >>>
>> >>> * trove-dashboard
>> >>> * sahara-dashboard
>> >>>
>> >>> The following horizon plugins SEEM to support translations.
>> >>> I have never tried them.
>> >>>
>> >>> * desginate-dasbhard
>> >>> * magnum-ui
>> >>> * monasca-ui
>> >>> * murano-dashboard
>> >>> * senlin-dashboard
>> >>>
>> >>> Thanks,
>> >>> Akihiro
>> >>>
>> >>> 2016-02-23 15:52 GMT+09:00 Ying Chun Guo <guoyi...@cn.ibm.com>:
>> >>> > Hi,
>> >>> >
>> >>> > Mitaka translation will be started from March 4 and ended in the
>> >>> > week of
>> >>> > March 28.
>> >>> > I'd like to know which Horizon plugins[1] are ready for translation
>> >>> > in
>> >>> > Mitaka release.
>> >>> > If there are, I'm happy to include them in the Mitaka translation
>> >>> > plan.
>> >>> >
>> >>> > Thank you.
&g

Re: [openstack-dev] [murano] Nominate Victor Ryzhenkin to Murano Core

2016-01-28 Thread Kirill Zaitsev

+1 from me. Victor’s continued work on keeping our gates green and stable is 
invaluable. His contribution during M cycle is also very impressive. Looking 
forward to seeing him one of the cores.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 27 January 2016 at 01:10:18, Stan Lagun (sla...@mirantis.com) wrote:

+1!  
Well deserved!  
Sincerely yours,  
Stan Lagun  
Principal Software Engineer @ Mirantis  



On Tue, Jan 26, 2016 at 5:20 AM, Yang, Lin A <lin.a.y...@intel.com> wrote:  
> Glad to see this happened. :)  
> Well deserved, Victor.  
>  
> Lin Yang  
> @Intel  
>  
>> On Jan 23, 2016, at 01:33, Serg Melikyan <smelik...@mirantis.com> wrote:  
>>  
>> I would like to nominate Victor Ryzhenkin (freerunner on IRC) join to the 
>> Murano  
>> core-reviewers team. He has been an active member of the Murano team  
>> for some time now. You can check his review activity report here:  
>> http://stackalytics.com/report/contribution/murano-group/90  
>>  
>> Team please vote for this change in reply to this message.  
>> --  
>> Serg Melikyan, Senior Software Engineer at Mirantis, Inc.  
>> http://mirantis.com | smelik...@mirantis.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

Re: [openstack-dev] [all][clients] Enable hacking in python-*clients

2016-01-25 Thread Kirill Zaitsev

I’d like to +1 the idea of moving these custom checks from repositories to 
hacking.

We, in murano, had a couple of commits, that added custom checks like checking 
that we do not use xrange, mutable objects as default arguments, etc. At first 
those look good and logical, but as their numbers grew, it started to look like 
it

1) bloats the repository with lot’s of unrelated, non-specific code/checks
2) makes OpenStack code-base less uniform (different project have different set 
of rules)
3) doesn’t reuse the same code, but encourages contributors to copy-paste the 
same rule to a dozen of repositories, which is a bad  thing overall

I believe that if you find yourself in a situation, where you want to add a 
custom check to repository — you should first consider adding this very check 
to hacking instead.

On the other hand releasing a new version of hacking and bumping it’s version 
in global requirements (it’s currently pinned to <0.11), might be a painful 
process. Is there any procedure, that hacking (and/or OS community as a whole) 
follows, regarding those upgrades?

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 19 January 2016 at 16:38:56, Akihiro Motoki (amot...@gmail.com) wrote:

2016-01-19 18:58 GMT+09:00 Kekane, Abhishek <abhishek.kek...@nttdata.com>:
>
>
> -Original Message-
> From: Andreas Jaeger [mailto:a...@suse.com]
> Sent: 19 January 2016 15:19
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all][clients] Enable hacking in python-*clients
>
> On 2016-01-19 10:44, Abhishek Kekane wrote:
>>> Hi Abishek,
>>
>>> In my understanding, hacking check is enabled for most (or all) of
>>
>>> python-*client.
>>
>>> For example, flake8 is run for each neutronclient review [1].
>>
>>> test-requirements installs hacking, so I believe hacking check is enabled.
>>
>>> openstackclient and novaclient do the same [2] [3].
>>
>>> Am I missing something?
>>
>> Hi Akhiro Motoki,
>>
>> Individual OpenStack projects has separate hacking module (e.g.
>> nova/hacking/checks.py) which contains additional rules other than
>> standard PEP8 errors/warnings.
>>
>> In similar mode can we do same in python-*clients?
>
> Let's share one common set of rules and not have each repo additional ones. 
> So, if those are useful, propose them for the hacking repo.

Totally agree.

> To answer your questions: Sure, it can be done but why?
>
> Because we can encounter this issues in local environments only, also we can 
> add custom checks like
> 1. use six.string_types instead of basestring
> 2. use dict.items or six.iteritems(dict) instead of dict.items
> 3. checks on assertions etc.

If you find hacking rules you feel useful for various projects,
I would suggest you try to add them to the hacking repo first.

If there is still a reasonable reasons to add the rules to individual repos,
you can propose them (though I believe it is a rare care).

I am not sure there are common rules specific to python-*client repos,
but it seems this is not a case of yours as far as I read this thread.

Akihiro


>
> Abhishek
>
> 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
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> 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.openst

Re: [openstack-dev] [murano] Nominate Rong Zhu to Murano Core

2016-01-25 Thread Kirill Zaitsev

I would very much want to see Rong Zhu to be in Murano Core, but I would like 
to see more contribution and better reviews before that happens.
I would have to say -1 from my side.

1) Rong Zhu is currently the top commiter in M cycle. However looking at his 
commits 
http://stackalytics.com/?user_id=zhu-rong=commits=murano-group — 
most of them are either cosmetic or fix small and non-complex bugs.
I would like to see Rong Zhu participate in development of project more. In 
order to become Core, I would like to see him design and implement a more 
complex feature for the project, not just cleanup typos & docs, and fix easy to 
reach bugs.

2) Rong Zhu is an active reviewer in our projects, and I really appreciate 
that. However, he currently makes less than 1 review a day (on average) and 
there is a lot of place for improvement here. I would also want to see more 
comments and better explanations on his votes, i.e. why he voted the way he did.

Overall I would very like to see Rong Zhu become one of Murano Cores, but right 
now is not the best moment.
I believe he should be a more active reviewer and contribute more to the 
project (beyond just fixing simple bugs) to become a Core reviewer.
I would be happy to assist him on achieving those.
As soon as that happens I would gladly change my vote, but currently it is -1.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 25 January 2016 at 10:29:42, Nikolay Starodubtsev 
(nstarodubt...@mirantis.com) wrote:

+1, no objections from my side.

                                  
Nikolay Starodubtsev
Software Engineer
Mirantis Inc.

Skype: dark_harlequine1

2016-01-22 18:48 GMT+03:00 Serg Melikyan <smelik...@mirantis.com>:
I would like to nominate Rong Zhu (zhurong on IRC) join to the Murano
core-reviewers team. He has been an active member of the Murano team
for some time now. You can check his review activity report here:
http://stackalytics.com/report/contribution/murano-group/90

Team please vote for this change in reply to this message.

--
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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

Re: [openstack-dev] [murano] why not abandon launchpad milestones and/or blueprints?

2015-12-28 Thread Kirill Zaitsev

One more argument in favour of abandoning use of milestones is that they do not 
work well with new stable branch release structure and us having multiple 
repositories rely on one launchpad. We might have murano ver 1.0.5 and 
murano-dashboard ver 1.0.3, which would be totally fine under current 
stable-branch release scheme and really weird in launchpad. I.e. have several 
active milestones or have only the latest milestone active. Or we would have to 
make unnecessary releases, to keep tags in repositories synced (which I also do 
not think is a nice thing to do).

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 22 December 2015 at 17:18:25, Kirill Zaitsev (kzait...@mirantis.com) wrote:

Hi all. A couple of meetings ago I brought this up and promised to start a 
discussion in the ML.
There are two ideas behind this letter:

1st) Since we (and openstack at large) started using reno for release notes — 
launchpad milestones became redundant as a tracking tool of what have been done 
during development of a certain version of an app.
We might still use milestones for what we’re planning to do during a certain 
period of development, but in my opinion it never really worked, since dozens 
of open/in-progress bugs get transferred at release time to the next milestone.

I’d like to discuss the idea to stop using milestones on l-pad and just target 
bugs/bps to series.

+1 from me on the idea as I don’t see milestones being useful anymore

2d) We currently have 3 ways to track something we’d like to implement: 
wishlist-bug, blueprint, spec. A spec always require a blueprint, but a 
blueprint doesn’t always require a spec.

The idea is to minimise the number of tracking tools we use here and to stop 
using blueprints altogether. For small features this would mean assigning a 
wishlist-level bug. And for large features we should file a spec anyway and 
probably a specially tagged bug.

Pros: simpler more streamlined release/bug/feature management. One place to 
search for all functionality.
Cons: we would have to write Closes-Bug, which is kind of misleading. We 
wouldn’t be able to track dependencies between bugs the same way we now do for 
bps.

I don’t have a strong opinion on this one, so I would love to hear out some 
opinions on this one.

-- 
Kirill Zaitsev
Murano team
Software Engineer
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

[openstack-dev] [murano] why not abandon launchpad milestones and/or blueprints?

2015-12-22 Thread Kirill Zaitsev

Hi all. A couple of meetings ago I brought this up and promised to start a 
discussion in the ML.
There are two ideas behind this letter:

1st) Since we (and openstack at large) started using reno for release notes — 
launchpad milestones became redundant as a tracking tool of what have been done 
during development of a certain version of an app.
We might still use milestones for what we’re planning to do during a certain 
period of development, but in my opinion it never really worked, since dozens 
of open/in-progress bugs get transferred at release time to the next milestone.

I’d like to discuss the idea to stop using milestones on l-pad and just target 
bugs/bps to series.

+1 from me on the idea as I don’t see milestones being useful anymore

2d) We currently have 3 ways to track something we’d like to implement: 
wishlist-bug, blueprint, spec. A spec always require a blueprint, but a 
blueprint doesn’t always require a spec.

The idea is to minimise the number of tracking tools we use here and to stop 
using blueprints altogether. For small features this would mean assigning a 
wishlist-level bug. And for large features we should file a spec anyway and 
probably a specially tagged bug.

Pros: simpler more streamlined release/bug/feature management. One place to 
search for all functionality.
Cons: we would have to write Closes-Bug, which is kind of misleading. We 
wouldn’t be able to track dependencies between bugs the same way we now do for 
bps.

I don’t have a strong opinion on this one, so I would love to hear out some 
opinions on this one.

-- 
Kirill Zaitsev
Murano team
Software Engineer
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

[openstack-dev] [murano][i18n] let's start translating murano

2015-12-18 Thread Kirill Zaitsev

We’ve been receiving requests to get murano translated for some time and I’m 
happy to say that you can start doing that today.

Murano is up on zanata [1].
So if you’re using murano and want to see it translated in your language and 
are willing to help that — please join the translation efforts.
Follow the steps you need to take to become openstack translator [2] and join 
the i18n mailing list [3]

If you’re interested in how it works internally: here are few docs to read [4] 
and [5]

I’m looking forward to bringing other murano projects to zanata soon.
And as for now I’m going to start translating murano to Russian. =)

[1] https://translate.openstack.org/project/view/murano
[2] http://docs.openstack.org/developer/i18n/official_translator.html
[3] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
[4] https://wiki.openstack.org/wiki/Translations
[5] https://wiki.openstack.org/wiki/Translations/Infrastructure#Workflow

-- 
Kirill Zaitsev
Murano team
Software Engineer
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] [murano][i18n] let's start translating murano

2015-12-18 Thread Kirill Zaitsev

Thanks for noting that! I was probably a bit too excited for this =) 

Anyway as of this moment murano project on zanata is populated with strings and 
is ready to be translated. =)

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 18 December 2015 at 16:16:17, Andreas Jaeger (a...@suse.com) wrote:

On 12/18/2015 01:35 PM, Kirill Zaitsev wrote:  
> We’ve been receiving requests to get murano translated for some time and  
> I’m happy to say that you can start doing that today.  
>  
> Murano is up on zanata [1].  

Note: It's up there and currently empty.  

It will get content *after* the next merge of any change for the murano  
project,  


Andreas  

> So if you’re using murano and want to see it translated in your language  
> and are willing to help that — please join the translation efforts.  
> Follow the steps you need to take to become openstack translator [2] and  
> join the i18n mailing list [3]  
>  
> If you’re interested in how it works internally: here are few docs to  
> read [4] and [5]  
>  
> I’m looking forward to bringing other murano projects to zanata soon.  
> And as for now I’m going to start translating murano to Russian. =)  
>  
> [1] https://translate.openstack.org/project/view/murano  
> [2] http://docs.openstack.org/developer/i18n/official_translator.html  
> [3] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n  
> [4] https://wiki.openstack.org/wiki/Translations  
> [5] https://wiki.openstack.org/wiki/Translations/Infrastructure#Workflow  


--  
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: 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

[openstack-dev] [murano] let's start using reno

2015-11-24 Thread Kirill Zaitsev

Hello, fellow murano developers. You surely heard about reno [1] — RElease 
NOtes management tool. I’m happy to say, that it’s configured and ready to be 
used for murano itself. If you need an example — here is our 1st commit that 
includes a reno release note https://review.openstack.org/#/c/215542/ [2]

I’m going to be adding reno to all murano repos before mitaka-1 (as mentioned 
in http://lists.openstack.org/pipermail/openstack-dev/2015-November/079795.html 
[3])

Release notes for murano can be found here: 
http://docs.openstack.org/releasenotes/murano/index.html [4]

TLDR:

pip install reno
reno new my-fix-name

then edit releasenotes/notes/my-fix-name-{id}.yaml, delete what you don’t need, 
add/alter what’s important and git add the file to your commit. 

[1] http://docs.openstack.org/developer/reno/
[2] https://review.openstack.org/#/c/215542/
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-November/079795.html
[4] http://docs.openstack.org/releasenotes/murano/index.html

-- 
Kirill Zaitsev
Murano team
Software Engineer
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

[openstack-dev] [reno] [release] Where do release notes of stable branches go?

2015-11-11 Thread Kirill Zaitsev

I’m setting up reno for murano repository and been testing and playing with it 
a bit and this question seems unclear to me.

So where should we put release notes for stable releases? Into respective 
branches or into master?

-- 
Kirill Zaitsev
Murano team
Software Engineer
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] [murano] [glare] Visibility consistency for packages and images

2015-11-10 Thread Kirill Zaitsev

Thanks for summing this up.

We’ve already merged the client patch so I believe we should merge the
dashboard one as well, to keep things consistent among GUI and CLI. Anyway your
concerns are as relevant for dashboard as they are for client.

Keeping dependency graph visibility consistent (i.e. forbidding to change
visibility of a dependency or at least handling it in some reasonable fashion)
right now seems like a very difficult task, but we might be able to do so
during migration towards glare-based backend (i.e. this
https://github.com/openstack/murano-specs/blob/master/specs/liberty/artifact-repository-support.rst
spec). I believe it would require some thought and some input from the
artifacts team as well. One place we can do this is on our weekly meeting.
btw, my suggestion is to file a bp for your bug, since it feels like a feature
of considerable size to me, what do you think?

--
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 4 November 2015 at 15:28:27, Olivier Lemasle (olivier.lema...@apalia.net)
wrote:

Hi all,

Ekaterina Chernova suggested last week to discuss the matter of
visibility consistency for murano packages and glance images,
following my bug report on that subject [1].

The general idea is to make sure that if a murano package is public,
it should be really available for all projects, which mean that:
- if it depends on other murano packages, these packages must be public,
- if it depends on glance images, these images must be public.

In fact, I created this bug report after Alexander Tivelkov's
suggesion on a review request [2] I did to fix a related bug [3]. In
this other bug report, I focused on images visibility during the
initial import of a package, because dependant murano packages are
already imported with the same visibility. It seemed to me most
confusing that packages are made public if the images are private. So
I did a fix in murano-dashboard, which is already merged [4], and
another one for python-muranoclient, still in review ([2]).

What are your thoughts on this subject? Do we need to address first
the general dependency issue? Is this a murano, glance or glare
subject?

Do we still need to do something specific for the initial import
(currently, dependency resolution for packages and images is done both
in murano-dashboard and in python-muranoclient)?

Thank you for your inputs,

[1] https://bugs.launchpad.net/murano/+bug/1509208
[2] https://review.openstack.org/#/c/236834/
[3] https://bugs.launchpad.net/murano/+bug/1507139
[4] https://review.openstack.org/#/c/236830/

--
Olivier Lemasle
Software Engineer
Apalia™
Mobile: +33-611-69-12-11
http://www.apalia.net
olivier.lema...@apalia.net

__
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] [release] establishing release liaisons for mitaka

2015-10-22 Thread Kirill Zaitsev

I’ve updated the page, and marked myself as a release liaison for Murano
(this is coordinated with Serg (sergmelikyan), Murano PTL).

Have already been closely watching release-tagged emails for some time.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 21 October 2015 at 22:48:24, Craig Vyvial (cp16...@gmail.com) wrote:

Doug,

I updated the liaisons for Trove on the wiki page. 

Thanks,
-Craig

On Wed, Oct 21, 2015 at 11:26 AM Doug Hellmann <d...@doughellmann.com> wrote:
Excerpts from Lingxian Kong's message of 2015-10-21 16:42:32 +0800:
> Hi, Doug,
>
> After conversition with Mistral PTL(Renat), I'm willing to be mistral
> liaison to take participate in cross-project release effort on beharf
> of mistral team, so please count me in.

Great, thank you for volunteering!

Please add your contact details to the wiki page [3], and make sure
you have your email client configured so that you will see messages
with the "[release]" topic tag.

Doug

[3] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

>
> On Wed, Oct 14, 2015 at 11:25 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> > As with the other cross-project teams, the release management team
> > relies on liaisons from each project to be available for coordination of
> > work across all teams. It's the start of a new cycle, so it's time to
> > find those liaison volunteers.
> >
> > We are working on updating the release documentation as part of the
> > Project Team Guide. Release liaison responsibilities are documented in
> > [0], and we will update that page with more details over time.
> >
> > In the past we have defaulted to having the PTL act as liaison if no
> > alternate is specified, and we will continue to do that during Mitaka.
> > If you plan to delegate release work to a liaison, especially for
> > submitting release requests, please update the wiki [1] to provide their
> > contact information. If you plan to serve as your team's liaison, please
> > add your contact details to the page.
> >
> > Thanks,
> > Doug
> >
> > [0] 
> > http://docs.openstack.org/project-team-guide/release-management.html#release-liaisons
> > [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
> >
> > __
> > 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] [murano] Murano code flow for custom development and combining murano with horizon in devstack

2015-09-28 Thread Kirill Zaitsev

Hi

1) adding [murano] would definitely suffice

2) Seems that you want to combine some of the murano panels under your own 
dashboard, right? (I do not really see why would you want to do that, but 
still). I believe that it is possible. You can look at 
muranodashboard/dashboard.py file. It defines Panels and a Dashboard murano 
has. Technically you can import those and just follow instructions on 
http://docs.openstack.org/developer/horizon/topics/tutorial.html you mentioned. 

3) Murano-dashboard does not have such a page, because murano-dashboard is 
itself a dashboard built for horizon and follows the structure, defined in the 
article you mentioned.

I might have gotten something wrong, so I once again invite you to join #murano 
on freenode IRC. Would probably be much faster to chat there.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 28 Sep 2015 at 18:23:41, Sumanth Sathyanarayana 
(sumanth.sathyanaray...@gmail.com) wrote:

Thanks Kirill.

Would adding "[murano]” to the subject line suffice or pls let me know if there 
is a separate mailing list for murano?

Let me try to clarify what I am asking over here.
So we have all these panels - 'Compute', 'Network', etc on Horizon dashboard.
If I add another panel like 'Example1' in Horizon by changing the code of 
openstack-dashboard inside horizon, it gets added. Similarly if I change the 
code of murano-dashboard and add another panel 'Example2' it gets added as a 
separate panel. Now, assuming I have some changes in Horizon's 
openstack-dashboard(i.e. example 1) and some changes in murano-dashboard(i.e. 
example2) is there a way of combining them into one panel i.e. say along with 
Compute, Network, etc panels I have something like a Murano panel under which 
both the changes of Horizon's openstack-dashboard(example1 - subpanel) and 
murano-dashboard(example2 - subpanel) be incorporated. 

Would a simple copy paste of say all the changes in Horizon's 
openstack-dashboard to murano-dashboard work or is there a better way of 
handling it.  Is murano-dashboard and openstack-dashboard code flow similar 
with all the different files like 'tables.py', 'form.py', 'views.py', etc? Does 
murano have a tutorial page something similar to this - 
http://docs.openstack.org/developer/horizon/topics/tutorial.html

Thanks & Best Regards
Sumanth

On Mon, Sep 28, 2015 at 3:56 AM, Kirill Zaitsev <kzait...@mirantis.com> wrote:
Hi, murano-dashboard works the same way any other horizon dashboard does.

I’m not quite sure, what you meant by «combined and showed under one tab», 
could you please elaborate?
If you’re asking about debugging — you can install murano-dashboard locally and 
configure it to use remote cloud (i.e. devstack) as descried here 
http://murano.readthedocs.org/en/latest/install/manual.html#install-murano-dashboard
 . If not — then I did’t quite understood what you asked in the first place =)

Feel free to come and ask around in #murano — you might get help there faster 
then on ML =)  

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 26 Sep 2015 at 02:24:10, Sumanth Sathyanarayana 
(sumanth.sathyanaray...@gmail.com) wrote:

Hello,

Could anyone let me know if the changes in murano dashboard and horizon's 
openstackdashboard, both be combined and showed under one tab.
i.e. say under Murano tab on the side left panel all the changes done in 
horizon and murano both appear.

If anyone could point me to a link explaining custom development of murano and 
the code flow would be very helpful...

Thanks & Best Regards
Sumanth

__
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] Murano code flow for custom development and combining murano with horizon in devstack

2015-09-28 Thread Kirill Zaitsev

Hi, murano-dashboard works the same way any other horizon dashboard does.

I’m not quite sure, what you meant by «combined and showed under one tab», 
could you please elaborate?
If you’re asking about debugging — you can install murano-dashboard locally and 
configure it to use remote cloud (i.e. devstack) as descried here 
http://murano.readthedocs.org/en/latest/install/manual.html#install-murano-dashboard
 . If not — then I did’t quite understood what you asked in the first place =)

Feel free to come and ask around in #murano — you might get help there faster 
then on ML =)  

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 26 Sep 2015 at 02:24:10, Sumanth Sathyanarayana 
(sumanth.sathyanaray...@gmail.com) wrote:

Hello,

Could anyone let me know if the changes in murano dashboard and horizon's 
openstackdashboard, both be combined and showed under one tab.
i.e. say under Murano tab on the side left panel all the changes done in 
horizon and murano both appear.

If anyone could point me to a link explaining custom development of murano and 
the code flow would be very helpful...

Thanks & Best Regards
Sumanth

__  
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] [murano] suggestion on commit message title format for the murano-apps repository

2015-09-25 Thread Kirill Zaitsev

Looks reasonable to me! Could you maybe document that on HACKING.rst in the 
repo? We could vote on the commit itself. 

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 25 Sep 2015 at 02:14:09, Alexey Khivin (akhi...@mirantis.com) wrote:

Hello everyone

Almost an every commit-message in the murano-apps repository contains a name of 
the application which it is related to

I suggest to specify application within commit message title using strict and 
uniform format 


For example, something like this:

[ApacheHTTPServer] Utilize Custom Network selector
[Docker/Kubernetes] Fix typo

instead of this:

Utilize Custom Network selector in Apache App
Fix typo in Kubernetes Cluster app


I think it would be useful for readability of the messages list

--
Regards,
Alexey Khivin

__  
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] [murano] [dashboard] Remove the owner filter from "Package Definitions" page

2015-09-11 Thread Kirill Zaitsev

I believe, that pagination is not broken there, since it works the same way 
pagination works on glance images page in horizon (the place the filter comes 
from)
Nevertheless +1 from me on the idea of replacing the filter with text-based 
filter, that would search by name. AFAIK it should be able to paginate based on 
filtered api calls.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 4 Sep 2015 at 14:49:26, Ekaterina Chernova (efedor...@mirantis.com) wrote:

Agreed.

Currently, pagination is broken on "Package definitions" page now, so removing 
that filter
will fix it back. Also, 'Other' tab looks unhelpful, admin should indicate to 
witch tenant this package belongs to.
This improvement will be added later.

Regards,
Kate.

On Fri, Sep 4, 2015 at 1:06 PM, Alexander Tivelkov <ativel...@mirantis.com> 
wrote:
+1 on this.

Filtering by ownership makes sense only on Catalog view (i.e. on the page of 
usable apps) but not on the admin-like console like the list of package 
definitions. 

--
Regards,
Alexander Tivelkov

On Fri, Sep 4, 2015 at 12:36 PM, Dmitro Dovbii <ddov...@mirantis.com> wrote:
Hi folks!

I want suggest you to delete owner filter (3 tabs) from Package Definition 
page. Previously this filter was available for all users and we agreed that it 
is useless. Now it is available only for admin but I think this fact still 
doesn't improve the UX. Moreover, this filter prevents the implementation of 
the search by name, because the work of the two filters can be inconsistent.
So, please express your opinion on this issue. If you agree, I will remove this 
filter ASAP.

Best regards,
Dmytro Dovbii

__
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-dev] [murano] Proposing Nikolai Starodubtsev for core

2015-08-31 Thread Kirill Zaitsev

I’m pleased to nominate Nikolai for Murano core.

He’s been actively participating in development of murano during liberty and is 
among top5 contributors during last 90 days. He’s also leading the CloudFoundry 
integration initiative.

Here are some useful links:

Overall contribution: http://stackalytics.com/?user_id=starodubcevna
List of reviews: 
https://review.openstack.org/#/q/reviewer:%22Nikolay+Starodubtsev%22,n,z
Murano contribution during latest 90 days 
http://stackalytics.com/report/contribution/murano/90

Please vote with +1/-1 for approval/objections

-- 
Kirill Zaitsev
Murano team
Software Engineer
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

[openstack-dev] [murano] [dashboard] public package visibility in Package Definitions UX concern

2015-08-20 Thread Kirill Zaitsev

On our latest irc meeting I raised a concern about public package visibility. 
Here’s the commit that caused my concerns 
https://review.openstack.org/#/c/213682/

We currently have «catalog» and «package definitions» pages in our dashboard. 
The former contains packages that the user can add in his environment, and the 
latter contains packages the user can edit. This means, that admin user sees 
all the packages on package definitions page, while simple user can only see 
packages from his tenant.
Lately we’ve added a filter, similar to the one «Images» dashboard has, that 
separates packages into «project» «public» and «other» groups, to ease 
selection, but this unfortunately introduced some negative UX, cause non-admin 
users now see the filter and expect all the public packages to be there.

This can be solved in a couple of ways.
1) Remove the filter for non-admin user, thus removing any concerns about 
public-packages. User can still sort the table by pressing on the public header.
2) Renaming the filter to something like «my public» for non-admin 
3) Allowing user to see public packages from other tenants, but making all the 
edit options grey, although I’m not sure if it’s possible to do so for bulk 
operation checkboxes.
4) Leave everything as is (ostrich algorithm), as we believe, that this is 
expected behaviour

Personally I like #1 as it makes more sense to me and feels more consistent 
than other options.

Ideas/opinions would be appreciated.

-- 
Kirill Zaitsev
Murano team
Software Engineer
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

[openstack-dev] [murano] new engine is almost here!

2015-08-13 Thread Kirill Zaitsev

This week yaql 1.0.0rc2 has been released 
https://pypi.python.org/pypi/yaql/1.0.0.0rc2 This rc2 would most likely become 
1.0 release.
This also means, that murano is upgrading it’s engine to accommodate changes 
and improvements to new yaql.

If you’re working with upstream/master murano or interested in helping improve 
new engine: please try and test it. Here are  commits, that do the migration: 
murano: https://review.openstack.org/#/c/204099/ 
murano-dashboard: https://review.openstack.org/#/c/203588/
python-muranoclient: https://review.openstack.org/#/c/202684/
Do not forget to install updated client and new yaql to the env with dashboard 
and murano virtual-envs!

If you have any complex custom apps, be sure to test them against the new 
engine, to help us find any bugs we might have missed  there!


-- 
Kirill Zaitsev
Murano team
Software Engineer
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] Does murano dymamic-ui have plan to support edit function?

2015-08-12 Thread Kirill Zaitsev

Hi, sure there are such plans! This have been long referred as 
per-component-UI. I’m really hoping there would be some traction about it 
during mitaka cycle. Not in liberty though, feature freeze is less than a month 
away.

btw, if you’re interested in custom tweaking and fine-tuning of murano 
object-model you can take a look at these CLI tools 
https://review.openstack.org/#/q/project:openstack/python-muranoclient+branch:master+topic:bp/env-configuration-from-cli,n,z

and this https://review.openstack.org/#/c/208659/ commit in particular. 
Although using those would require you to have some knowledge about how murano 
handles things internally.


-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 12 Aug 2015 at 13:23:47, WANG, Ming Hao (Tony T) 
(tony.a.w...@alcatel-lucent.com) wrote:

Dear OpenStack developers,

 

Currently, murano dynamic-ui is “one-time” GUI, and I can’t edit data what has 
been submitted.

Does murano dynamic-ui have plan to support edit function in the future? 

 

For example, developer develops some Wizard GUI to do some configuration, and 
user wants to change some configuration after the deployment.

 

Thanks,

Tony

 

__  
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] Does murano dymamic-ui have plan to support edit function?

2015-08-12 Thread Kirill Zaitsev

Hi Tony, 

After re-readng your question again I tend to agree with Alex. Actions seem to 
be exactly what you’re asking for.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 12 Aug 2015 at 20:16:08, Alexander Tivelkov (ativel...@mirantis.com) wrote:

Hi Tony,  

Thanks for your interest!  

This is a complicated topic. Being able to edit the object model (with  
DynamicUI, the CLI tools mentioned by Kirill or manually with murano's  
API) is just the tip of the iceberg: if you have already deployed your  
application, modifying of some of its input properties will not be  
enough: the application developer has to supply the logic which will  
handle the changes and will execute all the needed actions to  
reconfigure the app.  

Right now the right way to do so is to create an action method (see  
[1] for details), which may be called for already deployed apps. In  
this action you may change the properties of the object and do  
whatever custom handling you may need to reconfigure your app. For  
example, if you want to change the password of the database admin user  
of the mysql app, you may add an action method changeAdminPassword  
which will not only set '$.password' property to a new value, but will  
also execute an appropriate password-changing script on the VM running  
the database instance.  

Right now the actions are partially supported on the UI level (in the  
dashboard you may call any action of any deployed application),  
however currently you cannot pass any parameters to these actions if  
called from the UI, and being able to pass them is indeed required for  
your scenario (in the aforementioned example with DB password change,  
such an action should have at least one parameter - the new password  
value). This will be probably addressed during the M cycle as part of  
the per-component UI initiative mentioned by Kirill: we will provide  
a way to render dynamic UI dialogs not only for the new applications  
being added but also for the actions of the already deployed apps.  

Hope this helps.  
Please let me know if you have any questions on Actions and any other  
related topics  

[1] 
http://murano.readthedocs.org/en/latest/draft/appdev-guide/murano_pl.html#murano-actions
  

--  
Regards,  
Alexander Tivelkov  


On Wed, Aug 12, 2015 at 2:16 PM, WANG, Ming Hao (Tony T)  
tony.a.w...@alcatel-lucent.com wrote:  
 Kirll,  
  
  
  
 Thanks for your info very much!  
  
 We will study it first.  
  
  
  
 Thanks,  
  
 Tony  
  
  
  
 From: Kirill Zaitsev [mailto:kzait...@mirantis.com]  
 Sent: Wednesday, August 12, 2015 7:12 PM  
 To: WANG, Ming Hao (Tony T); OpenStack Development Mailing List (not for  
 usage questions)  
 Subject: Re: [openstack-dev] Does murano dymamic-ui have plan to support  
 edit function?  
  
  
  
 Hi, sure there are such plans! This have been long referred as  
 per-component-UI. I’m really hoping there would be some traction about it  
 during mitaka cycle. Not in liberty though, feature freeze is less than a  
 month away.  
  
  
  
 btw, if you’re interested in custom tweaking and fine-tuning of murano  
 object-model you can take a look at these CLI tools  
 https://review.openstack.org/#/q/project:openstack/python-muranoclient+branch:master+topic:bp/env-configuration-from-cli,n,z
   
  
  
  
 and this https://review.openstack.org/#/c/208659/ commit in particular.  
 Although using those would require you to have some knowledge about how  
 murano handles things internally.  
  
  
  
  
  
 --  
 Kirill Zaitsev  
 Murano team  
  
 Software Engineer  
  
 Mirantis, Inc  
  
  
  
 On 12 Aug 2015 at 13:23:47, WANG, Ming Hao (Tony T)  
 (tony.a.w...@alcatel-lucent.com) wrote:  
  
 Dear OpenStack developers,  
  
  
  
 Currently, murano dynamic-ui is “one-time” GUI, and I can’t edit data what  
 has been submitted.  
  
 Does murano dynamic-ui have plan to support edit function in the future?  
  
  
  
 For example, developer develops some Wizard GUI to do some configuration,  
 and user wants to change some configuration after the deployment.  
  
  
  
 Thanks,  
  
 Tony  
  
  
  
 __  
 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

Re: [openstack-dev] [api] [all] To changes-since or not to changes-since

2015-08-10 Thread Kirill Zaitsev

GET /app/items?f_updated_at=gte:some_timestamp

I guess this should only return existing entries in a collection, while the 
proposition was to add deleted entries to the result too (if we use 
changes_since). More like a delta, than simple filtering.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 10 Aug 2015 at 07:10:23, hao wang (sxmatch1...@gmail.com) wrote:

Hi, stackers

Since now we have merged filtering guideline[1], is that said we should 
implement this feature according this guideline?  like this:

GET /app/items?f_updated_at=gte:some_timestamp

Do we have reached a consensus about this?

2015-06-19 17:07 GMT+08:00 Chris Dent chd...@redhat.com:

There's an open question in the API-WG on whether to formalize or
otherwise enshrine the concept of a changes-since query parameter
on collection oriented resources across the projects. The original
source of this concept is from Nova's API:

    
http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html

There are arguments for and against but we've been unable to reach a
consensus so the agreed next step was to bring the issue to the
mailing list so more people can hash it out and provide their input.
The hope is that concerns or constraints that those in the group
are not aware of will be revealed and a better decision will be
reached.

The basic idea of changes-since is that it can be used as a way to
signal that the requestor is doing some polling and would like to
ask Give me stuff that has changed since the last time I checked.
As I understand it, for the current implementations (in Nova and
Glance) this means including stuff that has been deleted. Repeated
requests to the resource with a changes-since parameter gives a
running report on the evolving state of the resource. This is intended
to allow efficient polling[0].

The pro camp on this likes it because this is very useful and quite
humane: The requestor doesn't need to know the details of how the
query is is implemented under the hood. That is, if there are
several timestamps associated with the singular resources in the
collection which of those are used for time comparison and which
attributes (such as state with a value of deleted) are used to
determine if a singular resource is included. The service gets to
decide these things and in order for efficient polling to actually
be achieved it needs to do in order to make effective queries of the
data store.

The con camp doesn't like it because it introduces magic, ambiguity
and inconsistency into the API (when viewed from a cross-project
perspective) and one of the defining goals of the working group is
to slowly guide things to some measure of consistency. The
alternate approach is to formulate a fairly rigorous query system
for both filtering[1] and sorting[2] and use that to specify
explicit queries that state I want resources that are newer than time
X in timestamp attribute 'updated_at' _and_ have attribute 'state'
that is one of 'foo', 'bar' or 'baz'.

(I hope I have represented the two camps properly here and not
introduced any bias. Myself I'm completely on the fence. If you
think I've misrepresented the state of things please post a
clarifying response.)

The questions come down to:

* Are there additional relevant pros and cons for the two proposals?
* Are there additional proposals which can address the shortcomings
  in either?

Thanks for your input.

[0] Please try to refrain from responses on the line of ha!
    efficiency! that's hilarious! and ZOMG, polling, that's so
    last century. Everybody knows this already and it's not
    germane to the immediate concerns. We'll get to a fully message
    driven architecture next week. This week we're still working
    with what we've got.
[1] filtering guideline proposal
    https://review.openstack.org/#/c/177468/
[2] sorting guideline proposal
    https://review.openstack.org/#/c/145579/
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
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



--
Best Wishes For You!
__  
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] [murano] periodic jobs reminder

2015-08-06 Thread Kirill Zaitsev

hi

This letter is just a heads up, that murano now has periodic jobs, that report 
any failures in stable branches to 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint 
mailing list.

So if you’re interested — you should subscribe to the mailing list (and 
possibly add some filters for murano =))
Thanks for your attention =)

-- 
Kirill Zaitsev
Murano team
Software Engineer
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] [murano] eslint cleanup

2015-07-29 Thread Kirill Zaitsev

I gave it some thought, and came to a conclusion, that adopting openstack 
config is the right thing to do. It enables some of the rules, that are 
disabled by default, so it actually is stricter, than our current config. So 
https://review.openstack.org/#/c/206729/

Thank you again for your work Michael!

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 28 Jul 2015 at 17:38:03, Michael Krotscheck (krotsch...@gmail.com) wrote:

Well, the reasons those rules are deactivated is because they simply had no 
equivalent in the previous tool, and we didn't want to force the Horizon team 
to suddenly take on a far more aggressive style correction job than they'd 
signed up for. Once their job goes green, I'm going to start updating those 
rules one by one to slowly tighten the rules set.

With that in mind though: You can always extend the openstack rules and add 
your own additional restrictions. So: Best of both worlds :), just make sure 
you keep track of what's coming in from upstream.

Michael

On Tue, Jul 28, 2015 at 3:58 AM Kirill Zaitsev kzait...@mirantis.com wrote:
Thanks Michael,
I’m actually watching this process closely, and considering switching to these 
rules, as soon as the job goes green. =)

The upside of not doing so is that, since our (murano) js code base is 
significantly smaller than that of horizon — we can impose slightly stricter 
rule set, than horizon currently does. But switching to it completely is 
something, that I do consider and it is on the roadmap =)

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 28 Jul 2015 at 03:00:40, Michael Krotscheck (krotsch...@gmail.com) wrote:

FYI, those rules have been moved into OpenStack under the QA program. I'm 
currently working on getting npm publish jobs to function so we can release 
those rules as well.

http://git.openstack.org/cgit/openstack/eslint-config-openstack/

Michael

On Mon, Jul 27, 2015 at 4:13 PM Kirill Zaitsev kzait...@mirantis.com wrote:
Since there was some interest in my side activity (which is described in 
https://blueprints.launchpad.net/murano/+spec/add-js-lint-jobs) I’ve created an 
etherpad with files, that are yet to be cleaned up. 

Here is the link https://etherpad.openstack.org/p/murano-escleanup
So I suggest, that if you’re willing to help — add yourself in front of the 
file you’d like to cleanup so that we would not do the same job twice. 

When adding rule configs I try to refer to 
https://github.com/krotscheck/eslint-config-openstack/blob/master/.eslintrc 
(I’m considering switching to it completely, but that is a story for a 
different letter =))
 
-- 
Kirill Zaitsev
Murano team
Software Engineer
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
__
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] [murano] eslint cleanup

2015-07-28 Thread Kirill Zaitsev

Thanks Michael,
I’m actually watching this process closely, and considering switching to these 
rules, as soon as the job goes green. =)

The upside of not doing so is that, since our (murano) js code base is 
significantly smaller than that of horizon — we can impose slightly stricter 
rule set, than horizon currently does. But switching to it completely is 
something, that I do consider and it is on the roadmap =)

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 28 Jul 2015 at 03:00:40, Michael Krotscheck (krotsch...@gmail.com) wrote:

FYI, those rules have been moved into OpenStack under the QA program. I'm 
currently working on getting npm publish jobs to function so we can release 
those rules as well.

http://git.openstack.org/cgit/openstack/eslint-config-openstack/

Michael

On Mon, Jul 27, 2015 at 4:13 PM Kirill Zaitsev kzait...@mirantis.com wrote:
Since there was some interest in my side activity (which is described in 
https://blueprints.launchpad.net/murano/+spec/add-js-lint-jobs) I’ve created an 
etherpad with files, that are yet to be cleaned up. 

Here is the link https://etherpad.openstack.org/p/murano-escleanup
So I suggest, that if you’re willing to help — add yourself in front of the 
file you’d like to cleanup so that we would not do the same job twice. 

When adding rule configs I try to refer to 
https://github.com/krotscheck/eslint-config-openstack/blob/master/.eslintrc 
(I’m considering switching to it completely, but that is a story for a 
different letter =))
 
-- 
Kirill Zaitsev
Murano team
Software Engineer
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
__  
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] [murano] eslint cleanup

2015-07-27 Thread Kirill Zaitsev

Since there was some interest in my side activity (which is described in 
https://blueprints.launchpad.net/murano/+spec/add-js-lint-jobs) I’ve created an 
etherpad with files, that are yet to be cleaned up. 

Here is the link https://etherpad.openstack.org/p/murano-escleanup
So I suggest, that if you’re willing to help — add yourself in front of the 
file you’d like to cleanup so that we would not do the same job twice. 

When adding rule configs I try to refer to 
https://github.com/krotscheck/eslint-config-openstack/blob/master/.eslintrc 
(I’m considering switching to it completely, but that is a story for a 
different letter =))
 
-- 
Kirill Zaitsev
Murano team
Software Engineer
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] [Murano] Should we move to #openstack-murano ?

2015-07-17 Thread Kirill Zaitsev

Heat does seem to use #heat though. But I have to agree, that most os OpenStack 
projects use #openstack-something 

I do not have a strong opinion about the idea, but I’m pretty sure nobody came 
to #openstack-murano and asked anything there. People usually do not ask 
questions in empty channels ;)))


-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 17 Jul 2015 at 19:23:30, Ekaterina Chernova (efedor...@mirantis.com) wrote:

Hi guys!

Currently Murano holds the #murano IRC channel.

But all openstack projects have the openstack- prefix in their channel’s name.

So I have a question: should we move to #openstack-murano?

I think it’s a good idea, since it’s more obvious to go to #openstack-murano if 
one needs help with murano.

Do you know if anybody tried to get help at #openstack-murano and discovered 
that this is not the official Murano channel ?

Would it be hard to migrate from one channel to another?

Regards,
Kate.
__  
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] [murano] [congress] murano congress integration test - trusts

2015-07-15 Thread Kirill Zaitsev

Just to keep track, Victor started a bug on that: 
https://bugs.launchpad.net/murano/+bug/1474938/ Haven’t looked close into the 
problem, yet, though. Will try to do so some time soon.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 15 Jul 2015 at 16:44:24, Filip Blaha (filip.bl...@hp.com) wrote:

Hi all  

our congress integration tests were broken by the change [1] (trusts  
enabled by default). However I suspect problem could be with  
initialization congress client [2] or in python-congressclient. Any  
ideas about that? Thanks  

[1] https://review.openstack.org/#/c/194615/  
[2]  
https://github.com/openstack/murano/blob/6ac473fabbc2d2e1f3ed4c3d36be6439c1d6c2cd/murano/engine/client_manager.py#L102
  

Regards  
Filip  



__  
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] [Murano] Versioning of Murano packages and MuranoPL classes

2015-07-14 Thread Kirill Zaitsev

Alexander, do you plan to update the https://review.openstack.org/#/c/140402/ 
versioning spec? We can possibly try to make it a joint effort, if you like.


-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 14 Jul 2015 at 11:34:56, Alexander Tivelkov (ativel...@mirantis.com) wrote:

Gosha,

Could you please elaborate what do you mean by extra blocks? Glance V3 comes 
with Glance out-of-the box, no extra deployment is needed. The only thing one 
will have to install is Murano Package Type plugin - but it will be installed 
at the same time with Murano.

--
Regards,
Alexander Tivelkov

On Mon, Jul 13, 2015 at 5:54 PM, Georgy Okrokvertskhov 
gokrokvertsk...@mirantis.com wrote:


On Mon, Jul 13, 2015 at 2:19 AM, Alexander Tivelkov ativel...@mirantis.com 
wrote:
Hi Gosha,

Supporting versioning in existing backend will require us to re-implement the 
significant part of Artifact Repository in Murano API: we'll need to add 
versions and dependencies concepts into our model (which is already complicated 
and dirty enough), extend appropriate API calls etc. And all the efforts will 
be a waste of time once we finally migrate to Artifacts.

Also, what do you mean by set by default? V3 API is experimental, but it is 
already merged into upstream Glance, so there is no problem with using it in 
Murano right away.

This is exactly why I have these concerns. I wonder how much customers will use 
experimental API in production. I just don't want to add extra block on Murano 
adoption way.

 
--
Regards,
Alexander Tivelkov

On Fri, Jul 10, 2015 at 5:56 PM, Georgy Okrokvertskhov 
gokrokvertsk...@mirantis.com wrote:
Hi Alex,

Thank you for the great summary.

I have a concern about item #8. Can we add an option to Murano to use previous 
storage engine rather then Glance v3? We need to make sure that v3 API in 
Glance is set by default before we do a hard dependency on it in Murano.

Thanks
Gosha

On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov ativel...@mirantis.com 
wrote:
Hi folks,

Ability to manage multiple versions of application packages and their 
dependencies was always an important item in Murano roadmap, however we still 
don't have a clear spec for this feature. 
Yesterday we hosted a small design session to come up with a plan on what can 
be done in Liberty timeframe to have proper versioning for MuranoPL classes and 
packages. Stan Lagun, Kirill Zaitsev and myself participated offline, some 
other muranoers joined remotely. Thanks to everybody who joined us.

TL;DR: it turns out that now we have a clear plan which will allow us to 
achieve proper versioning of the packages and classes, and we'll try to 
implement the most important parts of it in Liberty.

Here is the detailed outcome of the session:

We'll use the standard Semantic Versioning format 
('Major.Minor.Patch[-dev-build.label[+metadata.label]]') to version our 
packages: changes which break backwards-compatibility should increment the 
major segment, non-breaking new features increment the minor segment and all 
non-breaking bugfixes increment the patch segment. The developers should be 
carefull with the new features part: if you add a new method to a class, it 
may be considered a breaking change if the existing subclasses of this class 
have the same method already declared. We still assume that such changes should 
lead to increment of 'minor' segment, however it is up to best judgement of 
developers in particular case: if the risk of such method override is really 
high it may worth to increment the 'major' segment. Proper guideline on the 
versioning rules will be published closer to L release.

A new field 'Version' is introduced into package manifest file which should 
define package version in complete semver format. The field itself is optional 
(so existing apps are not broken), if it is not specified the package is 
assumed to have version '0.0.0'

The existing 'Require' block of Application manifest will be used to specify 
the package dependencies. Currently it is a yaml-based dictionary, with the 
keys set to fully-qualified names of the dependency packages and the values set 
to the version of those dependencies. Currently this block is used only for 
integration with apps stored at apps.openstack.org. It is suggested to use this 
block in the deployment process as well, and extend its semantics.
The version of the dependency specified there should also follow the semver 
notation, however it may be specified in the shortened format, i.e. without 
specifying the 'patch' or 'patch' and 'minior' components. In this case the 
dependency will be specified as a range of allowed versions. For example, a 
dependency version 1.2 will mean a (1.2.0 = version  1.3) range.
If the version of a dependency is not specified (like in this existing app - 
[1]) then we assume the version 0 - i.e. the last available pre-release 
version of a package.

Murano core library is also a package which has its own version

Re: [openstack-dev] [Keystone] Symbol not found: _BIO_new_CMS

2015-07-14 Thread Kirill Zaitsev

Just for the sake of future googlers. I’ve encountered the same problem (with 
horizon actually) and managed to solve it.

1) install and link latest openssl from homebrew: brew update  brew install 
openssl  brew link --force openssl
2) run tox, it fails.
3) manually activate the environment you want: . .tox/venv/bin/activate
4) build cryptography package with brew ssl: 
LDFLAGS=-L/usr/local/opt/openssl/lib CPPFLAGS=-I/usr/local/opt/openssl/include 
pip install --force-reinstall --upgrade --no-binary cryptography cryptography
5) deactivate

that’s it — that should do the trick. Someone might be able to suggest a better 
way to do this, but this variant works for me. (As long as I do not rebuild 
venv too often =))

-- 
Kirill Zaitsev
Murano team
Software Engineer
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

[openstack-dev] [murano] idea of introducing a spec-freeze, during M cycle

2015-07-12 Thread Kirill Zaitsev

We had discussed this (see subj) interesting idea, during our latest meeting in 
IRC 
(http://eavesdrop.openstack.org/meetings/murano/2015/murano.2015-07-07-17.01.html)
The idea was borrowed from nova, who froze their specs shortly after L1 
release. The reasoning behind this is rather simple, as adding something, that 
requires a spec during a 2d half of the cycle, seems like a not so good idea. 
Knowing that there would be a spec freeze of some sort, would probably 
1) make contributors want to write their specs beforehan
2) make reviewers review specs more often (although I’m not really sure if 
there is a good way to encourage spec reviews)

What do you think about such an idea? 
Obviously introducing a spec-freeze for liberty (without proper prior notice) 
is a bad thing to do. But sounds like a reasonable idea for M cycle. Somewhere 
between M-1 and M-2, maybe? What do you think?

-- 
Kirill Zaitsev
Murano team
Software Engineer
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

[openstack-dev] [murano] We're enabling trusts by default in murano liberty

2015-06-23 Thread Kirill Zaitsev

Hello all.
I’m writing this letter to notify you of a small, but important change, that is 
about to come.
https://review.openstack.org/194615

We’re enabling trusts by default in murano and asking everyone who is using 
murano for development to upgrade and/or start using them and help us properly 
test them. Use of trusts was implemented them in kilo. The main problem this 
decision might pose is the fact that our trusts code has not yet been 
battle-tested, therefore there might be some errors associated with it. But 
ideally you shouldn’t even notice that you enabled them! =)


The reason behind this decision is simple — this is the intended behaviour of 
murano-engine. With current behaviour as soon as the user logs out of horizon — 
his or her token would become invalid and any deployment started by the user 
can fail. Trusts solve this problem naturally.


-- 
Kirill Zaitsev
Murano team
Software Engineer
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] [murano] shellcheck all .sh scripts in murano-deployment

2015-06-18 Thread Kirill Zaitsev

After thinking about this for a while, I came to think, that we also need a 
jslinter job for murano-dashboard.
Horizon is currently adopting eslint as a one tool for the job (meant to 
replace jscs and jshint afaiu), so we could adopt this as part of the 
blueprint, I filed.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 15 Jun 2015 at 02:27:06, Kirill Zaitsev (kzait...@mirantis.com) wrote:

Since there were no objections, and as a follow-up I’ve created a BP for that 
in murano: https://blueprints.launchpad.net/murano/+spec/add-shellcheck-jobs

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 10 Jun 2015 at 18:07:19, Filip Blaha (filip.bl...@hp.com) wrote:

Thanks for comment and suggestion!

there is also shutil2 framework for unit testing over shell scripts. We
shall consider it whether it could bring us value for the effort. I
personally have no strong opinion about that. Little contradiction to my
previous mail:-)

Regards
Filip



On 06/10/2015 03:34 PM, Jeremy Stanley wrote:
 On 2015-06-10 13:48:26 +0200 (+0200), Filip Blaha wrote:
 +1, nice idea. Shell script are not easy to review - large files, not
 covered by unit tests. Any automatic tool could be beneficial.
 It's worth noting that just because your shell scripts don't have
 their own validation tests doesn't mean they can't. For example see
 the test-features.sh and test-functions.sh scripts in the
 https://git.openstack.org/cgit/openstack-infra/devstack-gate/ repo,
 making sure we maintain a contract on things like branch fallback
 logic which is easy to subtly break if not tested.


__
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] [murano] shellcheck all .sh scripts in murano-deployment

2015-06-14 Thread Kirill Zaitsev

Since there were no objections, and as a follow-up I’ve created a BP for that 
in murano: https://blueprints.launchpad.net/murano/+spec/add-shellcheck-jobs

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 10 Jun 2015 at 18:07:19, Filip Blaha (filip.bl...@hp.com) wrote:

Thanks for comment and suggestion!  

there is also shutil2 framework for unit testing over shell scripts. We  
shall consider it whether it could bring us value for the effort. I  
personally have no strong opinion about that. Little contradiction to my  
previous mail:-)  

Regards  
Filip  



On 06/10/2015 03:34 PM, Jeremy Stanley wrote:  
 On 2015-06-10 13:48:26 +0200 (+0200), Filip Blaha wrote:  
 +1, nice idea. Shell script are not easy to review - large files, not  
 covered by unit tests. Any automatic tool could be beneficial.  
 It's worth noting that just because your shell scripts don't have  
 their own validation tests doesn't mean they can't. For example see  
 the test-features.sh and test-functions.sh scripts in the  
 https://git.openstack.org/cgit/openstack-infra/devstack-gate/ repo,  
 making sure we maintain a contract on things like branch fallback  
 logic which is easy to subtly break if not tested.  


__  
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] [murano] backporting changes to stable/juno and stable/kilo

2015-06-10 Thread Kirill Zaitsev

Hi all. I’ve been looking through the bugs/fixes we’ve made during kilo cycle. 
Some of them are worthy of being backported to stable/juno. And some of the 
fixes we’ve already made in liberty are worthy of being backported to 
stable/kilo.

Since we’ve agreed on using tags for bugs I’ve marked those bugs as 
juno-backport-potential and kilo-backport-potential.

Here are the links for them 

murano bugs with tag 'juno-backport-potential’ and without a tag 
‘in-stable-juno’ : http://j.mp/murano-juno-backport
murano bugs in murano with tag ‘kilo-backport-potential’ and without a tag 
‘in-stable-kilo’: http://j.mp/murano-kilo-backport

python-muranoclient bugs with tag 'juno-backport-potential’ and without a tag 
‘in-stable-juno’ : http://j.mp/muranoclient-juno-backport
python-muranoclient bugs in murano with tag ‘kilo-backport-potential’ and 
without a tag ‘in-stable-kilo’: http://j.mp/muranoclient-kilo-backport

Sorry for using url shortener, the links are really large and would clutter the 
email otherwise. I also hope I didn’t mess up with them. =) You can construct 
them from Launchpads advanced search.

If you have any objections to the list of bugs to be backported — you can 
comment in respective bugs on l-pad and we can discuss it on a per-bug basis.
If you're aware of any bugs, that have backport potential that are not present 
on the list: feel free to tag them.

-- 
Kirill Zaitsev
Murano team
Software Engineer
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] Tracking bugs in apps on launchpad

2015-06-09 Thread Kirill Zaitsev

+1

Can’t find any objectsions to separating murano-apps from murano.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 8 Jun 2015 at 17:13:22, Dmitro Dovbii (ddov...@mirantis.com) wrote:

Hi, Serg!
Nice!
Why only bug tracking?
I'm looking forward to the first blueprint submitting :)

Regards,
Dmytro Dovbii

2015-06-08 16:34 GMT+03:00 Serg Melikyan smelik...@mirantis.com:
We originally created https://launchpad.net/murano-applications, and I
misspelled address in my first e-mail, but after I was pointed out to
the mistake I've decided to create new project with URL
https://launchpad.net/murano-apps that correspond to the repository
name.

On Mon, Jun 8, 2015 at 4:01 PM, Serg Melikyan smelik...@mirantis.com wrote:
 Hi folks,

 We used to track bugs that we have in applications published in
 openstack/murano-apps repository directly on launchpad.net/murano but
 sometimes it's really inconvenient:

 * applications are not a part of the murano
 * it's hard to properly prioritize bugs, because critical bug for app is not
 critical at all for murano

 We had created murano-apps project on launchpad sometimes ago, but never
 truly used this project. I propose to move existing bugs for applications to
 https://launchpad.net/murano-apps and use this project as place for tracking
 bugs in openstack/murano-apps repository. Folks, what do you think about
 that?
 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com



--
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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

Re: [openstack-dev] [Murano] python-openstackclient support

2015-06-09 Thread Kirill Zaitsev

https://blueprints.launchpad.net/python-muranoclient/+spec/openstack-client-plugin-support

I’ve done that a while ago, already =). 

Could you please approve it?

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 9 Jun 2015 at 11:45:56, Serg Melikyan (smelik...@mirantis.com) wrote:

Hi Kirill,

It's definitely a great idea, it needs to be verified though AFAIK all
openstack projects are moving to support python-openstackclient. I
think we should file a blueprint around that and start looking at that
on background. I think it will be not a big deal to support
python-openstackclient.

On Thu, Apr 23, 2015 at 3:04 AM, Stan Lagun sla...@mirantis.com wrote:

 +1 for the idea though not sure on priority of this since we have so many way 
 more important things to implement in Kilo. I'd say that would be a great 
 contribution if we find someone willing to contribute it :)

 Sincerely yours,
 Stan Lagun
 Principal Software Engineer @ Mirantis


 On Thu, Apr 23, 2015 at 1:55 AM, Kirill Zaitsev kzait...@mirantis.com wrote:

 Since python-openstackclient is now a part of openstack — I guess it would 
 be a good idea to support it in murano. It has setuptools-based plugin 
 system, and it should be fairly easy to add murano commands as plugins to it.
 BTW, It’s based on cliff and has a terrific completion support (which is 
 basically why I started looking into the issue in the first place =))

 What do you think, is it a good idea?

 --
 Kirill Zaitsev
 Sent with Airmail

 __
 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




--  
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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] [Murano] python-openstackclient support

2015-06-09 Thread Kirill Zaitsev

Since it includes a certain research phase (on how to integrate properly) I’d 
bet on half-a-week to week of work. 
But that’s just a wild guess. Might be less, might be more.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 9 Jun 2015 at 14:59:13, Ekaterina Chernova (efedor...@mirantis.com) wrote:

Hi all!

I support the idea!

Kirill, how much time do you think blueprint implementation will take?

On Tue, Jun 9, 2015 at 2:46 PM, Kirill Zaitsev kzait...@mirantis.com wrote:
https://blueprints.launchpad.net/python-muranoclient/+spec/openstack-client-plugin-support

I’ve done that a while ago, already =). 

Could you please approve it?

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 9 Jun 2015 at 11:45:56, Serg Melikyan (smelik...@mirantis.com) wrote:

Hi Kirill,

It's definitely a great idea, it needs to be verified though AFAIK all
openstack projects are moving to support python-openstackclient. I
think we should file a blueprint around that and start looking at that
on background. I think it will be not a big deal to support
python-openstackclient.

On Thu, Apr 23, 2015 at 3:04 AM, Stan Lagun sla...@mirantis.com wrote:

 +1 for the idea though not sure on priority of this since we have so many way 
 more important things to implement in Kilo. I'd say that would be a great 
 contribution if we find someone willing to contribute it :)

 Sincerely yours,
 Stan Lagun
 Principal Software Engineer @ Mirantis


 On Thu, Apr 23, 2015 at 1:55 AM, Kirill Zaitsev kzait...@mirantis.com wrote:

 Since python-openstackclient is now a part of openstack — I guess it would 
 be a good idea to support it in murano. It has setuptools-based plugin 
 system, and it should be fairly easy to add murano commands as plugins to it.
 BTW, It’s based on cliff and has a terrific completion support (which is 
 basically why I started looking into the issue in the first place =))

 What do you think, is it a good idea?

 --
 Kirill Zaitsev
 Sent with Airmail

 __
 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




--
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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-dev] [murano] shellcheck all .sh scripts in murano-deployment

2015-06-09 Thread Kirill Zaitsev

Folks, I’ve got another proposal, mainly to the guys, who deal with CI and test 
jobs daily.

What would you say about adding a job to murano-deployment, that would launch 
shellcheck http://www.shellcheck.net/about.html against all .sh files? 

I use it, when reviewing .sh scripts (well, actually my vim does it for me =P) 
and although It has some excessive checks I find it quite useful.

We could also add a similar job to murano-apps, since they use shell scripts 
quite often.

Any objections to this idea?


-- 
Kirill Zaitsev
Murano team
Software Engineer
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] Tracking bugs in apps on launchpad

2015-06-09 Thread Kirill Zaitsev

First we need to setup bugtracking on murano-apps =)

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 9 Jun 2015 at 15:13:07, Ekaterina Chernova (efedor...@mirantis.com) wrote:

Folks,

nice idea.

Who is wishing to look through all bugs in murano and move to murano-apps 
project appropriate ones?

Regards,
Kate.



On Tue, Jun 9, 2015 at 2:49 PM, Kirill Zaitsev kzait...@mirantis.com wrote:
+1

Can’t find any objectsions to separating murano-apps from murano.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 8 Jun 2015 at 17:13:22, Dmitro Dovbii (ddov...@mirantis.com) wrote:

Hi, Serg!
Nice!
Why only bug tracking?
I'm looking forward to the first blueprint submitting :)

Regards,
Dmytro Dovbii

2015-06-08 16:34 GMT+03:00 Serg Melikyan smelik...@mirantis.com:
We originally created https://launchpad.net/murano-applications, and I
misspelled address in my first e-mail, but after I was pointed out to
the mistake I've decided to create new project with URL
https://launchpad.net/murano-apps that correspond to the repository
name.

On Mon, Jun 8, 2015 at 4:01 PM, Serg Melikyan smelik...@mirantis.com wrote:
 Hi folks,

 We used to track bugs that we have in applications published in
 openstack/murano-apps repository directly on launchpad.net/murano but
 sometimes it's really inconvenient:

 * applications are not a part of the murano
 * it's hard to properly prioritize bugs, because critical bug for app is not
 critical at all for murano

 We had created murano-apps project on launchpad sometimes ago, but never
 truly used this project. I propose to move existing bugs for applications to
 https://launchpad.net/murano-apps and use this project as place for tracking
 bugs in openstack/murano-apps repository. Folks, what do you think about
 that?
 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com



--
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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] [murano] python versions

2015-06-08 Thread Kirill Zaitsev

I’ve looked into several OS projects, and they first seen to implement py3 
support and create a job later. (Except for heat. They already have a 
non-voting py34, which seem to fail every time =))

I suggest we do the same: first make murano work on py34, then make a py34 job. 
I’ll file a blueprint shortly.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 2 Jun 2015 at 15:58:17, Serg Melikyan (smelik...@mirantis.com) wrote:

Hi Kirill,

I agree with Alexander that we should not remove support for python
2.6 in python-muranoclient.

Regarding adding python-3 jobs - great idea! But we need to migrate
python-muranoclient to yaql 1.0 first and then add python-3 jobs,
because previous versions of yaql are not compatible with python-3.

On Tue, Jun 2, 2015 at 3:33 PM, Alexander Tivelkov
ativel...@mirantis.com wrote:
 Hi Kirill,

 Client libraries usually have wider range of python requirements, as they
 may be run on various kinds of legacy environments, including the ones with
 python 2.6. only.
 Murano is definitely not the only project in Openstack which still maintains
 py26 compatibility for its client: nova, glance, cinder and other integrated
 ones do this.

 So, I would not drop py26 support for client code without any good reasons
 to. Are there any significant reasons to do it?
 Regarding py3.4 - this is definitely a good idea.


 --
 Regards,
 Alexander Tivelkov

 On Tue, Jun 2, 2015 at 3:04 PM, Kirill Zaitsev kzait...@mirantis.com
 wrote:

 It seems that python-muranoclient is the last project from murano-official
 group, that still supports python2.6. Other projects do not have a 2.6
 testing job (correct me if I’m wrong).

 Personally I think it’s time to drop support for 2.6 completely, and add
 (at least non-voting) jobs with python3.4 support tests.
 It seems to fit the whole process of moving OS projects towards python 3:
 https://etherpad.openstack.org/p/liberty-cross-project-python3

 What do you think? Does anyone have any objections?

 --
 Kirill Zaitsev
 Murano team
 Software Engineer
 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



 __
 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




--  
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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] [Murano] Nominating Kirill Zaitsev for murano-core

2015-06-02 Thread Kirill Zaitsev

Thanks all!

Someone should now say «With great power comes great responsibility» 

And I should respond with something like «Night gathers, and now my watch 
begins», should I? 


I kind of like this kind of symbolism =) Isn’t there a Core Developer Oath or 
Vow? Shouldn’t we think of one?

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 2 Jun 2015 at 20:27:46, McLellan, Steven (steve.mclel...@hp.com) wrote:

+1  

From: Stan Lagun sla...@mirantis.commailto:sla...@mirantis.com  
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org  
Date: Tuesday, June 2, 2015 at 9:32 AM  
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org  
Subject: Re: [openstack-dev] [Murano] Nominating Kirill Zaitsev for murano-core 
 

+1 without any doubt  

Sincerely yours,  
Stan Lagun  
Principal Software Engineer @ Mirantis  

mailto:sla...@mirantis.com  

On Tue, Jun 2, 2015 at 10:43 AM, Ekaterina Chernova 
efedor...@mirantis.commailto:efedor...@mirantis.com wrote:  
+1  

Regards,  
Kate.  

On Tue, Jun 2, 2015 at 9:32 AM, Serg Melikyan 
smelik...@mirantis.commailto:smelik...@mirantis.com wrote:  
I'd like to propose Kirill Zaitsev to core members of Murano team.  

Kirill Zaitsev is active member of our community, he 
implementedhttps://launchpad.net/murano/+milestone/2015.1.0 several blueprint 
in Kilo and fixed number of bugs, he maintains a really good score as 
contributor:  
http://stackalytics.com/report/users/kzaitsev  

Existing Murano cores, please vote +1/-1 for the addition of Kirill to the 
murano-core.  
--  
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.  
http://mirantis.com | smelik...@mirantis.commailto:smelik...@mirantis.com  

__  
OpenStack Development Mailing List (not for usage questions)  
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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:unsubscribehttp://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] [murano] python versions

2015-06-02 Thread Kirill Zaitsev

It seems that python-muranoclient is the last project from murano-official 
group, that still supports python2.6. Other projects do not have a 2.6 testing 
job (correct me if I’m wrong).

Personally I think it’s time to drop support for 2.6 completely, and add (at 
least non-voting) jobs with python3.4 support tests.
It seems to fit the whole process of moving OS projects towards python 3: 
https://etherpad.openstack.org/p/liberty-cross-project-python3

What do you think? Does anyone have any objections?

-- 
Kirill Zaitsev
Murano team
Software Engineer
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

[openstack-dev] [Murano] python-openstackclient support

2015-04-22 Thread Kirill Zaitsev

Since python-openstackclient is now a part of openstack — I guess it would be a 
good idea to support it in murano. It has setuptools-based plugin system, and 
it should be fairly easy to add murano commands as plugins to it.
BTW, It’s based on cliff and has a terrific completion support (which is 
basically why I started looking into the issue in the first place =))

What do you think, is it a good idea?

-- 
Kirill Zaitsev
Sent with Airmail__
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 clients] Client bash_completion script discovery

2015-04-02 Thread Kirill Zaitsev

Hello all,

Most OS python-xxxclient projects include a tools/xxx.bash_completion file, 
that is invaluable for working with said clients. Correct me if I’m wrong, but 
as far as I see the script is not packaged with any of the python packages on 
the pypi. If the end user wants to install client with

pip install python-xxxclient

she would have to go to that packages git repository and checkout the file by 
hand (and source it of course).


I think it might be a good idea to include completion script with the client in 
the pypi package and add a separate command, smth like `bash-completion-script` 
or `completion-script bash`, that would print the script on the stdout.

Since this applies basically to any python-xxxclient — I’d like to ask for 
input on this idea. Maybe someone already has a similar solution?

-- 
Kirill Zaitsev
Sent with Airmail__
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

91 matches

Mail list logo