Re: [openstack-dev] [telemetry][heat] Removal of Aodh combination alarms

[Sergey Kraynev]

Zane,
as I understand, all related code was removed. Probably we may to remove
our Hidden resource too.

If we want to have hidden resource, then probably as you mentioned will be
enough to raise Exceptions and execute nothing for handle_delete.

On 28 February 2017 at 01:36, Zane Bitter  wrote:

> On 24/02/17 06:15, Julien Danjou wrote:
>
>> Hey,
>>
>> We're about to remove the code for the deprecated combination alarm.
>>
>>   https://review.openstack.org/#/c/429405/
>>
>> I checked and as far as I can tell that should not break Heat gate, but
>> I'd prefer to be sure. So, Heat developers if you have some code relying
>> on it, let us know before we press the big +A button.
>>
>
> Looks like it merged and there was no breakage, so that's good.
>
> How should we handle the (hidden) resource type in Heat?
>
> http://git.openstack.org/cgit/openstack/heat/tree/heat/engin
> e/resources/openstack/aodh/alarm.py#n227
>
> Make handle_delete() return without doing anything, and raise an exception
> in all other handle_*() methods?
>
> - ZB
>
>
> __
> 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,
Sergey.
__
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] OpenStack Summit Barcelona: Heat Meetup (evening)

[Sergey Kraynev]

Looks like they will close hall earlier. :) I will be near of exit

25 окт. 2016 г. 15:45 пользователь "Rico Lin" <ric...@inwinstack.com>
написал:

> Looking forward to the evening event!
>
> Let's meet at Ten's Tapas Restaurant at 8:00 pm.
> Anyone would like to get there together, we can gettering around
> Registration table(CCIB hall) at 7:20 and go there together.
>
> 2016-10-25 15:27 GMT+08:00 Sergey Kraynev <skray...@mirantis.com>:
>
>> Rico,
>>
>> I realized, that this place is not so close to summit center :)
>> So I think, that follow link will be helpful:
>>
>> https://www.google.es/maps/dir/41.4104945,2.2199061/Ten's+
>> Tapas+Restaurant+Barcelona,+Carrer+del+Rec,+Barcelona/@41.39
>> 56423,2.1910301,14z/data=!4m9!4m8!1m0!1m5!1m1!1s0x12a4a2fe1f
>> 791a33:0x77ab372611d976f9!2m2!1d2.1841634!2d41.3843224!3e3?hl=en
>>
>> It's examples of routes from Summit Center to the restaurant.  I know,
>> that each of us can do it himself, but I think, it will be useful to put
>> this link here :)
>>
>> On 24 October 2016 at 10:28, Rico Lin <ric...@inwinstack.com> wrote:
>>
>>> Hola amigos
>>> Let's settle down for a Tuesday meetup
>>> 8:00pm at Ten's Tapas Restaurant [1]
>>> Welcome to join us and have fun.
>>>
>>> [1]
>>> Ten's Tapas Restaurant Barcelona
>>>
>>> Carrer del Rec, 79, 08003 Barcelona
>>> 933 19 22 22
>>>
>>> https://g.co/kgs/7u7qvG
>>>
>>> 2016年10月20日 下午2:40，"Rabi Mishra" <ramis...@redhat.com>寫道：
>>>
>>>> Thanks Rico for taking the initiative. Appreciate it. I'm fine for any
>>>> location on any evening other than Monday.
>>>>
>>>> On Thu, Oct 20, 2016 at 8:58 AM, Rico Lin <ric...@inwinstack.com>
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We're planning to have an evening Heat contributors meetup in
>>>>> Barcelona Summit.
>>>>> We would like every contributor, ops, users join us and have fun.
>>>>> We need to decide which day of that week would be most suited for all
>>>>> of us. If you would like to attend, please put your name and possible days
>>>>> at:
>>>>> http://doodle.com/poll/dyy6tdnawchnddvy
>>>>>
>>>>> As for location, feel free to suggest any.
>>>>> I would suggest `Bambu Beach Bar`[1], drink and tapas which nearby
>>>>> venue, or `Cervecería Catalana`[2] and Tapas 24 [3] which a little far 
>>>>> from
>>>>> the venue. All nice and relax places(Not like the evening place from
>>>>> the last summit I promise!!). Most importantly, all place served beers and
>>>>> drinks( This is very essential if we want to attract our Steve!!).
>>>>>
>>>>>
>>>>> [1] https://www.tripadvisor.com.tw/Restaurant_Review-g187497
>>>>> -d4355271-Reviews-Bambu_Beach_Bar-Barcelona_Catalonia.htm
>>>>> [2] https://www.tripadvisor.com.tw/Restaurant_Review-g187497
>>>>> -d782944-Reviews-Cerveceria_Catalana-Barcelona_Catalonia.html
>>>>> [3] https://www.tripadvisor.com.tw/Restaurant_Review-g187497
>>>>> -d1314895-Reviews-Tapas_24-Barcelona_Catalonia.html
>>>>>
>>>>> --
>>>>> May The Force of OpenStack Be With You,
>>>>>
>>>>> *Rico Lin*irc: ricolin
>>>>>
>>>>>
>>>>> 
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>>> enstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Rabi Misra
>>>>
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>> 
>>> __
>>> OpenStack 

Re: [openstack-dev] [Heat] OpenStack Summit Barcelona: Heat Meetup (evening)

[Sergey Kraynev]

Rico,

I realized, that this place is not so close to summit center :)
So I think, that follow link will be helpful:

https://www.google.es/maps/dir/41.4104945,2.2199061/Ten's+Tapas+Restaurant+Barcelona,+Carrer+del+Rec,+Barcelona/@41.3956423,2.1910301,14z/data=!4m9!4m8!1m0!1m5!1m1!1s0x12a4a2fe1f791a33:0x77ab372611d976f9!2m2!1d2.1841634!2d41.3843224!3e3?hl=en

It's examples of routes from Summit Center to the restaurant.  I know, that
each of us can do it himself, but I think, it will be useful to put this
link here :)

On 24 October 2016 at 10:28, Rico Lin  wrote:

> Hola amigos
> Let's settle down for a Tuesday meetup
> 8:00pm at Ten's Tapas Restaurant [1]
> Welcome to join us and have fun.
>
> [1]
> Ten's Tapas Restaurant Barcelona
>
> Carrer del Rec, 79, 08003 Barcelona
> 933 19 22 22
>
> https://g.co/kgs/7u7qvG
>
> 2016年10月20日 下午2:40，"Rabi Mishra" 寫道：
>
>> Thanks Rico for taking the initiative. Appreciate it. I'm fine for any
>> location on any evening other than Monday.
>>
>> On Thu, Oct 20, 2016 at 8:58 AM, Rico Lin  wrote:
>>
>>> Hi everyone,
>>>
>>> We're planning to have an evening Heat contributors meetup in Barcelona
>>> Summit.
>>> We would like every contributor, ops, users join us and have fun.
>>> We need to decide which day of that week would be most suited for all of
>>> us. If you would like to attend, please put your name and possible days at:
>>> http://doodle.com/poll/dyy6tdnawchnddvy
>>>
>>> As for location, feel free to suggest any.
>>> I would suggest `Bambu Beach Bar`[1], drink and tapas which nearby
>>> venue, or `Cervecería Catalana`[2] and Tapas 24 [3] which a little far from
>>> the venue. All nice and relax places(Not like the evening place from
>>> the last summit I promise!!). Most importantly, all place served beers and
>>> drinks( This is very essential if we want to attract our Steve!!).
>>>
>>>
>>> [1] https://www.tripadvisor.com.tw/Restaurant_Review-g187497
>>> -d4355271-Reviews-Bambu_Beach_Bar-Barcelona_Catalonia.htm
>>> [2] https://www.tripadvisor.com.tw/Restaurant_Review-g187497
>>> -d782944-Reviews-Cerveceria_Catalana-Barcelona_Catalonia.html
>>> [3] https://www.tripadvisor.com.tw/Restaurant_Review-g187497
>>> -d1314895-Reviews-Tapas_24-Barcelona_Catalonia.html
>>>
>>> --
>>> May The Force of OpenStack Be With You,
>>>
>>> *Rico Lin*irc: ricolin
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Regards,
>> Rabi Misra
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Regards,
Sergey.
__
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] [magnum] Subjects to discuss during the summit

[Sergey Kraynev]

Hi Spyros,

AFAIK we already have special session slot related with your topic.
So thank you for the providing all items here.
Rabi, can we add link on this mail to etherpad ? (it will save our time
during session :) )

On 10 October 2016 at 18:11, Spyros Trigazis  wrote:

> Hi heat and magnum.
>
> Apart from the scalability issues that have been observed, I'd like to
> add few more subjects to discuss during the summit.
>
> 1. One nested stack per node and linear scale of cluster creation
> time.
>
> 1.1
> For large stacks, the creation of all nested stack scales linearly. We
> haven't run any tested using the convergence-engine.
>
> 1.2
> For large stacks, 1000 nodes, the final call to heat to fetch the
> IPs for all nodes takes 3 to 4 minutes. In heat, the stack has status
> CREATE_COMPLETE but magnum's state is updated when this long final
> call is done. Can we do better? Maybe fetch only the master IPs or
> get he IPs in chunks.
>
> 1.3
> After the stack create API call to heat, magnum's conductor
> busy-waits heat with a thread/cluster. (In case of a magnum conductor
> restart, we lose that thread and we can't update the status in
> magnum). Investigate better ways to sync the status between magnum
> and heat.
>
> 2. Next generation magnum clusters
>
> A need that comes up frequently in magnum is heterogeneous clusters.
> * We want to able to create cluster on different hardware, (e.g. spawn
>   vms on nodes with SSDs and nodes without SSDs or other special
>   hardware available only in some nodes of the cluster FPGA, GPU)
> * Spawn cluster across different AZs
>
> I'll describe briefly our plan here, for further information we have a
> detailed spec under review. [1]
>
> To address this issue we introduce the node-group concept in magnum.
> Each node-group will correspond to a different heat stack. The master
> nodes can be organized in one or more stacks, so as the worker nodes.
>
> We investigate how to implement this feature. We consider the
> following:
> At the moment, we have three template files, cluster, master and
> node, and all three template files create one stack. The new
> generation of clusters will have a cluster stack containing
> the resources in the cluster template, specifically, networks, lbaas
> floating-ips etc. Then, the output of this stack would be passed as
> input to create the master node stack(s) and the worker nodes
> stack(s).
>
> 3. Use of heat-agent
>
> A missing feature in magnum is the lifecycle operations in magnum. For
> restart of services and COE upgrades (upgrade docker, kubernetes and
> mesos) we consider using the heat-agent. Another option is to create a
> magnum agent or daemon like trove.
>
> 3.1
> For restart, a few systemctl restart or service restart commands will
> be issued. [2]
>
> 3.2
> For upgrades there are three scenarios:
> 1. Upgrade a service which runs in a container. In this case, a small
>script that runs in each node is sufficient. No vm reboot required.
> 2. For an ubuntu based image or similar that requires a package upgrade
>a similar small script is sufficient too. No vm reboot required.
> 3. For our fedora atomic images, we need to perform a rebase on the
>rpm-ostree files system which requires a reboot.
> 4. Finally, a thought under investigation is replacing the nodes one
>by one using a different image. e.g. Upgrade from fedora 24 to 25
>with new versions of packages all in a new qcow2 image. How could
>we update the stack for this?
>
> Options 1. and 2. can be done by upgrading all worker nodes at once or
> one by one. Options 3. and 4. should be done one by one.
>
> I'm drafting a spec about upgrades, should be ready by Wednesday.
>
> Cheers,
> Spyros
>
> [1] https://review.openstack.org/#/c/352734/
> [2] https://review.openstack.org/#/c/368981/
>
> __
> 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,
Sergey.
__
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] Presence at PTG, Atlanta

[Sergey Kraynev]

Thierry,

Thank you for the clarification :)

On 7 October 2016 at 11:35, Thierry Carrez <thie...@openstack.org> wrote:

> Sergey Kraynev wrote:
> > Rabi, thank you for the information.
> >
> > I think, that we need to attend as a team. So I agree with you opinion
> > about option 1.
> > Also I have a question: When do we need prepare new list of topics for
> > design sessions for this event ?
>
> Note that the PTG will not be organized into arbitrary 40-min time
> slots. Teams will be given a room and a number of days (2 or 3), and
> then you are free to organize your time as you see fit (more like what
> happens on the "contributors meetup" on Fridays at the Design Summit,
> and at midcycle sprints).
>
> So while you may still want to prepare a list of topics for your team
> gathering at the PTG, it doesn't have to be artificially lined up with a
> number of 40-min time slots, and you can decide the contents at the last
> minute.
>
> --
> 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
>



-- 
Regards,
Sergey.
__
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] Presence at PTG, Atlanta

[Sergey Kraynev]

Rabi, thank you for the information.

I think, that we need to attend as a team. So I agree with you opinion
about option 1.
Also I have a question: When do we need prepare new list of topics for
design sessions for this event ?

On 7 October 2016 at 08:48, Rabi Mishra  wrote:

> Hi All,
>
> As you would probably know, the first Project Teams Gathering(PTG) will
> happen in Atlanta from Feb 20-24, 2017.
>
> Organizers are working on the event space layout and have asked all
> project teams on their plans to join the event and whether they would
> require/use a separate room.
>
> As this is expected to be a substitute for the 'design summit' plus
> 'mid-cycle meet up' (I'm not sure if we had one before), I assume most the
> contributors would be planning to attend it.
>
>
> We can respond with one of the options below on 'Whether the project team
> is planning to gather for the event?'
>
> 1. Yes, Absolutely
> 2. Maybe, Still Considering it
> 3. No Certainly Not
>
> I think for us it's '1'. However, please let us know if you have different
> idea/opinion on this. We can also discuss about it in the team meeting this
> week.
>
>
> --
> Regards,
> Rabi Misra
>
>
> __
> 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,
Sergey.
__
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] resigning from heat-cores

[Sergey Kraynev]

Hi Pavlo,

It's really bad to hear such news. However as you said we all stay in
community and I believe, we will meet again! :)
See you in Barcelona, I hope ;)

On 12 September 2016 at 15:35, Pavlo Shchelokovskyy
 wrote:
> Hi Heaters,
>
> with great regret I announce my resignation from the heat-core team.
>
> About a year ago I was reassigned to another project, and despite my best
> efforts I came to conclusion that unfortunately I can not keep up with
> duties expected from Heat core team member in appropriate capacity.
>
> I do still work on OpenStack, so I'm not leaving the community altogether,
> and will be available in e.g. IRC. I also have some ideas left to implement
> in Heat, but, given the great community we've built around the project, I
> could surely make it as an ordinary contributor.
>
> It was an honor to be a member of this team, I’ve learned a lot during this
> time. Hope to see some of you in Barcelona :)
>
> Best regards,
>
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.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
>



-- 
Regards,
Sergey.

__
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] [tc] [heat] [murano] [app-catalog] OpenStack Apps Community, several suggestions how to improve collaboration

[Sergey Kraynev]

Hi Jeremy,
Please see my answers below:

On 31 May 2016 at 19:38, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2016-05-31 19:20:22 +0300 (+0300), Sergey Kraynev wrote:
> [...]
> > * *Second part related with changes with future repositories and*
> > important for Openstack Infra team *
> > JFYI, what we plan to do as next steps.
> >
> > Murano team will re-create some applications in their repositories using
> > name murano-examples, as reference implementation of some of the
> > applications which Murano team decides to keep in their project for
> > reference. This can be done by Murano team, no external help needed.
> >
> > Some of the applications (complicated and big applications like CI/CD
> > pipeline or Kubernetes cluster) will have their own repositories in the
> > future under openstack/. Actually CI/CD pipeline already lives in
> separated
> > repository, probably Kubernetes should be also moved to separated repo
> > going forward. Hopefully this shouldn't be a big deal for OpenStack Infra
> > team.
> > *However* we would like to get confirmation, that *Infra team* is ok with
> > it?
>
> Infra hasn't balked in the past at project teams having however many
> Git repositories they need to be able to effectively maintain their
> software (see configuration management projects for examples of
> fairly large sets of repos). Do you have any guesses as to how many
> you're talking about creating in, say, the next year?
>

>>>  I am happy to hear, that you don't mind about it. We suppose, that the
number of such repositories should not be more then 10. Probably the number
will be about 5-10 repos. I suppose, that it's extremely big number.

>
> > Suggestion is to use common template for names of repositories with
> Murano
> > applications in the future, namely openstack/murano-app-...
> > (openstack/murano-app-kubernetes, openstack/murano-app-docker, ...).
> We'll
> > describe overall approach in more details using
> > https://launchpad.net/murano-apps as entry point.
> >
> > Simple applications or applications where there is no active development
> > will keep being stored in murano-apps until there is a demand to move
> some
> > of them to separated repository. At that point we'll ask OpenStack Infra
> > team to do it.
> [...]
>
> Can you clarify what it is you're going to ask Infra to do? I think
> the things you're describing can be done entirely through
> configuration (you just need some project-config-core reviewers to
> approve the changes you propose), but that might mean I'm
> misunderstanding you.
>

>>> Jeremy, it's some kind of repetition previous words, like: "if we will
decide to move some apps to separate repositories - we will ask infra team
to confirm, that it's ok." So if you agree with this whole idea (sometimes
create new repos for some applications with number mentioned earlier (no
more then 10 per year)), current question may be ignored.

> --
> Jeremy Stanley
>
> __
> 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,
Sergey.
__
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] [tc] [heat] [murano] [app-catalog] OpenStack Apps Community, several suggestions how to improve collaboration

[Sergey Kraynev]

Hi Infra, Murano and App Catalog teams.

We discussed in some more details plan suggested below with App Catalog,
Murano and (partially) Infra team regarding moving repositories with source
code of Murano applications out of area of responsibility of Murano core
team.

* *First part related with changes in existing Murano repository and*
important for Murano App developers *

Decision was made to:
- create new gerrit groups for review/release/test repository, namely -
murano-apps-core
- don't rename murano-apps project and repository, just assign team above
as owners (murano-apps-core)

Previous owner of this project (murano-core) will be part of new group to
continue sharing expertise in Murano with this new team and help them going
forward.

There is patch on review for it: https://review.openstack.org/#/c/323340/3

Separation of murano-apps from Murano is the first step in separating work
with Murano applications from work with Murano core project.

* *Second part related with changes with future repositories and*
important for Openstack Infra team *
JFYI, what we plan to do as next steps.

Murano team will re-create some applications in their repositories using
name murano-examples, as reference implementation of some of the
applications which Murano team decides to keep in their project for
reference. This can be done by Murano team, no external help needed.

Some of the applications (complicated and big applications like CI/CD
pipeline or Kubernetes cluster) will have their own repositories in the
future under openstack/. Actually CI/CD pipeline already lives in separated
repository, probably Kubernetes should be also moved to separated repo
going forward. Hopefully this shouldn't be a big deal for OpenStack Infra
team.
*However* we would like to get confirmation, that *Infra team* is ok with
it?

Suggestion is to use common template for names of repositories with Murano
applications in the future, namely openstack/murano-app-...
(openstack/murano-app-kubernetes, openstack/murano-app-docker, ...). We'll
describe overall approach in more details using
https://launchpad.net/murano-apps as entry point.

Simple applications or applications where there is no active development
will keep being stored in murano-apps until there is a demand to move some
of them to separated repository. At that point we'll ask OpenStack Infra
team to do it.

We hope that this will help to clearly identify area of responsibility
around development of Murano applications, helping to onboard new
contributors/teams using mostly efforts of Murano Apps team. I.e. creation
of new application in murano-apps repository means in this model just
creation of new directory with new application, which can be done by
murano-apps team on their own. In this case we'll need to understand how to
organize CI for different applications being stored in the same repository
but I think we'll figure it out, it's not a blocker.

This model allows us to ask for involvement of OpenStack Infra team only in
rare cases when there is a need to create separate repository for
especially big and complicated Murano Application which should be treated
as a dedicated project with its own development team and CI.


Any suggestions, questions are welcome

On 25 May 2016 at 14:37, Igor Marnat  wrote:

> Colleagues,
> having attended many sessions and talked to many customers, partners
> and contributors in Austin I’d like to suggest several improvements to how
> we develop OpenStack apps and work with the Community App Catalog (
> https://apps.openstack.org/).
>
> Key goals to achieve are:
> - Provide contributors with an ability to collaborate on OpenStack
> apps development
> - Provide contributors and consumers with transparent workflow to
> manage their apps
> - Provide consumers with information about apps - how it was developed
> and tested
> - To summarize - introduce the way to build community working on
> OpenStack apps
>
> *What is OpenStack application*
> OpenStack is about 6 years young and all these years discussions about
> it are in progress. Variety of applications is huge, from LAMP stacks
> and legacy Java apps to telco workloads and VNF apps. There is working
> group which works on a definition of "What is OpenStack application",
> hopefully community will agree on definition soon.
>
> For the sake of our discussion below let us agree on a simple approach:
> an OpenStack application is any software asset which 1. can be executed on
> an OpenStack cloud, 2. lives in apps.openstack.org.  So far there are
> Murano applications, Heat templates, Glance images and TOSCA templates.
>
> There are many good OpenStack applications in the world which don't live
> in OpenStack App Catalog. However, let us for now concentrate on those
> which do, just for the sake of this discussion.
>
> *Introduction to OpenStack development ecosystem*
> OpenStack was introduced about 6 years ago. Over these years
> community grown 

Re: [openstack-dev] [heat] api-ref gate job is active

[Sergey Kraynev]

Hi guys,

just for clarification: do I correctly understand, that now we store all
API related docs in local (Heat) repository and we have not copy of this
staff somewhere else? so we can easily update it ourself and don't push the
same commit to another repository ?

And also library mentioned in patch from Sean allows to build and publish
this doc ? or it does something else?

On 18 May 2016 at 17:23, Sean Dague  wrote:

> On 05/18/2016 09:58 AM, Jay Dobies wrote:
> > Just a quick note that there is a new job active called
> > gate-heat-api-ref. Our API documentation has been pulled into our tree
> > [1] and you can run it locally with `tox -e api-ref`.
> >
> > For now, it's a direct port of our existing API docs, but I'm planning
> > on taking a pass over them to double check that they are still valid.
> > Feel free to ping me if you have any questions/issues.
> >
> > [1] https://review.openstack.org/#/c/312712/
>
> Very cool. I proposed a review which switches over to the extracted
> library today - https://review.openstack.org/#/c/318019/ which passes
> with all your data.
>
> Thanks for digging in so early in this process.
>
> -Sean
>
> --
> Sean Dague
> http://dague.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
>



-- 
Regards,
Sergey.
__
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]informal meetup during summit

[Sergey Kraynev]

I will be there after 15 min
28 апр. 2016 г. 7:14 PM пользователь "Rico Lin" 
написал:

> *Tomorrow 10:00 am at alta's cafe*
>
> See you guys have there:)
>
> http://altascafe.com/
>
> map
> 
> On Apr 25, 2016 8:11 PM, "Steve Baker"  wrote:
>
>> We are now at Terry black's BBQ now for anyone who wants to join usThanks
>> for organising Rico! See you when you get there.
>>
>> - ZB
>>
>>
>> On 22/04/16 20:01, Rico Lin wrote:
>> > Let's settle down on with
>> >
>> > A meet up on Monday night 7:00pm
>> > At continentalclub
>> > <
>> http://www.google.com/url?q=http%3A%2F%2Fcontinentalclub.com=D=1=AFQjCNGirvAgZuZhxVEzHb7bFZU_fShJQw
>> >
>> > address : 1315 S Congress Ave
>> > Austin, TX 78704 http://continentalclub.com
>> > <
>> http://www.google.com/url?q=http%3A%2F%2Fcontinentalclub.com=D=1=AFQjCNGirvAgZuZhxVEzHb7bFZU_fShJQw
>> >
>> > And
>> > Friday morning 10:00 venue:TBD
>> >
>> > Is the time and venue find with everyone?
>> >
>> > Everyone are welcome :)
>> > Feel free to let me know if you're coming, just for easy pre-booking
>> > purpose:)
>> >
>> > On Apr 22, 2016 12:13 AM, "Zane Bitter" > > > wrote:
>> >
>> > On 20/04/16 13:00, Rico Lin wrote:
>> >
>> > Hi team
>> > Let plan for more informal meetup(relax) time! Let all heaters
>> > and any
>> > other projects can have fun and chance for technical discussions
>> > together.
>> >
>> > After discuss in meeting, we will have a pre-meetup-meetup on
>> Friday
>> > morning to have a cup of cafe or some food. Would like to ask if
>> > anyone
>> > knows any nice place for this meetup?:)
>> >
>> >
>> > According to
>> > https://www.openstack.org/summit/austin-2016/guide-to-austin/ if we
>> > line up at Franklin's at 7am then we can be eating barbeque by 11
>> > and still make it back in time for the afternoon meetup :))
>> >
>> > Also open for other chance for all can go out for a nice dinner
>> and
>> > beer. Right now seems maybe Monday or Friday night could be the
>> best
>> > candidate for this wonderful task, what all think about this? :)
>> >
>> >
>> > +1. I'll be around on Friday, but I imagine a few people will be
>> > leaving so Monday is probably better.
>> >
>> > cheers,
>> > Zane.
>> >
>> >
>>  __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > <
>> http://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
>
>
__
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] Issue with validation and preview due to get_attr==None

[Sergey Kraynev]

Zane, I like you idea. As example we may discuss some steps for it
during summit session (if it need).

Also I have another question, which probably came in your heads a lot of times:
Can we somekind improve our existing approach for validation?
we do validation twice - before create and during it.
The one issue, which I also see is:
first validation is a synchronous operation, and It takes a lot of
time, for huge stacks. May be we need to make separate state like
validation for stacks ? and maybe it also allows to solve our current
issue with build-in functions ?

On 23 March 2016 at 23:11, Zane Bitter  wrote:
> On 23/03/16 13:14, Steven Hardy wrote:
>>
>> Hi all,
>>
>> I'm looking for some help and additional input on this bug:
>>
>> https://bugs.launchpad.net/heat/+bug/1559807
>
>
> Hmm, I was wondering how this ever worked, but it appears you're making
> particularly aggressive use of the list_join and map_merge Functions there -
> where you're not only getting the elements in the list of things to merge
> (as presumably originally envisioned) but actually getting the list itself
> from an intrinsic function. If we're going to support that then those
> functions need to handle the fact that the input argument may be None, just
> as they do for the list members (see the ensure_string() and ensure_map()
> functions inside the result() methods of those two Functions).
>
>
>> Basically, we have multiple issues due to the fact that we consider
>> get_attr to resolve to None at any point before a resource is actually
>> instantiated.
>>
>> It's due to this:
>>
>>
>> https://github.com/openstack/heat/blob/master/heat/engine/hot/functions.py#L163
>>
>> This then causes problems during validation of several intrinsic
>> functions,
>> because if they reference get_attr, they have to contain hacks and
>> special-cases to work around the validate-time None value (or, as reported
>> in the bug, fail to validate when all would be fine at runtime).
>>
>>
>> https://github.com/openstack/heat/blob/master/heat/engine/resource.py#L1333
>>
>> I started digging into fixes, and there are probably a few possible
>> approaches, e.g setting stack.Stack.strict_validate always to False, or
>> reworking the intrinsic function validation to always work with the
>> temporary None value.
>>
>> However, it's a more widespread issue than just validation - this affects
>> any action which happens before the actual stack gets created, so things
>> like preview updates are also broken, e.g consider this:
>>
>> resources:
>>random:
>>  type: OS::Heat::RandomString
>>
>>config:
>>  type: OS::Heat::StructuredConfig
>>  properties:
>>group: script
>>config:
>>  foo: {get_attr: [random, value]}
>>
>>deployment:
>>  type: OS::Heat::StructuredDeployment
>>  properties:
>>config:
>>  get_resource: config
>>server: "dummy"
>>
>> On update, nothing is replaced, but if you do e.g:
>>
>>heat stack-update -x --dry-run
>>
>> You see this:
>>
>> | replaced  | config| OS::Heat::StructuredConfig |
>>
>> Which occurs due to the false comparison between the current value of
>> "random" and the None value we get from get_attr in the temporary stack
>> used for preview comparison:
>>
>> https://github.com/openstack/heat/blob/master/heat/engine/resource.py#L528
>>
>> after_props.get(key) returns None, which makes us falsely declare the
>> "config" resource gets replaced :(
>>
>> I'm looking for ideas on how we solve this - it's clearly a major issue
>> which completely invalidates the results of validate and preview
>> operations
>> in many cases.
>
>
> I've been thinking about this (for about 2 years).
>
> My first thought (it seemed like a good idea at the time, 2 years ago, for
> some reason) was for Function objects themselves to take on the types of
> their return values, so e.g. a Function returning a list would have a
> __getitem__ method and generally act like a list. Don't try this at home,
> BTW, it doesn't work.
>
> I now think the right answer is to return some placeholder object (but not
> None). Then the validating code can detect the placeholder and do some
> checks. e.g. we would be able to say that the placeholder for get_resource
> on a Cinder volume would have type 'cinder.volume' and any property with a
> custom constraint would check that type to see if it matches (and fall back
> to accepting any text type if the placeholder doesn't have a type
> associated). get_param would get its type from the parameter schema
> (including any custom constraints). For get_attr we could make it part of
> the attribute schema.
>
> The hard part obviously would be getting this to work with deeply-nested
> trees of data and across nested stacks. We could probably get the easy parts
> going and incrementally improve from there though. Worst case we just return
> None and get the same behaviour as now.
>
> cheers,
> Zane.
>
>
> 

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

[Sergey Kraynev]

Rabi,

Good point. I suppose, that the root cause of it is gap in our documentation.
Unfortunately I can not find any clear description what's the
differences or how it should work (especially with examples) in our
documentation. [1]

May be we need to improve it by adding more examples ?

[1] 
http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#get-attr

On 24 March 2016 at 08:39, Rabi Mishra <ramis...@redhat.com> wrote:
>> On Wed, Mar 23, 2016 at 05:25:57PM +0300, Sergey Kraynev wrote:
>> >Hello,
>> >It looks similar on issue, which was discussed here [1]
>> >I suppose, that the root cause is incorrect using get_attr for your
>> >case.
>> >Probably you got "list"  instead of "string".
>> >F.e. if I do something similar:
>> >outputs:
>> >  rg_1:
>> >value: {get_attr: [rg_a, rg_a_public_ip]}
>> >  rg_2:
>> >value: {get_attr: [rg_a, rg_a_public_ip, 0]}
>> >
>> >  rg_3:
>> >value: {get_attr: [rg_a]}
>> >  rg_4:
>> >value: {get_attr: [rg_a, resource.0.rg_a_public_ip]}
>> >where rg_a is also resource group which uses custom template as
>> >resource.
>> >the custom template has output value rg_a_public_ip.
>> >The output for it looks like [2]
>> >So as you can see, that in first case (like it is used in your example),
>> >get_attr returns list with one element.
>> >rg_2 is also wrong, because it takes first symbol from sting with IP
>> >address.
>>
>> Shouldn't rg_2 and rg_4 be equivalent?
>
> They are the same for template version 2013-05-23. However, they behave 
> differently
> from the next  version(2014-10-16) onward and return a list of characters. I 
> think
> this is due to the fact that `get_attr` function mapping is changed from 
> 2014-10-16.
>
>
> 2013-05-23 -  
> https://github.com/openstack/heat/blob/master/heat/engine/hot/template.py#L70
> 2014-10-16 -  
> https://github.com/openstack/heat/blob/master/heat/engine/hot/template.py#L291
>
> This makes me wonder why would a template author do something like
> {get_attr: [rg_a, rg_a_public_ip, 0]} when he can easily do
> {get_attr: [rg_a, resource.0.rg_a_public_ip]} or {get_attr: [rg_a, 
> resource.0, rg_a_public_ip]}
> for specific resource atrributes.
>
> I understand that {get_attr: [rg_a, rg_a_public_ip]} cane be useful when we 
> just want to use
> the list of attributes.
>
>
>>
>> {get_attr: [rg_a, rg_a_public_ip]} should return a list of all
>> rg_a_public_ip attributes (one list item for each resource in the group),
>> then the 0 should select the first item from that list?
>>
>> If it's returning the first character of the first element, that sounds
>> like a bug to me?
>>
>> Steve
>>
>> __
>> 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



-- 
Regards,
Sergey.

__
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] issue of ResourceGroup in Heat template

[Sergey Kraynev]

Steven,

Honestly I thought about it, but I am not sure, which behavior was
before for both. I don't mind if we create such bug and investigate
the root cause (unfortunately I had not time to do it yet).
The my main point was to provide workable way for mentioned issue.

p.s. there is corresponding bug was created
https://bugs.launchpad.net/heat/+bug/1561157

On 23 March 2016 at 20:35, Steven Hardy <sha...@redhat.com> wrote:
> On Wed, Mar 23, 2016 at 05:25:57PM +0300, Sergey Kraynev wrote:
>>Hello,
>>It looks similar on issue, which was discussed here [1]
>>I suppose, that the root cause is incorrect using get_attr for your case.
>>Probably you got "list"  instead of "string".
>>F.e. if I do something similar:
>>outputs:
>>  rg_1:
>>value: {get_attr: [rg_a, rg_a_public_ip]}
>>  rg_2:
>>value: {get_attr: [rg_a, rg_a_public_ip, 0]}
>>
>>  rg_3:
>>value: {get_attr: [rg_a]}
>>  rg_4:
>>value: {get_attr: [rg_a, resource.0.rg_a_public_ip]}
>>where rg_a is also resource group which uses custom template as resource.
>>the custom template has output value rg_a_public_ip.
>>The output for it looks like [2]
>>So as you can see, that in first case (like it is used in your example),
>>get_attr returns list with one element.
>>rg_2 is also wrong, because it takes first symbol from sting with IP
>>address.
>
> Shouldn't rg_2 and rg_4 be equivalent?
>
> {get_attr: [rg_a, rg_a_public_ip]} should return a list of all
> rg_a_public_ip attributes (one list item for each resource in the group),
> then the 0 should select the first item from that list?
>
> If it's returning the first character of the first element, that sounds
> like a bug to me?
>
> Steve
>
> __
> 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,
Sergey.

__
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] issue of ResourceGroup in Heat template

[Sergey Kraynev]

Hello,

It looks similar on issue, which was discussed here [1]
I suppose, that the root cause is incorrect using get_attr for your case.
Probably you got "list"  instead of "string".
F.e. if I do something similar:


outputs:

  rg_1:

value: {get_attr: [rg_a, rg_a_public_ip]}

  rg_2:

value: {get_attr: [rg_a, rg_a_public_ip, 0]}

  rg_3:

value: {get_attr: [rg_a]}

  rg_4:

value: {get_attr: [rg_a, resource.0.rg_a_public_ip]}

where rg_a is also resource group which uses custom template as resource.
the custom template has output value rg_a_public_ip.

The output for it looks like [2]

So as you can see, that in first case (like it is used in your example),
get_attr returns list with one element.
rg_2 is also wrong, because it takes first symbol from sting with IP
address.
rg_3 - does not work at all  (because it's custom template resource)
the right way is rg_4, which returns IP address string .

[1]
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg77526.html

[2] http://paste.openstack.org/show/491587/

On 23 March 2016 at 14:15, Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <
wentao...@hpe.com> wrote:

>
>
> Hi Sergey,
>
> Here is our tracked logs. we can notice that  kube_master resource can
> return the output value "kube_master_ip": "10.101.58.117"  , but It
> can’t  get the kube_master_ip value in kube_minions of
> *kubecluster-fedora-ironic.yaml.*
>
> I found about this heat template composition configuration at
> https://ask.openstack.org/en/question/56988/get-outputs-from-nested-stack/
> . It is same with us.
>
> *#heat resource-list --nested-depth 5 cf0e4e53-e703-4d78-b2e3-90c7081c39fe*
>
>
> +---+--++-+-+-+
>
> | resource_name | physical_resource_id |
> resource_type
> | resource_status | updated_time|
> stack_name  |
>
>
> +---+--++-+-+-+
>
> | kube_master   | 65d68ca7-6629-4203-b40b-359f53be8c79 |
> OS::Heat::ResourceGroup
> | CREATE_COMPLETE | 2016-03-23T18:12:44 |
> k8sbay-rzqvufyi24q5 |
>
> | kube_minions  | 9a3d3d0c-104e-4887-9961-f4d6b6dc392f |
> OS::Heat::ResourceGroup
> | CREATE_FAILED   | 2016-03-23T18:12:44 |
> k8sbay-rzqvufyi24q5 |
>
>
> +---+--++-+-+-+
>
>
>
> *#heat resource-show 65d68ca7-6629-4203-b40b-359f53be8c79 0*
>
>
> ++--+
>
> | Property   |
> Value
>   
>  |
>
>
> ++--+
>
> | attributes |
> {
> |
>
> ||   "kube_master_external_ip":
> "10.101.58.117",
> |
>
> ||   "kube_master_ip": "10.101.58.117"
>   
>  |
>
> ||
> }
>
> |
>
> …
>
> | resource_status|
> CREATE_COMPLETE
> |
>
>
> ++--+
>
>
>
>
>
> *Here is the three k8s heat yaml file.*
>
> *kubecluster-fedora-ironic.yaml*
>
> kube_master:
>
> type: OS::Heat::ResourceGroup
>
> properties:
>
>   count: 1
>
>   resource_def:
>
> type: kubemaster-fedora-ironic.yaml
>
> properties:
>
>   ssh_key_name: {get_param: ssh_key_name}
>
>   server_image: {get_param: server_image}
>
>   …
>
>
>
> kube_minions:
>
> type: OS::Heat::ResourceGroup
>
> depends_on:
>
>   - kube_master
>
> properties:
>
>   count: {get_param: number_of_minions}
>
>   removal_policies: [{resource_list: {get_param: minions_to_remove}}]
>
>   resource_def:
>
> type: 

Re: [openstack-dev] 答复: [Heat] Nomination Oleksii Chuprykov to Heat core reviewer

[Sergey Kraynev]

Looks like it was unanimously decision :)
Oleksii, my congratulations !
Good work. I will add you to necessary groups ;)

On 17 March 2016 at 04:34, Huangtianhua <huangtian...@huawei.com> wrote:
> +1 ：）
>
> -邮件原件-
> 发件人: Sergey Kraynev [mailto:skray...@mirantis.com]
> 发送时间: 2016年3月16日 18:58
> 收件人: OpenStack Development Mailing List (not for usage questions)
> 主题: [openstack-dev] [Heat] Nomination Oleksii Chuprykov to Heat core reviewer
>
> Hi Heaters,
>
> The Mitaka release is close to finish, so it's good time for reviewing 
> results of work.
> One of this results is analyze contribution results for the last release 
> cycle.
> According to the data [1] we have one good candidate for nomination to 
> core-review team:
> Oleksii Chuprykov.
> During this release he showed significant value of review metric.
> His review were valuable and useful. Also He has enough level of expertise in 
> Heat code.
> So I think he is worthy to join to core-reviewers team.
>
> I ask you to vote and decide his destiny.
>  +1 - if you agree with his candidature
>  -1  - if you disagree with his candidature
>
> [1] http://stackalytics.com/report/contribution/heat-group/120
>
> --
> Regards,
> Sergey.
>
> __
> 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



-- 
Regards,
Sergey.

__
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][Neutron] Mitaka RC1 available

[Sergey Kraynev]

On 16 March 2016 at 20:15, Thierry Carrez  wrote:
> Hello everyone,
>
> Heat and Neutron just produced a release candidate for the end of the Mitaka
> cycle! You can find their RC1 source code tarballs at:

Heat team also plan to cut RC2 on the week.

>
> https://tarballs.openstack.org/heat/heat-6.0.0.0rc1.tar.gz
>
> https://tarballs.openstack.org/neutron/neutron-8.0.0.0rc1.tar.gz
> https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-8.0.0.0rc1.tar.gz
> https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-8.0.0.0rc1.tar.gz
> https://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-8.0.0.0rc1.tar.gz
>
> Unless release-critical issues are found that warrant a release candidate
> respin, these RC1s will be formally released as the final Mitaka releases on
> April 7th. You are therefore strongly encouraged to test and validate these
> tarballs !
>
> Alternatively, you can directly test the stable/mitaka release branches at:
>
> http://git.openstack.org/cgit/openstack/heat/log/?h=stable/mitaka
>
> http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/mitaka
> http://git.openstack.org/cgit/openstack/neutron-lbaas/log/?h=stable/mitaka
> http://git.openstack.org/cgit/openstack/neutron-fwaas/log/?h=stable/mitaka
> http://git.openstack.org/cgit/openstack/neutron-vpnaas/log/?h=stable/mitaka
>
> If you find an issue that could be considered release-critical, please
> file it at:
>
> https://bugs.launchpad.net/heat/+filebug
> or
> https://bugs.launchpad.net/neutron/+filebug
>
> and tag it *mitaka-rc-potential* to bring it to the release crew's
> attention.
>
> Note that the "master" branches of Heat and Neutron are now open for Newton
> development, and feature freeze restrictions no longer apply there !
>
>
> Regards,
>
> --
> 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



-- 
Regards,
Sergey.

__
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] [Heat] Nomination Oleksii Chuprykov to Heat core reviewer

[Sergey Kraynev]

Hi Heaters,

The Mitaka release is close to finish, so it's good time for reviewing
results of work.
One of this results is analyze contribution results for the last release cycle.
According to the data [1] we have one good candidate for nomination to
core-review team:
Oleksii Chuprykov.
During this release he showed significant value of review metric.
His review were valuable and useful. Also He has enough level of
expertise in Heat code.
So I think he is worthy to join to core-reviewers team.

I ask you to vote and decide his destiny.
 +1 - if you agree with his candidature
 -1  - if you disagree with his candidature

[1] http://stackalytics.com/report/contribution/heat-group/120

-- 
Regards,
Sergey.

__
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] issue of ResourceGroup in Heat template

[Sergey Kraynev]

Hi Gary,

I have tried your template and it works for me correctly. Note, that I
used private network (because my servers have not any public IP in
template).

So your issue looks like a strange bug, because I can not reproduce it.
Could you share traceback if your error and also provide information
about Heat version. Please create new bug with all this data and ping
us to review it.

On 11 March 2016 at 08:25, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
<li-gong.d...@hpe.com> wrote:
> Hi Sergey,
>
> Thanks for your reply.
>
> Thanks for your pointing out that "depends_on" is not needed when we have 
> already used "get_attr".

So as Zane pointed, when we use get_attr it's expected, that we start
create rg_b, when rg_a will be finally completed/created , because all
information (in your case it's attributes) will be available after
creation of rg_a.

In heat we have two types of dependencies explicit and implicit. So
implicit dependencies will be created with using some Heat intrinsic
functions. Depends_on add explicit dependency. All these dependencies
work in the same way, depended resource will be created, when all his
dependencies be resolved (created).

>
>>you create in rg_a some Server and probably it goes to active state before ip 
>>address becomes available for get_attr. It is necessary to check, but if it's 
>>try to add wait condition for this resource, then you will get created rg_a 
>>with fully available resources and I suppose IP will be available
>
> Do you mean that with "depends_on" functionalities, Heat will launch another 
> resource group(in my case, "rg_b") as soon as the server in "rg_a" becomes 
> "active" state?
> Actually, in my real program code, there is  a wait condition, but it is 
> located in the server template, not Resource group(in my case, it is 
> "b.yaml), which is like:
> --
> rg_a_wc_notify:
> type: OS::Heat::SoftwareConfig
> properties:
>   group: ungrouped
>   config:
> str_replace:
>   template: |
> #!/bin/bash -v
> wc_notify --data-binary '{"status": "SUCCESS"}'
>   params:
> wc_notify: {get_attr: [master_wait_handle, curl_cli]}
> --
> Is it the wait condition which you mentioned in " but if it's try to add wait 
> condition for this resource"? or you want this wait condition to be added to 
> "a.yaml"(the template declaring resource group)?
>
> And as per my observation, only after Heat receives the signal of "SUCCESS", 
> then it try to begin launch "rg_b"(my another server in another resource 
> group).
>
> I am wondering whether there is a chance that, the "IP" information is 
> available but Heat doesn't try to get it until the creation of the 2 resource 
> groups(rg_a and rg_b) is completed?



>
> Regards,
> Gary
>
> -Original Message-
> From: Sergey Kraynev [mailto:skray...@mirantis.com]
> Sent: Wednesday, March 09, 2016 6:42 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template
>
> Hi Gary,
>
>
> First of all you don't need to use "depends_on", because using "get_attr" 
> already create implicit dependency from rg_a.
> About getting Null instead of real Ip address:
> It sounds like a bug, but IMO, it's expected behavior, because I suppose it 
> happens due to:
>  - you create in rg_a some Server and probably it goes to active state before 
> ip address becomes available for get_attr. It is necessary to check, but if 
> it's try to add wait condition for this resource, then you will get created 
> rg_a with fully available resources and I suppose IP will be available.
>
> On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
> <li-gong.d...@hpe.com> wrote:
>> Hi,
>>
>>
>>
>> I have 3 Heat templates using ResourceGroup. There are 2 resource
>> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires the
>> IP address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip: 
>> {get_attr:
>> [rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the
>> section of rg_b parameters (rg_b/properties/resource_def/properties)
>> and the section of outputs.
>>
>> As per my observation,  rg_a_public_ip shows “null” in the parameter
>> section of rg_b. while rg_a_public_ip shows the correct IP address in
>> the outputs section of the yaml file.
>>
>>
>>
>> My questions are:
>>
>> 1)  Does this behavior is expected as des

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Sergey Kraynev]

Hi, Doug

Heat team is agree to use python-heatclient == 1.0.0 for creating stable branch

On 9 March 2016 at 20:26, Doug Hellmann  wrote:
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
>
> __
> 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,
Sergey.

__
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] issue of ResourceGroup in Heat template

[Sergey Kraynev]

Hi Gary,


First of all you don't need to use "depends_on", because using
"get_attr" already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I
suppose it happens due to:
 - you create in rg_a some Server and probably it goes to active state
before ip address becomes available for get_attr. It is necessary to
check, but if it's try to add wait condition for this resource, then
you will get created rg_a with fully available resources and I suppose
IP will be available.

On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
 wrote:
> Hi,
>
>
>
> I have 3 Heat templates using ResourceGroup. There are 2 resource
> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires the IP
> address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip: {get_attr:
> [rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the section
> of rg_b parameters (rg_b/properties/resource_def/properties) and the section
> of outputs.
>
> As per my observation,  rg_a_public_ip shows “null” in the parameter section
> of rg_b. while rg_a_public_ip shows the correct IP address in the outputs
> section of the yaml file.
>
>
>
> My questions are:
>
> 1)  Does this behavior is expected as designed or this is a bug?
>
> 2)  What is the alternative solution for the above case(user want to get
> the run-time information of the instance when creating the second resource
> group)  if this behavior is expected?
>
>
>
> --- a.yaml ---
>
> resources:
>
> rg_a:
>
>   type: OS::Heat::ResourceGroup
>
>   properties:
>
>   count: 1
>
>   resource_def:
>
>   type: b.yaml
>
>   properties:
>
>…
>
>
>
> rg_b:
>
> type: OS::Heat::ResourceGroup
>
> depends_on:
>
> -rg_a
>
> properties:
>
> count: 2
>
> resource_def:
>
> type: c.yaml
>
> properties:
>
> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>   the value is “null”
>
> …
>
>
>
> outputs:
>
>rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
> -  the value is correct.
>
> --
>
>
>
> --b.yaml  
>
> …
>
> resources:
>
> rg_a:
>
> type: OS::Nova::Server
>
> properties:
>
>  …
>
> outputs:
>
>  rg_a_public_ip:
>
>  value: {get_attr: [rg_a, networks, public, 0]}
>
> --
>
>
>
> -- c.yaml 
>
> parameters:
>
> rg_a_public_ip:
>
>  type: string
>
>  description: IP of rg_a
>
> …
>
> resources:
>
> rg_b:
>
> type: OS::Nova::Server
>
> properties:
>
>  …
>
> outputs:
>
>  …
>
> ---
>
>
>
> Regards,
>
> Gary
>
>
>
>
> __
> 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,
Sergey.

__
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][release] Release countdown for week R-4, Mar 7 - 11

[Sergey Kraynev]

Hi Doug.

I have one question related with last item: "Release actions".
Who will prepare patches for Reno and for updating .gitreview?
Should it be done by related project team or it will be done by someone else?

On 5 March 2016 at 02:01, Doug Hellmann  wrote:
> The Mitaka 3 milestone has passed, and we're on our way to preparing
> release candidates. See Thierry's email [1] for details about the
> artifacts produced for the milestone.
>
> [1] 
> http://lists.openstack.org/pipermail/openstack-announce/2016-March/001002.html
>
> Focus
> -
>
> Project teams should be concentrating on finishing work for which
> a feature freeze exception (FFE) was granted, and fixing release-critical
> bugs before preparing the release candidates during week R-3. Any
> FFE work not completed this week should be postponed to the next
> cycle.
>
> General Notes
> -
>
> The global requirements list is frozen. If you need to change a
> dependency, for example to include a bug fix in one of our libraries
> or an upstream library, please provide enough detail in the change
> request to allow the requirements review team to evaluate the change.
>
> User-facing strings are frozen to allow the translation team time
> to finish their work.
>
> Release Actions
> ---
>
> The stable/mitaka branches for libraries will be created early
> during R-4. After the branch is created, a patch will be submitted
> to update the .gitreview file. If the project uses reno, another
> patch will be submitted on master to add a mitaka-specific page to
> the reno build.  Please watch for those patches and prioritize
> reviewing them.
>
> Important Dates
> ---
>
> RC Target Week: R-3, Mar 14-18
>
> Mitaka release schedule: http://releases.openstack.org/mitaka/schedule.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



-- 
Regards,
Sergey.

__
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] [Heat] Release of M3 milestone and FFE for rc-1

[Sergey Kraynev]

Hi all.

I want to inform all, that mitaka-3 milestone was recently released:
https://review.openstack.org/#/c/284198/

So now we are going to prepare mitaka-rc1.
This milestone has one Feature Freeze Exception:
https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport

For this BP we still has not merged Functional test:
https://review.openstack.org/#/c/237608/

and patch for release notes:

https://review.openstack.org/#/c/287271/

Also BP:
https://blueprints.launchpad.net/heat/+spec/sfc-heat

was moved to newton-1, because it has some comments for each patch and I'd
like to minimize risk of going out of time before rc-1.

-- 
Regards,
Sergey.
__
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] [heat] Heat Convergence in Mitaka/Newton status and plans

[Sergey Kraynev]

Hi all,

I want to share results of the last Heat meeting, where we discussed
"convergence" status.
"Convergence" feature still has some issues, which prevent enabling
"convergence" engine by default. Some of them were found on TripleO during
manual deploying.
Also there are valuable numbers of related patches [1]

The final solution for Mitaka is saving "convergence"  feature in
experimental status and ready for deep, thorough testing.
So if somebody wants to try/test 'convergence' stuff, it's the best moment
for it.
However it's not recommended for production clouds.

In Newton release Heat team plans to enable this feature on the most part
of gate jobs (e.g. TripleO ha job).
After 1 month of execution jobs with enabled "convergence" and positive
results (low rate or equal 0 happening errors), feature will be enabled by
default.


[1]
https://review.openstack.org/#/q/message:Convergence++project:openstack/heat+status:open+branch:master

-- 
Regards,
Sergey.
__
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] [heat] re-ask about Global OpenStack Bug Smash Mitaka

[Sergey Kraynev]

Hi Heaters.

I want to attract your attention on mail [1] about Bug Smash Day and ask
question related with it:
Does anybody plan to visit Moscow during this event?
If yes, we can meet there and work together :)

It will be really cool to create group of people in different locations and
discuss some important bugs/changes.

P.S. I will try  to communicate constantly with each group in other places
too.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-January/085196.html

-- 
Regards,
Sergey.
__
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] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

[Sergey Kraynev]

Sean, thank you for the spotting.

Martinx, According to the information mentioned by Sean, we unfortunately
can not do it :(

On 29 January 2016 at 10:45, Sean M. Collins  wrote:

> Kilo is in the "security supported" stage of the lifecycle. So no,
> that's not going to get backported.
>
> http://docs.openstack.org/releases/index.html
> --
> Sean M. Collins
>
> __
> 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,
Sergey.
__
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] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

[Sergey Kraynev]

I see ,that it has a assigned bug. So we can process it as normal backport
(although it looks as a small enhancement). So Please just propose patch
and we will review it.

On 28 January 2016 at 23:45, Martinx - ジェームズ 
wrote:

> Guys,
>
>  This is important and Kilo is missing it:
>
>  https://review.openstack.org/#/c/179989/
>
>  Is it possible to backport it to Kilo 2015.1.3?
>
>  Currently, I am manually patching Kilo / Heat by using the following diff:
>
>
> https://review.openstack.org/gitweb?p=openstack%2Fheat.git;a=commitdiff;h=811c8714aa2442e68980561d3e8dd435378f164c
>
>  But it is a pain to maintain...
>
> Thanks!
> Thiago
>
> __
> 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,
Sergey.
__
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] spec-lite for simple feature requests

[Sergey Kraynev]

+1 from my side. I agree with this idea.

There is only one question from my side, which IMO we should  describe in
documentation:

Do we need to upload release-notes for such small features?
My guess is  - Yes. I'd like to know what other guys think about it.

On 20 January 2016 at 18:21, Rabi Mishra  wrote:

> Hi All,
>
> As discussed in the team meeting, below is the proposed spec-lite process
> for simple feature requests. This is already being used in Glance project.
> Feedback/comments/concerns are welcome, before we update the contributor
> docs with this:).
>
>
> tl;dr - spec-lite is a simple feature request created as a bug with enough
> details and with a `spec-lite` tag. Once triaged with status 'Triaged' and
> importance changed to 'Whishlist', it's approved. Status 'Won’t fix'
> signifies the request is rejected and 'Invalid' means it would require a
> full spec.
>
>
> Heat Spec Lite
> --
>
> Lite specs are small feature requests tracked as Launchpad bugs, with
> status 'Wishlist' and tagged with 'spec-lite' tag. These allow for
> submission and review of these feature requests before code is submitted.
>
> These can be used for simple features that don’t warrant a detailed spec
> to be proposed, evaluated, and worked on. The team evaluates these requests
> as it evaluates specs. Once a bug has been approved as a Request for
> Enhancement (RFE), it’ll be targeted for a release.
>
>
> The workflow for the life of a spec-lite in Launchpad is as follows:
>
> 1. File a bug with a small summary of what the request change is and tag
> it as spec-lite.
> 2. The bug is triaged and importance changed to Wishlist.
> 3. The bug is evaluated and marked as Triaged to announce approval or to
> Won’t fix to announce rejection or Invalid to request a full spec.
> 4. The bug is moved to In Progress once the code is up and ready to review.
> 5. The bug is moved to Fix Committed once the patch lands.
>
> In summary the states are:
>
> New:This is where spec-lite starts, as filed by the community.
> Triaged:Drivers - Move to this state to mean, “you can start
> working on it”
> Won’t Fix:  Drivers - Move to this state to reject a lite-spec.
> Invalid:Drivers - Move to this state to request a full spec for
> this request
>
> Lite spec Submission Guidelines
> ---
>
> When a bug is submitted, there are two fields that must be filled:
> ‘summary’ and ‘further information’. The ‘summary’ must be brief enough to
> fit in one line.
>
> The ‘further information’ section must be a description of what you would
> like to see implemented in heat. The description should provide enough
> details for a knowledgeable developer to understand what is the existing
> problem and what’s the proposed solution.
>
> Add spec-lite tag to the bug.
>
>
> Thanks,
> Rabi
>
> __
> 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,
Sergey.
__
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] spec-lite for simple feature requests

[Sergey Kraynev]

On 21 January 2016 at 05:57, Rico Lin  wrote:

> +1
>
> And how everyone think about if we deprecate to use Blueprint in Launchpad
> and use bug system instead?
>

Rico, I am not sure, that it will be really useful.
It's obvious, that we may track progress by reno + launchpad bugs.
However, it also has negative effects:
 - you need to add Partial-Bug for each patch which corresponds this bug
(feature).
 - and of course use Closes-Bug, when it be finished.
 - it's really difficult to find differences between real bug and BP during
release.
"Wishlist" status partially solves this issue, but it leads us to
situation, when we have a lot of "Whishlist" bugs, where can be real bugs
(not only features).
 - again it's more difficult for tracking status of feature  (you need to
list whole comments history for understanding list of all related patches,
while in BP all patches with necessary tag presented in short list :) )

May be I am a bit  skeptical, but I think, that we are not ready for this
step right now.


> If this make more sense, we can move all spec to bug system, lite or not.
> I have saw Ironic and some other project discuss about doing it. Most of
> the reason is they think Launchpad bug system + reno release note can
> already cover Launchpad Blueprint system.
>
> 2016-01-21 6:31 GMT+08:00 Steve Baker :
>
>> On 21/01/16 04:21, Rabi Mishra wrote:
>>
>> Hi All,
>>
>> As discussed in the team meeting, below is the proposed spec-lite process 
>> for simple feature requests. This is already being used in Glance project. 
>> Feedback/comments/concerns are welcome, before we update the contributor 
>> docs with this:).
>>
>>
>> tl;dr - spec-lite is a simple feature request created as a bug with enough 
>> details and with a `spec-lite` tag. Once triaged with status 'Triaged' and 
>> importance changed to 'Whishlist', it's approved. Status 'Won’t fix' 
>> signifies the request is rejected and 'Invalid' means it would require a 
>> full spec.
>>
>>
>> Heat Spec Lite
>> --
>>
>> Lite specs are small feature requests tracked as Launchpad bugs, with status 
>> 'Wishlist' and tagged with 'spec-lite' tag. These allow for submission and 
>> review of these feature requests before code is submitted.
>>
>> These can be used for simple features that don’t warrant a detailed spec to 
>> be proposed, evaluated, and worked on. The team evaluates these requests as 
>> it evaluates specs. Once a bug has been approved as a Request for 
>> Enhancement (RFE), it’ll be targeted for a release.
>>
>>
>> The workflow for the life of a spec-lite in Launchpad is as follows:
>>
>> 1. File a bug with a small summary of what the request change is and tag it 
>> as spec-lite.
>> 2. The bug is triaged and importance changed to Wishlist.
>> 3. The bug is evaluated and marked as Triaged to announce approval or to 
>> Won’t fix to announce rejection or Invalid to request a full spec.
>> 4. The bug is moved to In Progress once the code is up and ready to review.
>> 5. The bug is moved to Fix Committed once the patch lands.
>>
>> In summary the states are:
>>
>> New: This is where spec-lite starts, as filed by the community.
>> Triaged: Drivers - Move to this state to mean, “you can start working on 
>> it”
>> Won’t Fix:   Drivers - Move to this state to reject a lite-spec.
>> Invalid:Drivers - Move to this state to request a full spec for this 
>> request
>>
>> Lite spec Submission Guidelines
>> ---
>>
>> When a bug is submitted, there are two fields that must be filled: ‘summary’ 
>> and ‘further information’. The ‘summary’ must be brief enough to fit in one 
>> line.
>>
>> The ‘further information’ section must be a description of what you would 
>> like to see implemented in heat. The description should provide enough 
>> details for a knowledgeable developer to understand what is the existing 
>> problem and what’s the proposed solution.
>>
>> Add spec-lite tag to the bug.
>>
>>
>> Thanks,
>> Rabi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> +1, this sounds useful for small features.
>>
>> __
>> 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,
>
> *Rico Lin*
> 
> 迎棧科技股份有限公司
> │ 886-963-612-021
> │ ric...@inwinstack.com
> │ 886-2-7738-6804 #7754
> │ 新北市220板橋區遠東路3號5樓C室
> Rm.C, 5F., No.3, Yuandong Rd.,
> Banqiao Dist., New Taipei City 220, Taiwan (R.O.C)
>
>
> 

Re: [openstack-dev] [heat] Convergence status

[Sergey Kraynev]

Anant, thank you for the summary.

I planned to announce it (enabling convergence by default) on the next week
(after m-2).
I think, that we need to land two first mentioned patches before it ^.


On 19 January 2016 at 09:44, Anant Patil  wrote:

>
> Hi,
>
> This is to discuss the status of convergence patches and plans for
> making it default.
>
> The convergence gate jobs have been running successfully since more than
> a month now. There were three integration tests skipped:
> 1. StackValidationTest
> 2. UpdateStackTest.test_stack_update_alias_type
> 3. UpdateStackTest.test_stack_update_alias_changes
>
> 2 and 3 of above are addressed by patches and have been running
> successfully:
> https://review.openstack.org/#/c/248676/
> https://review.openstack.org/#/c/259865/
>
> The StackValidationTest fails because the test uses an image without
> cfn-tools and convergence heat will wait for the signal to arrive.
> https://bugs.launchpad.net/heat/+bug/1486281/comments/3 . This should be
> fixed when we address https://bugs.launchpad.net/heat/+bug/1533176 . The
> delete request can cancel the currently running check-resource requests
> and it can then proceed without having to wait for resources to
> complete. Also, if we use a proper image, this is is not seen.
>
> There are few important patches in review which should close most of the
> bugs:
> https://review.openstack.org/#/c/264748/
> https://review.openstack.org/#/c/262374/
> https://review.openstack.org/#/c/261208/
> https://review.openstack.org/#/c/264675/
> https://review.openstack.org/#/c/208790/
>
> There are other bugs for which the patches should land soon. We should
> plan to make convergence default earlier in m-3 phase so that we can
> thoroughly test it before release. Let me know your opinion on this.
>
> - Anant
>
> __
> 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,
Sergey.
__
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] [heat] cancel IRC meeting for 30 Dec

[Sergey Kraynev]

Hi, Heaters.

I'd suggest to cancel tomorrow meeting (30 Dec 2015).
The experience of previous meeting showed, that the most part of Heat team
is on holidays/vacations. more over I don't think, that we have some useful
updates after Christmas :)

If somebody have a really important reason do not do it, please contact
with me or sent answer in this mail thread. (Then I will lead it :) )

Congratulate all with future New Year celebration :)

-- 
Regards,
Sergey.
__
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][telemetry] gate-ceilometer-dsvm-integration broken

[Sergey Kraynev]

Hi, Julien.

I suppose, that your guess is right.
Mentioned patch was merged recently and it broke our Ceilometer related
functional test.
There is a patch, which skip it. [1] and related bug [2]

We already have a revert for this staff [3] and patch for check based on
this revert [4].

[1] https://review.openstack.org/#/c/261272/
[2] https://bugs.launchpad.net/heat/+bug/1529058
[3] https://review.openstack.org/#/c/261308/
[4] https://review.openstack.org/#/c/261272/








On 28 December 2015 at 15:06, Julien Danjou  wrote:

> Hi there,
>
> The gate for telemetry projects is broken:
>
>   https://bugs.launchpad.net/heat/+bug/1529583
>
> The failure appears in Heat from what I understand:
>
>  BadRequest: Expecting to find domain in project - the server could not
>  comply with the request since it is either malformed or otherwise
>  incorrect. The client is assumed to be in error. (HTTP 400)
>  (Request-ID: req-3f39cc92-c356-4b92-9ab8-401738c8d31d
>
> I've dig a bit, and I *think* that the problem lies in this recent
> devsatck patch:
>
>   https://review.openstack.org/#/c/254755/
>
> Could someone from Heat tell me if I'm a good Sherlock or if I am
> completely out? :)
>
> Cheers,
> --
> Julien Danjou
> // Free Software hacker
> // https://julien.danjou.info
>
> __
> 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,
Sergey.
__
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] [Heat] Status of the Support Conditionals in Heat templates

[Sergey Kraynev]

Hi Heaters,

On the last IRC meeting we had a question about Support Conditionals spec
[1].
Previous attempt for this staff is here [2].
The example of first POC in Heat can be reviewed here [3]

As I understand we have not had any complete decision about this work.
So I'd like to clarify feelings of community about it. This clarification
may be done as answers for two simple questions:
 - Why do we want to implement it?
 - Why do NOT we want to implement it?

My personal feeling is:
- Why do we want to implement it?
* A lot of users wants to have similar staff.
* It's already presented in AWS, so will be good to have this feature
in Heat too.
 - Why do NOT we want to implement it?
* it can be solved with Jinja [4] . However I don't think, that it's
really important reason for blocking this work.

Please share your idea about two questions above.
It should allows us to eventually decide, want we implement it or not.

[1] https://review.openstack.org/#/c/245042/
[2] https://review.openstack.org/#/c/153771/
[3] https://review.openstack.org/#/c/221648/1
[4] http://jinja.pocoo.org/
-- 
Regards,
Sergey.
__
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] Rico Lin for heat-core

[Sergey Kraynev]

So looks like most part have agreement :)

My congratulations, Rico!!! Good luck in this important work.
I will add you to gerrit group.

On 8 December 2015 at 06:30, Rabi Mishra  wrote:

> - Original Message -
> > Hi all.
> >
> > I'd like to nominate Rico Lin for heat-core. He did awesome job with
> > providing useful and valuable reviews. Also his contribution is really
> high
> > [1] .
> >
> > [1] http://stackalytics.com/report/contribution/heat-group/60
> >
> > Heat core-team, please vote with:
> > +1 - if you agree
> > -1 - if you disagree
>
> +1
>
> >
> > --
> > Regards,
> > Sergey.
> >
> >
> __
> > 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
>



-- 
Regards,
Sergey.
__
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] [heat] Rico Lin for heat-core

[Sergey Kraynev]

Hi all.

I'd like to nominate Rico Lin for heat-core. He did awesome job with
providing useful and valuable reviews. Also his contribution is really high
[1] .

[1] http://stackalytics.com/report/contribution/heat-group/60

Heat core-team, please vote with:
 +1 - if you agree
  -1 - if you disagree

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

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

[Sergey Kraynev]

On 30 November 2015 at 18:19, Derek Higgins  wrote:

> Hi All,
>
> A few months tripleo switch from its devtest based CI to one that was
> based on instack. Before doing this we anticipated disruption in the ci
> jobs and removed them from non tripleo projects.
>
> We'd like to investigate adding it back to heat and ironic as these
> are the two projects where we find our ci provides the most value. But we
> can only do this if the results from the job are treated as voting.
>
> In the past most of the non tripleo projects tended to ignore the
> results from the tripleo job as it wasn't unusual for the job to broken for
> days at a time. The thing is, ignoring the results of the job is the reason
> (the majority of the time) it was broken in the first place.
> To decrease the number of breakages we are now no longer running
> master code for everything (for the non tripleo projects we bump the
> versions we use periodically if they are working). I believe with this
> model the CI jobs we run have become a lot more reliable, there are still
> breakages but far less frequently.
>
> What I proposing is we add at least one of our tripleo jobs back to both
> heat and ironic (and other projects associated with them e.g. clients,
> ironicinspector etc..), tripleo will switch to running latest master of
> those repositories and the cores approving on those projects should wait
> for a passing CI jobs before hitting approve. So how do people feel about
> doing this? can we give it a go? A couple of people have already expressed
> an interest in doing this but I'd like to make sure were all in agreement
> before switching it on.
>

+1 for make it for Heat. I'd prefer approach mentioned by Zane - make it
non-voting for first time with enabling voting later in the future, when
 it be stable enough.

Also I have one more suggestion.
Could we make this TripleO job in following way:
 - with separate score, which is independent from score of other Heat jobs

I prefer mentioned approach, because:
1. Other jobs will be executed faster (AFAIK, it will take less or equal 1
hour), for TripleO it will take more time.
2. In the future it will allow to recheck only this particular job in
situation, when we want to tests some fix.
3. I hope, that Sahara team will provide similar job and we will get two
really useful job which will give one score, like: "third-party real
deployment test".



>
> thanks,
> Derek.
>
> __
> 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,
Sergey.
__
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] [Heat] Heat specs re-organization

[Sergey Kraynev]

Hi all.

This mail is announcement of changes in heat-specs repository, which were
*partially* discussed on the last Heat weekly meeting.
There are following list of planned changes:
 - Create one main directory for all specs with name, e.g. scope
 - Move all not implemented specs from previous releases to this folder
   (For supporting old links, original file content in release directory
will be replaced by link on file in scope)
Other implemented specs will be leaved without changes
 - For new release will be created pattern with on file, which contains
links on specs, which was implemented during the corresponding release
cycle.
 - For specs in "scope" directory will be added extra option like: "Feature
health" with possible values:
   Introduced/Implemented

So new approach for publishing specs will be look like:
 - create new spec in "scope"  directory with "Feature health" equals
"Introduced"
 - when it will be implemented "Feature health" should be updated with
status: "Implemented" and
   link on this spec should be added to the file for corresponding release.

Heat team, please review introduced changes ^, because I have added couple
notes, which looks reasonable for me.

-- 
Regards,
Sergey.
__
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] how to start heat through devstack

[Sergey Kraynev]

Hi, P. Ramanjaneya Reddy.

Please read Heat documentation page:
http://docs.openstack.org/developer/heat/getting_started/on_devstack.html#configure-devstack-to-enable-heat

In your case it looks like you use localrc for new version of
devstack, so you need use local.conf file instead.

If it will not help you will need provide some tracebacks from
corresponding Heat services with mentioned errors (tracebacks
mentioned by you just say, that it's not running without any
additional information about root cause).

Also I suggest to use https://ask.openstack.org/en/questions/ for such
questions ;)
Thank you.

On 24 November 2015 at 14:50, P. Ramanjaneya Reddy  wrote:
> Hi, How to start heat using devstack, i've added below services in localrc
> but throwing an error
>
> localrc:
>
> ENABLED_SERVICES+=,heat,h-api,h-api-cfn,h-api-cw,h-eng
> IMAGE_URLS+=",http://download.fedoraproject.org/pub/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.qcow2;
>
> Error:
> 2015-11-24 11:19:28.716 | Error: Service h-api-cfn is not running
> 2015-11-24 11:19:28.717 | Error: Service h-api-cw is not running
> 2015-11-24 11:19:28.718 | Error: Service h-api is not running
>
>
> any input, how to make heat work.?
>
> Thanks & Regards,
> Ramanji.
>
> __
> 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,
Sergey.

__
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] [neutron][heat] LBaaS of Neutron

[Sergey Kraynev]

On 16 November 2015 at 09:46, Qiao,Liyong  wrote:

> hi, I have some questions about neutorn LBaas.
>
> seen from the wiki, the load balancer only support:
>
> *Table 4.6. Load Balancing Algorithms*
> *Name* LEAST_CONNECTIONS ROUND_ROBIN
> https://wiki.openstack.org/wiki/Neutron/LBaaS/API
>
> think about if I have a A-P mode HA
>
> VIP : 192.168.0.10
>
> master-1 192.168.0.100 (A)
> master-2 192.168.0.101 (P)
>
> if I want to use VIP to alway connect with master-1(since it is A mode),
> only switch to master-2 when master-1 down. what should I do?
> any plan to support more algorithms for neutron lbaas?
>
> BTW, the usage is from heat:
>
>   etcd_pool:
> type: OS::Neutron::Pool
> properties:
>   protocol: HTTP
>   monitors: [{get_resource: etcd_monitor}]
>   subnet: {get_resource: fixed_subnet}
> *  lb_method: ROUND_ROBIN*
>   vip:
> protocol_port: 2379
>
>
>
> thanks,
> Eli.
>
> --
> BR, Eli(Li Yong)Qiao
>
>
> __
> 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
>
>

Hi, Qiao,Liyong

I can not say about LBaaS team plans for supporting some additional
algorithms :)
AFAIK, they do not plan add it to v1 API.
As I understand it may be discussed as part of v2 API [1]

In the Heat we have related BP [2], with several patches on review. So if
it will be implemented on Neutron side, we may add such functionality too.

[1] http://developer.openstack.org/api-ref-networking-v2-ext.html#lbaas-v2.0
[2] https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport

-- 
Regards,
Sergey.
__
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] Questions about BP for enable/disable heat-engine

[Sergey Kraynev]

Ethan,

I can see, that it was assigned on Kanagaraj, but he is now in vacation (afaik).
Also corresponding patch with specification was abandoned by his request,
so I suggest wait answer here or may be ping him in IRC directly on
the next week.

On 8 November 2015 at 17:26, Ethan Lynn  wrote:
> Hi,
>   I notice that there is a BP for enable/disable heat-engine,
> https://blueprints.launchpad.net/heat/+spec/heat-manage-service-disable-enable
>   This feature is important when maintain heat-engine in HA production, if
> one controller node needs to be replaced, we can disable heat-engine in this
> node and then replace this node.
>   I would like to know the reasons why this BP stops working, is there any
> technical issues to implement it? I don’t quite understand the issues raised
> by inc0, any one can explain it?
>   I would like to see this feature come into heat, and I would like to pay
> some effort on it.
>
> Best Regards,
> Ethan Lynn
>
>
>
>
> __
> 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,
Sergey.

__
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] Convergence plans

[Sergey Kraynev]

Anant, thank you for notification.
I will be happy to hear Kanagaraj.

__
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][Rant] About blank rechecks

[Sergey Kraynev]

On 22 October 2015 at 10:58, Thomas Herve  wrote:
> Hi all,
>
> You've seen me complain about people doing blank rechecks in Gerrit on IRC,
> and it seems it had little to no effect. So here I am trying to spread the
> word here. I'll try to stay calm.
>
> I'm seeing way too many rechecks on heat patches. It's not epidemic, but
> it's still enough to make me sad.
>
> First, it makes me sad as a developer. I don't know if it's just me, but one
> of the reason I code is curiosity, and debugging a gate failure is a great
> way to learn, pierce through the layers, and improve the situation.
>
> It then makes me sad as a team member. By doing a recheck you're basically
> implying that you don't care about the failure, and surely someone will care
> at some point. Except, the information will be lost, and we may have 100
> builds before that happen again, when a release already happened, and we
> have to backport it. Working early means working less.
>
> And finally, it makes me sad for the infra team. Doing a recheck is
> disrespecting all the work they're doing to create a reliable environment to
> run our tests. Sure, sometimes the environment is the reason the failure
> happens, but then it's even more important to give feedback about it. They
> provide a great deal of logs, we can use logstach to find patterns, the
> least we can do is trying. We're also using resources that other projects
> could be using. As much as we'd like to believe it, the cloud doesn't have
> free infinite resources.
>
> Recently, I've seen many cases where rechecks were made whereas:
> 1) The heat branch was broken. Generally for some external reason (a
> dependency updated), doing a recheck is a pure waste of resources until that
> failure is fixed. Most of the time, we say something on IRC when it's the
> case. We also try to open a bug, so looking at launchpad can show something.
> 2) THE PATCH WAS ACTUALLY BROKEN. And there I'm not sad anymore I'm
> particularly angry. It basically means that you didn't look at all at the
> build results, and just mindlessly typed rechecks hoping that some fairy
> will fix your broken code. Frankly, that makes want to go on a -2 rampage.
> ESPECIALLY where a core is doing it.
>
> To close, I'll try to provide a solution. I know we all have our agenda,
> debugging gate failures takes some time that you may not have, and obviously
> "my patch is fine it's not my fault" (who cares, that's what being in a team
> means). Still, I'd like everyone to look at the test failures, look if the
> patch is not the problem, and if not open a bug [1] mentioning the test
> name, pasting the traceback in the description, and linking the build
> result. Then do recheck bug #xyz. That's it. It shouldn't take you more than
> 3 minutes, and at least we didn't lose the information.
>
> Thanks for reading that far and sorry for the length,
>
>
> [1] https://bugs.launchpad.net/heat/+filebug
>
> --
> Thomas
>
> __
> 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
>

Thomas,

Thank you for the pay attention on this issue.
I know that you constantly ask about it, especially core-team members :)
I appreciate it, because it's really helpful and more over important.

Unfortunately new approach with empty reverify made people more lazy.
I think, that we should follow your recommendation, because:
 - it will help fix our gate faster
 - makes our develop process more clear and useful for new comers

my +2 for this initiative.
Everybody please spent your 2-3 minutes to make our work better!

-- 
Regards,
Sergey.

__
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] core team nomination

[Sergey Kraynev]

Rabi, Peter, my congradulations. You were elected by a unanimous vote :)
I will add you to heat-core group. Enjoy and stay on this course ! :)

On 21 October 2015 at 09:45, Qiming Teng <teng...@linux.vnet.ibm.com> wrote:
> +1 to both.
>
> Qiming
>
> On Tue, Oct 20, 2015 at 04:38:12PM +0300, Sergey Kraynev wrote:
>> I'd like to propose new candidates for heat core-team:
>> Rabi Mishra
>> Peter Razumovsky
>>
>> According statistic both candidate made a big effort in Heat as
>> reviewers and as contributors [1][2].
>> They were involved in Heat community work  during last several releases and
>> showed good understanding of Heat code.
>> I think, that they are ready to became core-reviewers.
>>
>> Heat-cores, please vote with +/- 1.
>>
>> [1] http://stackalytics.com/report/contribution/heat-group/180
>> [2] http://stackalytics.com/?module=heat-group=person-day
>> --
>> Regards,
>> Sergey.
>>
>> __
>> 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



-- 
Regards,
Sergey.

__
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][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Sergey Kraynev]

On 20 October 2015 at 16:04, Monty Taylor  wrote:
> On 10/20/2015 06:43 AM, Andreas Jaeger wrote:
>>
>> On 2015-10-20 12:17, Qiming Teng wrote:
>>>
>>> Hi,
>>>
>>> Just encountered this again in code review [1]. The question is about
>>> the repository to point to when documenting things up. Between the
>>> following links, which one should we use?
>>>
>>> - https://git.openstack.org/cgit/openstack/sqlalchemy-migrate
>>> - https://github.com/openstack/sqlalchemy-migrate
>>>
>>> I had an impression that I saw something like 'use git.openstack.org
>>> instead of github.com because the later is just a mirror ...' but cannot
>>> find the link now. Maybe it is an illusion. :)
>>>
>>> So, seriously, any recommendations or guidelines?
>>
>>
>> Yes, git.openstack.org is our official server, github is just a
>> read-only mirror.
>>
>> Linking to github might also raise the expectation that we use the usual
>> github workflow which is not the case,
>
>
> ++
>
> I try to update github urls when I find them - but it's better if they don't
> crop up in general. :)
>
>
>
> __
> 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


Guys, I got idea. Thank you for clarification. We will use correct
link instead of github :)
Qiming, thank you for the question ;)

-- 
Regards,
Sergey.

__
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] [Heat] core team nomination

[Sergey Kraynev]

I'd like to propose new candidates for heat core-team:
Rabi Mishra
Peter Razumovsky

According statistic both candidate made a big effort in Heat as
reviewers and as contributors [1][2].
They were involved in Heat community work  during last several releases and
showed good understanding of Heat code.
I think, that they are ready to became core-reviewers.

Heat-cores, please vote with +/- 1.

[1] http://stackalytics.com/report/contribution/heat-group/180
[2] http://stackalytics.com/?module=heat-group=person-day
-- 
Regards,
Sergey.

__
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] [Heat] Mitaka design summit schedule

[Sergey Kraynev]

Hi folks, I glad to inform you about final version of Heat schedule
for design summit.

Online version is available here:
- http://mitakadesignsummit.sched.org/type/Heat#.Vh_V7NSlyko

It will be useful for understanding rooms and time.

If you want to look on description and etherpad for each session,
please use wiki page:
- https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Heat

Heat Core-team, please do not hesitate to edit and add your ideas to
corresponding etherpads.

-- 
Regards,
Sergey.

__
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] mox to mock migration

[Sergey Kraynev]

Jay,

I think, that only one person who partially do the same job is Qiming.
Please ask him about it.
Also I think, that will be good to create BP for it, which you may
mention in commit messages.
In this Bp you may specify list of directories for parallel work.
There is nothing else from my side. :)
Thank you for volunteering!

On 9 October 2015 at 16:06, Jay Dobies  wrote:
> I forget where we left things at the last meeting with regard to whether or
> not there should be a blueprint on this. I was going to work on some during
> some downtime but I wanted to make sure I wasn't overlapping with what
> others may be converting (it's more time consuming than I anticipated).
>
> Any thoughts on how to track it?
>
> Thanks :)
>
> __
> 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,
Sergey.

__
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] perfomance benchmark metrics of heat-api

[Sergey Kraynev]

On 6 October 2015 at 10:18, Christian Berendt  wrote:
> On 10/06/2015 05:20 AM, ESWAR RAO wrote:
>>
>> Has anyone done any performance tests on heat-api servers on any
>> standard setup so as to know how many stack requests it can handle
>> before it can stumble so that we can deploy scaling of heat-servers ??
>
>
> It depends on your environment and you should run your own tests. Have a
> look at
> https://github.com/openstack/rally/tree/master/samples/tasks/scenarios/heat
> for a lot of prepared scenarios for Heat.
>
> HTH, Christian.
>
> --
> Christian Berendt
> Cloud Solution Architect
> Mail: bere...@b1-systems.de
>
> B1 Systems GmbH
> Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>
> __
> 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


ESWAR RAO,  good question !

I don't know about some published results for such performance testing :)

As Christian Berendt said: it's really depends on particular
deployment installation, so suggestion about using rally is the best
option :)
Btw, if you do it, feel free to share with community - it will be
really helpful for us.

-- 
Regards,
Sergey.

__
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] Traditional question about Heat IRC meeting time.

[Sergey Kraynev]

Thank you all for the feedback :)

Let's continue with the same time frames.

Zane, I will try to move main/complex questions on the 2000 UTC
meetings to allow you to debate in it :)

On 1 October 2015 at 20:13, x Lyn <xuanlangj...@gmail.com> wrote:
> +1 for 7:00
>
> Sent from my iPhone
>
>> On Oct 1, 2015, at 10:36 PM, Zane Bitter <zbit...@redhat.com> wrote:
>>
>>> On 29/09/15 05:56, Sergey Kraynev wrote:
>>> Hi Heaters!
>>>
>>> Previously we had constant "tradition" to change meeting time for
>>> involving more people from different time zones.
>>> However last release cycle show, that two different meetings with 07:00
>>> and 20:00 UTC are comfortable for most of our contributors. Both time
>>> values are acceptable for me and I plan to visit both meetings. So I
>>> suggested to leave it without any changes.
>>>
>>> What do you think about it ?
>>
>> Sadly I can only make the 2000 UTC, but +1 anyway... it seems to be working 
>> ok at the moment.
>>
>> - ZB
>>
>> __
>> 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



-- 
Regards,
Sergey.

__
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] Assumptions regarding extensions to OpenStack api's

[Sergey Kraynev]

Guys. Thank you for the pointing to the this gap.

It probably was wrong missed before assumption about nova extension.
I was personally sure, that it this extension always is installed.
Currently we have couple resources OS::Nova::Server and AWS::EC2::Instance,
which uses this extension with wrong assumption, that extension is
presented in nova.

Pratik, I have seen bug created by you and agree, that it's bug.
We will fix this during Mitaka, also I suppose, that it should be
backported to previous releases (may need additional work, but it will be
done, I supppose).



Regards,
Sergey.

On 25 September 2015 at 23:08, Monty Taylor  wrote:

> On 09/25/2015 02:32 PM, Pratik Mallya wrote:
>
>> Hello Heat Team,
>>
>> I was wondering if OpenStack Heat assumes that the Nova extensions api
>> would always exist in a cloud? My impression was that since these
>> features are extensions, they may or may not be implemented by the cloud
>> provider and hence Heat must not rely on it being present.
>>
>> My question is prompted by this code change: [0] where it is assumed
>> that the os-interfaces extension [1] is implemented.
>>
>> If we cannot rely on that assumption, then that code would need to be
>> changed with a 404 guard since that endpoint may not exist and the nova
>> client may thus raise a 404.
>>
>
> Correct. Extensions are not everywhere and so you must either query the
> extensions API to find out what extensions the cloud has, or you must 404
> guard.
>
> Of course, you can't ONLY 404 guard, because the cloud may also throw
> unauthorized - so querying the nova extension API is the more correct way
> to deal with it.
>
> Thanks,
>> Pratik Mallya
>> Software Developer
>> Rackspace, Inc.
>>
>> [0]:
>>
>> https://github.com/openstack/heat/commit/54c26453a0a8e8cb574858c7e1d362d0abea3822#diff-b3857cb91556a2a83f40842658589e4fR163
>> [1]:
>> http://developer.openstack.org/api-ref-compute-v2-ext.html#os-interface
>>
>>
>> __
>> 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] [heat] Traditional question about Heat IRC meeting time.

[Sergey Kraynev]

Hi Heaters!

Previously we had constant "tradition" to change meeting time for involving
more people from different time zones.
However last release cycle show, that two different meetings with 07:00 and
20:00 UTC are comfortable for most of our contributors. Both time values
are acceptable for me and I plan to visit both meetings. So I suggested to
leave it without any changes.

What do you think about it ?

Regards,
Sergey.
__
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] [neutron][lbaas] - Heat support for LbaasV2

[Sergey Kraynev]

Guys, my apologize for the delay. Now I can give answers.

Stephen, Heat meeting scheduled on Wednesday. (
https://wiki.openstack.org/wiki/Meetings/HeatAgenda)

Result was really short and clear: use suggested in this mail thread naming
OS::LBaaS::*  and add new resources.
I personally think, that this work requires separate BP + spec. So some
corner cases about similar resources may be discussed on review for this
specification.

Thank you guys, for the raising this idea. We  definitely should provide
new "fresh" resources for users :)

Regards,
Sergey.

On 25 September 2015 at 01:30, Doug Wiegley <doug...@parksidesoftware.com>
wrote:

> Hi Sergey,
>
> I agree with the previous comments here. While supporting several APIs at
> once, with one set of objects, is a noble goal, in this case, the object
> relationships are *completely* different. Unless you want to get into the
> business of redefining your own higher-level API abstractions in all cases,
> that general strategy for all things will be awkward and difficult.
>
> Some API changes lend themselves well to object reuse abstractions. Some
> don’t. Lbaas v2 is definitely the latter, IMO.
>
> What was the result of your meeting discussion?  (*goes to grub around in
> eavesdrop logs after typing this.*)
>
> Thanks,
> doug
>
>
>
> On Sep 23, 2015, at 12:09 PM, Sergey Kraynev <skray...@mirantis.com>
> wrote:
>
> Guys. I happy, that you already discussed it here :)
> However, I'd like to raise same question on our Heat IRC meeting.
> Probably we should define some common concepts, because I think, that
> lbaas is not single example of service with
> several APIs.
> I will post update in this thread later (after meeting).
>
> Regards,
> Sergey.
>
> On 23 September 2015 at 14:37, Fox, Kevin M <kevin@pnnl.gov> wrote:
>
>> Seperate ns would work great.
>>
>> Thanks,
>> Kevin
>>
>> --
>> *From:* Banashankar KV
>> *Sent:* Tuesday, September 22, 2015 9:14:35 PM
>>
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [neutron][lbaas] - Heat support for
>> LbaasV2
>>
>> What you think about separating both of them with the name as Doug
>> mentioned. In future if we want to get rid of the v1 we can just remove
>> that namespace. Everything will be clean.
>>
>> Thanks
>> Banashankar
>>
>>
>> On Tue, Sep 22, 2015 at 6:01 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
>>
>>> As I understand it, loadbalancer in v2 is more like pool was in v1. Can
>>> we make it such that if you are using the loadbalancer resource and have
>>> the mandatory v2 properties that it tries to use v2 api, otherwise its a v1
>>> resource? PoolMember should be ok being the same. It just needs to call v1
>>> or v2 depending on if the lb its pointing at is v1 or v2. Is monitor's api
>>> different between them? Can it be like pool member?
>>>
>>> Thanks,
>>> Kevin
>>>
>>> --
>>> *From:* Brandon Logan
>>> *Sent:* Tuesday, September 22, 2015 5:39:03 PM
>>>
>>> *To:* openstack-dev@lists.openstack.org
>>> *Subject:* Re: [openstack-dev] [neutron][lbaas] - Heat support for
>>> LbaasV2
>>>
>>> So for the API v1s api is of the structure:
>>>
>>> /lb/(vip|pool|member|health_monitor)
>>>
>>> V2s is:
>>> /lbaas/(loadbalancer|listener|pool|healthmonitor)
>>>
>>> member is a child of pool, so it would go down one level.
>>>
>>> The only difference is the lb for v1 and lbaas for v2.  Not sure if that
>>> is enough of a different.
>>>
>>> Thanks,
>>> Brandon
>>> On Tue, 2015-09-22 at 23:48 +, Fox, Kevin M wrote:
>>> > Thats the problem. :/
>>> >
>>> > I can't think of a way to have them coexist without: breaking old
>>> > templates, including v2 in the name, or having a flag on the resource
>>> > saying the version is v2. And as an app developer I'd rather not have
>>> > my existing templates break.
>>> >
>>> > I haven't compared the api's at all, but is there a required field of
>>> > v2 that is different enough from v1 that by its simple existence in
>>> > the resource you can tell a v2 from a v1 object? Would something like
>>> > that work? PoolMember wouldn't have to change, the same resource could
>>> > probably work for whatever lb it was pointing at I'm guessing.
>>> >
>&g

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

[Sergey Kraynev]

> > Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support
>> > for LbaasV2
>> >
>> >
>> >
>> >
>> > But I think, V2 has introduced some new components and whole
>> > association of the resources with each other is changed, we
>> > should be still able to do what Kevin has mentioned ?
>> >
>> > Thanks
>> > Banashankar
>> >
>> >
>> >
>> > On Tue, Sep 22, 2015 at 3:39 PM, Fox, Kevin M
>> > <kevin@pnnl.gov> wrote:
>> > There needs to be a way to have both v1 and v2
>> > supported in one engine
>> >
>> > Say I have templates that use v1 already in existence
>> > (I do), and I want to be able to heat stack update on
>> > them one at a time to v2. This will replace the v1 lb
>> > with v2, migrating the floating ip from the v1 lb to
>> > the v2 one. This gives a smoothish upgrade path.
>> >
>> > Thanks,
>> > Kevin
>> > 
>> > From: Brandon Logan [brandon.lo...@rackspace.com]
>> > Sent: Tuesday, September 22, 2015 3:22 PM
>> > To: openstack-dev@lists.openstack.org
>> > Subject: Re: [openstack-dev] [neutron][lbaas] - Heat
>> > support for LbaasV2
>> >
>> > Well I'd hate to have the V2 postfix on it because V1
>> > will be deprecated
>> > and removed, which means the V2 being there would be
>> > lame.  Is there any
>> > kind of precedent set for for how to handle this?
>> >
>> > Thanks,
>> > Brandon
>> > On Tue, 2015-09-22 at 14:49 -0700, Banashankar KV
>> > wrote:
>> > > So are we thinking of making it as ?
>> > > OS::Neutron::LoadBalancerV2
>> > >
>> > > OS::Neutron::ListenerV2
>> > >
>> > > OS::Neutron::PoolV2
>> > >
>> > > OS::Neutron::PoolMemberV2
>> > >
>> > > OS::Neutron::HealthMonitorV2
>> > >
>> > >
>> > >
>> > > and add all those into the loadbalancer.py of heat
>> > engine ?
>> > >
>> > > Thanks
>> > > Banashankar
>> > >
>> > >
>> > >
>> > > On Tue, Sep 22, 2015 at 12:52 PM, Sergey Kraynev
>> > > <skray...@mirantis.com> wrote:
>> > > Brandon.
>> > >
>> > >
>> > > As I understand we v1 and v2 have
>> > differences also in list of
>> > > objects and also in relationships between
>> > them.
>> > > So I don't think that it will be easy to
>> > upgrade old resources
>> > > (unfortunately).
>> > > I'd agree with second Kevin's suggestion
>> > about implementation
>> > > new resources in this case.
>> > >
>> > >
>> > > I see, that a lot of guys, who wants to help
>> > with it :) And I
>> > > suppose, that me and Rabi Mishra may try to
>> > help with it,
>> > > because we was involvement in implementation
>> > of v1 resources
>> > > in Heat.
>> > > Follow the list of v1 lbaas resources in
>> > Heat:
>> > >
>> > >
>> > >
>> >
>> http://docs.openstack.

Re: [openstack-dev] [neutron][lbaas] - Heat support for LbaasV2

[Sergey Kraynev]

Brandon.

As I understand we v1 and v2 have differences also in list of objects and
also in relationships between them.
So I don't think that it will be easy to upgrade old resources
(unfortunately).
I'd agree with second Kevin's suggestion about implementation new resources
in this case.

I see, that a lot of guys, who wants to help  with it :) And I suppose,
that me and Rabi Mishra may try to help with it, because we was involvement
in implementation of v1 resources in Heat.
Follow the list of v1 lbaas resources in Heat:

http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::LoadBalancer
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Pool
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::PoolMember
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::HealthMonitor

Also, I suppose, that it may be discussed during summit talks :)
Will add to etherpad with potential sessions.


Regards,
Sergey.

On 22 September 2015 at 22:27, Brandon Logan 
wrote:

> There is some overlap, but there was some incompatible differences when
> we started designing v2.  I'm sure the same issues will arise this time
> around so new resources sounds like the path to go.  However, I do not
> know much about Heat and the resources so I'm speaking on a very
> uneducated level here.
>
> Thanks,
> Brandon
> On Tue, 2015-09-22 at 18:38 +, Fox, Kevin M wrote:
> > We're using the v1 resources...
> >
> > If the v2 ones are compatible and can seamlessly upgrade, great
> >
> > Otherwise, make new ones please.
> >
> > Thanks,
> > Kevin
> >
> > __
> > From: Banashankar KV [banvee...@gmail.com]
> > Sent: Tuesday, September 22, 2015 10:07 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for
> > LbaasV2
> >
> >
> >
> > Hi Brandon,
> > Work in progress, but need some input on the way we want them, like
> > replace the existing lbaasv1 or we still need to support them ?
> >
> >
> >
> >
> >
> >
> >
> > Thanks
> > Banashankar
> >
> >
> >
> > On Tue, Sep 22, 2015 at 9:18 AM, Brandon Logan
> >  wrote:
> > Hi Banashankar,
> > I think it'd be great if you got this going.  One of those
> > things we
> > want to have and people ask for but has always gotten a lower
> > priority
> > due to the critical things needed.
> >
> > Thanks,
> > Brandon
> > On Mon, 2015-09-21 at 17:57 -0700, Banashankar KV wrote:
> > > Hi All,
> > > I was thinking of starting the work on heat to support
> > LBaasV2,  Is
> > > there any concerns about that?
> > >
> > >
> > > I don't know if it is the right time to bring this up :D .
> > >
> > > Thanks,
> > > Banashankar (bana_k)
> > >
> > >
> >
> > >
> >
>  __
> > > 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] [Heat] Integration Test Questions

[Sergey Kraynev]

sorry, false pressing ;)

Regards,
Sergey.

On 13 September 2015 at 16:10, Sergey Kraynev <skray...@mirantis.com> wrote:

> Hi Sabeen,
>
> I think, that Pavlo described whole picture really nice.
> So I'd like just to add couple my thoughts below:
>
>
> Regards,
> Sergey.
>
> On 12 September 2015 at 15:08, Pavlo Shchelokovskyy <
> pshchelokovs...@mirantis.com> wrote:
>
>> Hi Sabeen,
>>
>> thank you for the effort :) More tests is always better than less, but
>> unfortunately we are limited by the power of VM and time available for
>> gate jobs. This is why we do no exhaustive functional testing of all
>> resource plugins APIs, as every time a test goes out and makes an
>> async API call to OpenStack, like create a server, it always consumes
>> time, and often consumes resources of VM that runs other tests of the
>> same test suit as well (we do run them in parallel) making other tests
>> also slower to some degree. Also, even for not-async/lightweight
>> resources (e.g. SaharaNodeGroupTemplate), testing all of them requires
>> running a corresponding OpenStack service on the gate job, which will
>> consume its resources even further.
>>
>
> More over new additional services make devstack installation longer, so
> as result we have less time for running tests.
> Note, that we also should be careful during adding new tests, because as
> Pavlo mentioned, we run them in parallel. I suppose, that everyone try
> to use unique names for stacks and for internal resources or use only
> random ids, but anyway want to remind do it carefully ;)
>
>
>>
>> Below are my thoughts and comments inline:
>>
>> On Fri, Sep 11, 2015 at 6:46 PM, Sabeen Syed <sabeen.s...@rackspace.com>
>> wrote:
>> > Hi All,
>> >
>> > My coworker and I would like to start filling out some gaps in api
>> coverage
>> > that we see in the functional integration tests. We have one patch up
>> for
>> > review (https://review.openstack.org/#/c/219025/). We got a comment
>> saying
>> > that any new stack creation will prolong the testing cycle. We agree
>> with
>> > that and it got us thinking about a few things -
>>
>> this test should use the TestResource (or even RandomString if you do
>> not need to ensure a particular order of events), as there is no point
>> of using an actual server for the assertions this test makes on
>> stack/resource events.
>>
>
> I personally prefer TestResource, because it's more flexible and
>
probably easier for understanding/writing templates.

>
>
>
>>
>> >
>> > We are planning on adding tests for the following api's: event api's,
>> > template api's, software config api's, cancel stack updates, check stack
>> > resources and show resource data. These are the api's that we saw aren't
>> > covered in our current integration tests. Please let us know if you
>> feel we
>> > need tests for these upstream, if we're missing something or if it's
>> already
>> > covered somewhere.
>>
>> Just make sure all (ideally) of them use TestResource/RandomStrings.
>> You might still have to tweak it a bit to support a successful/failed
>> check though. There is a test for SC/SD in functional (and I actually
>> wonder what is it doing in functional but not scenario), is it not
>> enough?
>>
>> > To conserve the creation of stacks would it make sense to add one test
>> and
>> > then under that we could call sub methods that will run tests against
>> that
>> > stack. So something like this:
>> >
>> > def _test_template_apis()
>> >
>> > def _test_softwareconfig_apis()
>> >
>> > def _test_event_apis()
>> >
>> > def test_event_template_softwareconfig_apis(self):
>> >
>> > stack_id = self.stack_create(…)
>> >
>> > self._test_template_apis(stack_id)
>> >
>> > self._test_event_apis(stack_id)
>> >
>> > self._test_softwareconfig_apis(stack_id)
>>
>> If you use TestResource and the like, the time to create a new stack
>> for each test is not that long. And it is much better to have API
>> tests separated as actual unit tests, otherwise failure in one API
>> will fail the whole test which only leaves the developer wondering
>> "what was that?" and makes it harder to find the root cause.
>>
>> >
>> > The current tests are divided into two folders – scenario and
>> functional. To
>> > help with organization - under 

Re: [openstack-dev] [Heat] Integration Test Questions

[Sergey Kraynev]

Hi Sabeen,

I think, that Pavlo described whole picture really nice.
So I'd like just to add couple my thoughts below:


Regards,
Sergey.

On 12 September 2015 at 15:08, Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> Hi Sabeen,
>
> thank you for the effort :) More tests is always better than less, but
> unfortunately we are limited by the power of VM and time available for
> gate jobs. This is why we do no exhaustive functional testing of all
> resource plugins APIs, as every time a test goes out and makes an
> async API call to OpenStack, like create a server, it always consumes
> time, and often consumes resources of VM that runs other tests of the
> same test suit as well (we do run them in parallel) making other tests
> also slower to some degree. Also, even for not-async/lightweight
> resources (e.g. SaharaNodeGroupTemplate), testing all of them requires
> running a corresponding OpenStack service on the gate job, which will
> consume its resources even further.
>

More over new additional services make devstack installation longer, so
as result we have less time for running tests.
Note, that we also should be careful during adding new tests, because as
Pavlo mentioned, we run them in parallel. I suppose, that everyone try
to use unique names for stacks and for internal resources or use only
random ids, but anyway want to remind do it carefully ;)


>
> Below are my thoughts and comments inline:
>
> On Fri, Sep 11, 2015 at 6:46 PM, Sabeen Syed 
> wrote:
> > Hi All,
> >
> > My coworker and I would like to start filling out some gaps in api
> coverage
> > that we see in the functional integration tests. We have one patch up for
> > review (https://review.openstack.org/#/c/219025/). We got a comment
> saying
> > that any new stack creation will prolong the testing cycle. We agree with
> > that and it got us thinking about a few things -
>
> this test should use the TestResource (or even RandomString if you do
> not need to ensure a particular order of events), as there is no point
> of using an actual server for the assertions this test makes on
> stack/resource events.
>

I personally prefer TestResource, because it's more flexible and



>
> >
> > We are planning on adding tests for the following api's: event api's,
> > template api's, software config api's, cancel stack updates, check stack
> > resources and show resource data. These are the api's that we saw aren't
> > covered in our current integration tests. Please let us know if you feel
> we
> > need tests for these upstream, if we're missing something or if it's
> already
> > covered somewhere.
>
> Just make sure all (ideally) of them use TestResource/RandomStrings.
> You might still have to tweak it a bit to support a successful/failed
> check though. There is a test for SC/SD in functional (and I actually
> wonder what is it doing in functional but not scenario), is it not
> enough?
>
> > To conserve the creation of stacks would it make sense to add one test
> and
> > then under that we could call sub methods that will run tests against
> that
> > stack. So something like this:
> >
> > def _test_template_apis()
> >
> > def _test_softwareconfig_apis()
> >
> > def _test_event_apis()
> >
> > def test_event_template_softwareconfig_apis(self):
> >
> > stack_id = self.stack_create(…)
> >
> > self._test_template_apis(stack_id)
> >
> > self._test_event_apis(stack_id)
> >
> > self._test_softwareconfig_apis(stack_id)
>
> If you use TestResource and the like, the time to create a new stack
> for each test is not that long. And it is much better to have API
> tests separated as actual unit tests, otherwise failure in one API
> will fail the whole test which only leaves the developer wondering
> "what was that?" and makes it harder to find the root cause.
>
> >
> > The current tests are divided into two folders – scenario and
> functional. To
> > help with organization - under the functional folder, would it make
> sense to
> > add an 'api' folder, 'resource' folder and 'misc folder? Here is what
> we're
> > thinking about where each test can be put:
> >
> > API folder - test_create_update.py, test_preview.py
> >
> > Resource folder – test_autoscaling.py, test_aws_stack.py,
> > test_conditional_exposure.py, test_create_update_neutron_port.py,
> > test_encryption_vol_type.py, test_heat_autoscaling.py,
> > test_instance_group.py, test_resource_group.py, test_software_config.py,
> > test_swiftsignal_update.py
> >
> > Misc folder - test_default_parameters.py, test_encrypted_parameter.py,
> > test_hooks.py, test_notifications.py, test_reload_on_sighup.py,
> > test_remote_stack.py, test_stack_tags.py, test_template_resource.py,
> > test_validation.py
> >
> > Should we add to our README? For example, I see that we use TestResource
> as
> > a resource in some of our tests but we don't have an explanation of how
> to
> > set that up. I'd also like add explanations about the pre-testhook and
> > post-testhook file and how 

[openstack-dev] [Tripleo][Heat][Nova][Ironic] Rich-network stuff and ironic hypervisor

[Sergey Kraynev]

Hi folks,

Currently during implementation rich-network bp [1] (spec - [2]) we met
with issue on Tripleo
 [3]. As temporary solution patch [4] was reverted.

According traceback mentioned in bug description current issue related with
mac
 addresses which should be used for specific hypervisor [5] [6].
Previously in Tripleo, when we created vm without 'port-id' in networks
parameters, it was
 handled by Nova [7], so new port got mac address from list of allowed
addresses.

According rich-network BP, we want to use pre-created port (which we create
in Heat code
 directly) during booting VM. Unfortunately in this case validation
mentioned above fails due
 to different mac_addresses (for port and for hypervisor).

We discussed it with Derek, and it looks like for Tripleo  it's overhead
work to get such mac
 addresses and pass it in Heat template. Also I personally think, that it's
not user side issue,
i.e. we should solve it inside Heat code ourselves. So we probably need to
ask Nova Ironic driver (because we can not ask ironic directly from Heat)
for this information - about list
of allowed mac-addresses and then use it during creating port.

I have investigated Novaclient code, but did not met any ability to do it,
except make to_dict() for Hypervisor object, but I am not sure, that it
will be presented in this output.

So I'd ask Nova guys about some suggestions.
Also any thoughts are welcome.


[1] https://blueprints.launchpad.net/heat/+spec/rich-network-prop
[2] https://review.openstack.org/#/c/130093
[3] https://bugs.launchpad.net/tripleo/+bug/1494747
[4] https://review.openstack.org/#/c/217753/
[5]
https://github.com/openstack/nova/blob/309301381039b162588e5f2d348b5b666c96bd3a/nova/network/neutronv2/api.py#L477-L488
[6]
https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L662-L678
[7]
https://github.com/openstack/nova/blob/309301381039b162588e5f2d348b5b666c96bd3a/nova/network/neutronv2/api.py#L278

Regards,
Sergey.
__
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] [gate] gate-heat-dsvm-functional-orig-mysql fails 100%

[Sergey Kraynev]

Sean, thank you for the raising it.

We know about this issue. It was related with glanceclient:
There is a fix, which fixes this issue -
https://review.openstack.org/#/c/219533/

If it's possible may you abandon changes in queue before this patch?

Regards,
Sergey.

On 2 September 2015 at 16:07, Sean Dague  wrote:

> Today's gate firedrill #2 is the fact that in the last 12 hours heat's
> functional tests went to 100% failure - http://goo.gl/YeVrD0
>
> There are current 14 heat changes in the gate, each will add 30 - 40
> minutes of delay as they fail and reset things behind them. So 7 - 10
> hours of gate delay for everyone because of these patches.
>
> Could heat team members get engaged and get to the bottom of this one?
>
> -Sean
>
> --
> Sean Dague
> http://dague.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] [Heat] convergence rally test results (so far)

[Sergey Kraynev]

Angus!

it's Awesome!  Thank you for the investigation.
I had a talk with guys from Sahara team and we decided to start testing
convergence with Sahara after L release.
I suppose, that Murano can also join to this process.

Also AFAIK Sahara team plan to create functional tests with Heat-engine. We
may add it as a non-voting job for our gate.
Probably it will be good to have two different type of this job: with
convergence and with default Heat.

On 28 August 2015 at 04:35, Angus Salkeld asalk...@mirantis.com wrote:

 Hi

 I have been running some rally tests against convergence and our existing
 implementation to compare.

 So far I have done the following:

1. defined a template with a resource group

 https://github.com/asalkeld/convergence-rally/blob/master/templates/resource_group_test_resource.yaml.template
2. the inner resource looks like this:

 https://github.com/asalkeld/convergence-rally/blob/master/templates/server_with_volume.yaml.template
  (it
uses TestResource to attempt to be a reasonable simulation of a
server+volume+floatingip)
3. defined a rally job:

 https://github.com/asalkeld/convergence-rally/blob/master/increasing_resources.yaml
  that
creates X resources then updates to X*2 then deletes.
4. I then ran the above with/without convergence and with 2,4,8
heat-engines

 Here are the results compared:

 https://docs.google.com/spreadsheets/d/12kRtPsmZBl_y78aw684PTBg3op1ftUYsAEqXBtT800A/edit?usp=sharing


Results look pretty nice (especially for create) :)
The strange thing for me: why on update 8 engines shows worse results
then with 4 engines? (may be mistake in graph... ?)





 Some notes on the results so far:

-  convergence with only 2 engines does suffer from RPC overload (it
gets message timeouts on larger templates). I wonder if this is the problem
in our convergence gate...

 Good spotting. If it's true, probably we should try to change  number of
engines... (not sure, how gate hardware react on it).


- convergence does very well with a reasonable number of engines
running.
- delete is slightly slower on convergence


Also about delete - may be we may to optimize it later, when convergence
way get more feedback.


 Still to test:

- the above, but measure memory usage
- many small templates (run concurrently)
- we need to ask projects using Heat to try with convergence (Murano,
TripleO, Magnum, Sahara, etc..)

 Any feedback welcome (suggestions on what else to test).

 -Angus

 __
 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,
Sergey.
__
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] [magnum] devstack/heat problem with master_wait_condition

[Sergey Kraynev]

Hi Stanislaw,

Your host with Fedora should have special config file, which will send
signal to WaitCondition.
For good example please take a look this template
 
https://github.com/openstack/heat-templates/blob/819a9a3fc9d6f449129c8cefa5e087569340109b/hot/native_waitcondition.yaml
https://github.com/openstack/heat-templates/blob/819a9a3fc9d6f449129c8cefa5e087569340109b/hot/native_waitcondition.yaml

Also the best place for such question I suppose will be
https://ask.openstack.org/en/questions/
https://ask.openstack.org/en/questions/

Regards,
Sergey.

On 26 August 2015 at 09:23, Pitucha, Stanislaw Izaak 
stanislaw.pitu...@hp.com wrote:

 Hi all,

 I’m trying to stand up magnum according to the quickstart instructions
 with devstack.

 There’s one resource which times out and fails: master_wait_condition. The
 kube master (fedora) host seems to be created, I can login to it via ssh,
 other resources are created successfully.



 What can I do from here? How do I debug this? I tried to look for the
 wc_notify itself to try manually, but I can’t even find that script.



 Best Regards,

 Stanisław Pitucha



 __
 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] Proposing Kanagaraj Manickam and Ethan Lynn for heat-core

[Sergey Kraynev]

+1 from me for both.

Regards,
Sergey.

On 31 July 2015 at 07:35, Steve Baker sba...@redhat.com wrote:

 I believe the heat project would benefit from Kanagaraj Manickam and Ethan
 Lynn having the ability to approve heat changes.

 Their reviews are valuable[1][2] and numerous[3], and both have been
 submitting useful commits in a variety of areas in the heat tree.

 Heat cores, please express your approval with a +1 / -1.

 [1] http://stackalytics.com/?user_id=kanagaraj-manickammetric=marks
 [2] http://stackalytics.com/?user_id=ethanlynnmetric=marks
 [3] http://stackalytics.com/report/contribution/heat-group/90

 __
 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][heat][oslo] Public show and validation clients methods

[Sergey Kraynev]

Doug, Terry.

Thank you for the feedback.
I will create a BP with list of desired public methods and will add all
projects to it.

Regards,
Sergey.

On 9 July 2015 at 21:20, Doug Hellmann d...@doughellmann.com wrote:

 Excerpts from Sergey Kraynev's message of 2015-07-09 18:26:09 +0300:
  Hi community.
 
  I want to raise couple questions about openstack clients.
  In Heat we use other python-*clients for manipulating service's
 resources,
  but some stuff placed in shell.py modules and we are forced to duplicate
  some existing code.
 
  There are couple examples which I met last time:
   - getting resource by name or id
 
  All clients implement this logic in the shell.py module and it's not
  possible to re-use it from client
  directly as single call of some function resolve_by_name_or_id
  (unfortunately same is for Heat too ). As result all external developers
  (and we too as orchestration tool) should copy logic in our repos and
  implement similar resolve methods for all services/resources.
 
  - show command for clients
 
  some of clients use base Resource class and they have ._info attribute,
  but it's private and use it is not right too. But I did not see another
  solution, because clients have not some *_show public method for it too
  (except neutron :) ). Also there is additional issue, when clients use
  their own classes, without this attribute, e.g. glance v2.
 
  So my question: can we create mentioned above public methods for such
 stuff
  and make it as standard for all clients or may be discuss list of common
  public interfaces for all clients?

 Until the SDK is ready for use, adding public methods or attributes
 seems like the best approach.

 Doug

 
  If it was raised early please point me, because this issue is really
  painful, when you try to implement
  common approach for all projects.
 
  Regards,
  Sergey.

 __
 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] [Heat] Show attribute is a collection of other attributes or not?

[Sergey Kraynev]

Thank everyone for the good feedback.
If summarize all suggestions:
 - I will continue add show as raw output (similar on clients show command
output)
 - Also we decided to implement additional functional for get_attr
function, when it get only resource name and returns map with all
attributes (except show).

About second one need volunteer :)

Regards,
Sergey.

On 3 July 2015 at 00:04, Steven Hardy sha...@redhat.com wrote:

 On Fri, Jul 03, 2015 at 07:35:18AM +1200, Steve Baker wrote:
  On 03/07/15 06:03, Randall Burt wrote:
  Maybe use all for all attributes in the schema and use show for the
 raw output from the service (as is done today for server and neutron stuff).
  Instead of all, how about allowing a special form of {get_attr:
  [resource_name]} with no extra arguments to return a dict of all
 attributes?
  This would be consistent with how extra arguments traverse attribute
 data.

 +1

 __
 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] [Heat] Show attribute is a collection of other attributes or not?

[Sergey Kraynev]

Hi Heaters.

I don't think that my question is very huge for openstack-dev, but it
affects a lot of Heat resources
and need collect more opinions before apply some of follow approaches.
I recently uploaded initial approach for implementation common 'show'
attribute [1]
https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:show-attribute,n,z


On one of this review was raised one interesting suggestion:
'show' attribute should return map of all resource's attributes, i.e.

for each attr in self.attributes_schema:
   outputs[attr] =  _resolve_attribute(attr)
return outputs

I agree, that it's more easier than separate show_resource method for each
resource and it's the same, what returns Neutron API on show request.
However, we already has opposite example, when OS::Nova::Server resource
has bunch of attributes which are not similar on current 'show' attribute
output:

https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/nova/server.py#L918

I suppose, that the same situation will be and for other resources.

So I want to ask about way, which we would like to follow?
[1] show as collection of attributes
[2] show as the same output for command some client  name of
resource-show


Regards,
Sergey.
__
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][Oslo] Versioned objects compatibility mode

[Sergey Kraynev]

Davanum,

Can we also use SIGHUP signal tool instead of for these restarts?

Regards,
Sergey.

On 22 June 2015 at 13:12, Davanum Srinivas dava...@gmail.com wrote:

 Michał,

 we are adding that reread config to oslo.service, there's a test
 version on pypi 0.1.0 (API not yet stable) that you can try and see if
 it works for you.

 thanks,
 dims

 On Mon, Jun 22, 2015 at 5:40 AM, Jastrzebski, Michal
 michal.jastrzeb...@intel.com wrote:
  Hello,
 
  I wanted to start discussion about versioned objects backporting for
 conductor-less projects.
  In Vancouver we discussed compatibility mode, which works like that:
 
  1. We define one version for every object we use, this means adding base
 object, for example:
 
  Class HeatObject:
  VERSION=1.5
 
  All objects inherit from this one, each time we change it, we bump up
 this variable.
 
  2. We introduce new config option in heat.conf
 
  Combatibility_mode = 1.4
 
  3. Implement mechanism which will automatically backport each outgoing
 message to 1.4 as long as we have this var.
 
  Upgrade flow looks like that:
  1. We have all nodes using 1.4 version
  2. We incrementally run new version with 1.4 compatibility mode
  3. When all nodes are already up-to-date, we incrementally turn off
 compatibility mode
 
  This solution has one rather big disadvantage: 2 restarts.
  This can be mitigated by adding another call to reread config without
 restart. Oslo.config has this capability, but we need to add call to run it.
 
  Thoughts?
 
  Regards,
  Michał Jastrzębski
 
 
 __
  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] [heat][python-heatclient] Does python-heatclient works with keystone sessions?

[Sergey Kraynev]

Hi Jay.

AFAIK, it works, but we can have some minor issues. There several atches on
review to improve it:

https://review.openstack.org/#/q/status:open+project:openstack/python-heatclient+branch:master+topic:improve-sessionclient,n,z

Also as I remember we really had bug mentioned by you, but fix was merged.
Please look:
https://review.openstack.org/#/c/160431/1
https://bugs.launchpad.net/python-heatclient/+bug/1427310

Which version of client do you use? Try to use code from master, it should
works.
Also one note: the best place for such questions is
openst...@lists.openstack.org or http://ask.openstack.org/. And of course
channel #heat in IRC.

Regards,
Sergey.

On 7 May 2015 at 23:43, Jay Reslock jresl...@gmail.com wrote:

 Hi,
 This is my first mail to the group.  I hope I set the subject correctly
 and that this hasn't been asked already.  I searched archives and did not
 see this question asked or answered previously.

 I am working on a client thing that uses the python-keystoneclient and
 python-heatclient api bindings to set up an authenticated session and then
 use that session to talk to the heat service.  This doesn't work for heat
 but does work for other services such as nova and sahara.  Is this because
 sessions aren't supported in the heatclient api yet?

 sample code:

 https://gist.github.com/jreslock/a525abdcce53ca0492a7

 I'm using fabric to define tasks so I can call them via another tool.
 When I run the task I get:

 TypeError: Client() takes at least 1 argument (0 given)

 The documentation does not say anything about being able to pass session
 to the heatclient but the others seem to work.  I just want to know if this
 is intended/expected behavior or not.

 -Jason

 __
 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] [QA][Glance][Heat][Cinder] Removing the CLI tests from Tempest

[Sergey Kraynev]

Hi guys.

Probably we have missed this activity, so I start working on it.
These are first commits:

https://review.openstack.org/#/c/180215/

Regards,
Sergey.

On 30 April 2015 at 19:55, Matthew Treinish mtrein...@kortar.org wrote:

 On Thu, Apr 30, 2015 at 05:44:40PM +0100, Louis Taylor wrote:
  On Thu, Apr 30, 2015 at 12:28:15PM -0400, Matthew Treinish wrote:
   We're now at the end of the cycle and there are 3 clients that still
 have CLI
   tests in tempest. I have pushed the patch up to remove all these tests
 here:
  
   https://review.openstack.org/#/c/178757/
 
  Hi Matt,
 
  This is being worked on in glance (infra patch adding test job:
  https://review.openstack.org/#/c/178285/). It will likely be finished
 before
  you remove the tests from tempest, so your current plan for removal
 sounds okay
  for us.
 

 Oh, cool I didn't realize that was in progress for glance already. Thanks
 for
 driving it forward.

 I guess it's probably worth pointing out that John Griffith has similar
 patches
 in progress starting the process on cinderclient too:

 https://review.openstack.org/175521

 and

 https://review.openstack.org/175512


 Thanks,

 Matt Treinish

 __
 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] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

[Sergey Kraynev]

@VACHNIS:  yeah. in this case we blocked by ceilometer. AFAIK, ceilometer
collect metrics from Nova:Server, not from docker directly.
So mentioned bp is make sense (add support for this feature to ceilomete,
then to heat).


Regards,
Sergey.

On 17 April 2015 at 17:11, VACHNIS, AVI (AVI) 
avi.vach...@alcatel-lucent.com wrote:

  Hi,

 @Ashish, if the limitation you've mentioned for #1 still exists, I join
 your question how heat auto-scale-group may work w/o ceilometer being able
 to collect docker metrics?



 @Sergey, hey. Are you saying that ceilometer do collects metrics on docker
 underlying nova::server resource?







 -Avi



 -- Original message--

 *From: *ashish.jai...@wipro.com

 *Date: *Fri, Apr 17, 2015 4:56 PM

 *To: *openstack-dev@lists.openstack.org;

 *Subject:*Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling
 docker in openstack



 Hi Segey,


  So IIUC approach #2 may still help to autoscale docker on openstack. I
 will try that out and post questions on heat irc thanks.


  Regards

 Ashish
  --
 *From:* Sergey Kraynev skray...@mirantis.com
 *Sent:* Friday, April 17, 2015 7:01 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [nova-docker][ceilometer][heat]
 Autoscaling docker in openstack

   Hi, Ashish.

  Honestly I am not familiar with most part of these ways, but can add
 more information from Heat side (item 2).

  I am surprised, that you have missed Heat autoscaling mechanism (You
 should look it :) ). It's one of the important part of Heat project.
 It allows to scale vms/stacks by using Ceilometer alarms. There are couple
 examples of autoscale templates:


 https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml  
(with
 LoadBalancer)

 https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml

 https://github.com/openstack/heat-templates/blob/master/hot/asg_of_stacks.yaml

 https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml


 https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml
 It's true, that Docker plugin for Heat create docker server on
 Nova::Server resource. So you may write template Docker resource + Server
 resource (similar on third template) and scale by using Ceilometer alarms.
 If you have any questions how to use it, please got to #heat irc channel
 and ask us :)
 Also another way (AFAIK) is to use SoftwareDeployment/Config and deploy
 Server with docker inside (without docker plugin). In this way, I suppose,
 Steve Baker can help with advise :)


 On 17 April 2015 at 16:06, ashish.jai...@wipro.com wrote:


 Hi,

 I have been working on running docker on openstack. I had a discussion on
 multiple IRC and IIUC there are 5 different ways of running docker on
 openstack. IIUC currently there is no way to autoscale docker on openstack.
 Please correct me if I am wrong


 1) Using nova-docker driver - Running docker as a Nova::Server using
 nova-docker hypervisor
 2) Using nova-plugin for heat - Running docker using
 DockerInc::Docker::Container
 3) Using magnum - IIUC no automation as of now, manually it is possible.
 Not enough documentation available
 4) heat compose - Saw some samples available @
 https://github.com/openstack/heat-templates/tree/master/hot/software-config/elements/heat-config-docker-compose
 5) Swarm support - Still in development

 Issues with each on the above approaches

 1) Using nova-docker driver - IIUC there is no way for ceilometer to
 collect and emit statistics for docker hypervisor. So that mean ceilometer
 does not have any stats available once you switch to docker driver.
 This link (
 https://github.com/openstack/ceilometer/tree/master/ceilometer/compute/virt)
 currently does not have anything for docker hypervisor.

 2) Using nova-plugin for heat - Using this approach docker containers run
 on a Nova VM. However I do not see any illustration which suggests that you
 can autoscale using this approach.

 3) Using magnum - Currently only possible by manually invoking it.

 4) heat compose - Sample available at the above link just talks about
 deploying it up but nothing about auto scaling

 5) Swarm Support - Still in dev

 While I understand some of these options may enable us during the future
 release to autoscale docker on openstack. But looking currently I feel
 option #1 is most mature(probably) and by plugging in a ceilometer
 inspector for docker hypervisor it may be possible. Another approach could
 be to using cfn-push-stats to probably push some stats from docker
 container.

 Please advice through your valued suggestions that time being what is the
 best way to achieve auto scaling for docker on openstack. I am ready to
 contribute to it in the best possible way.

 Regards
 Ashish






 The information contained in this electronic message and any attachments
 to this message are intended for the exclusive use

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

[Sergey Kraynev]

Hi, Ashish.

Honestly I am not familiar with most part of these ways, but can add more
information from Heat side (item 2).

I am surprised, that you have missed Heat autoscaling mechanism (You should
look it :) ). It's one of the important part of Heat project.
It allows to scale vms/stacks by using Ceilometer alarms. There are couple
examples of autoscale templates:

https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml
   (with LoadBalancer)
https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml
https://github.com/openstack/heat-templates/blob/master/hot/asg_of_stacks.yaml
https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml

https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml
It's true, that Docker plugin for Heat create docker server on Nova::Server
resource. So you may write template Docker resource + Server resource
(similar on third template) and scale by using Ceilometer alarms.
If you have any questions how to use it, please got to #heat irc channel
and ask us :)
Also another way (AFAIK) is to use SoftwareDeployment/Config and deploy
Server with docker inside (without docker plugin). In this way, I suppose,
Steve Baker can help with advise :)


On 17 April 2015 at 16:06, ashish.jai...@wipro.com wrote:


 Hi,

 I have been working on running docker on openstack. I had a discussion on
 multiple IRC and IIUC there are 5 different ways of running docker on
 openstack. IIUC currently there is no way to autoscale docker on openstack.
 Please correct me if I am wrong


 1) Using nova-docker driver - Running docker as a Nova::Server using
 nova-docker hypervisor
 2) Using nova-plugin for heat - Running docker using
 DockerInc::Docker::Container
 3) Using magnum - IIUC no automation as of now, manually it is possible.
 Not enough documentation available
 4) heat compose - Saw some samples available @
 https://github.com/openstack/heat-templates/tree/master/hot/software-config/elements/heat-config-docker-compose
 5) Swarm support - Still in development

 Issues with each on the above approaches

 1) Using nova-docker driver - IIUC there is no way for ceilometer to
 collect and emit statistics for docker hypervisor. So that mean ceilometer
 does not have any stats available once you switch to docker driver.
 This link (
 https://github.com/openstack/ceilometer/tree/master/ceilometer/compute/virt)
 currently does not have anything for docker hypervisor.

 2) Using nova-plugin for heat - Using this approach docker containers run
 on a Nova VM. However I do not see any illustration which suggests that you
 can autoscale using this approach.

 3) Using magnum - Currently only possible by manually invoking it.

 4) heat compose - Sample available at the above link just talks about
 deploying it up but nothing about auto scaling

 5) Swarm Support - Still in dev

 While I understand some of these options may enable us during the future
 release to autoscale docker on openstack. But looking currently I feel
 option #1 is most mature(probably) and by plugging in a ceilometer
 inspector for docker hypervisor it may be possible. Another approach could
 be to using cfn-push-stats to probably push some stats from docker
 container.

 Please advice through your valued suggestions that time being what is the
 best way to achieve auto scaling for docker on openstack. I am ready to
 contribute to it in the best possible way.

 Regards
 Ashish






 The information contained in this electronic message and any attachments
 to this message are intended for the exclusive use of the addressee(s) and
 may contain proprietary, confidential or privileged information. If you are
 not the intended recipient, you should not disseminate, distribute or copy
 this e-mail. Please notify the sender immediately and destroy all copies of
 this message and any attachments. WARNING: Computer viruses can be
 transmitted via email. The recipient should check this email and any
 attachments for the presence of viruses. The company accepts no liability
 for any damage caused by any virus transmitted by this email.
 www.wipro.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] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

[Sergey Kraynev]

Let's wait more opinions ;) I don;t think that we know everything.

Regards,
Sergey.

On 17 April 2015 at 18:10, ashish.jai...@wipro.com wrote:

  So ultimately this means there is no way to autoscale docker containers
 on openstack until and unless ceilometer adds an inspector for docker
 hypervisor something similar to this (
 https://github.com/openstack/ceilometer/tree/master/ceilometer/compute/virt
 ).


  Regards

 Ashish
  --
 *From:* Sergey Kraynev skray...@mirantis.com
 *Sent:* Friday, April 17, 2015 8:12 PM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [nova-docker][ceilometer][heat]
 Autoscaling docker in openstack

   @VACHNIS:  yeah. in this case we blocked by ceilometer. AFAIK,
 ceilometer collect metrics from Nova:Server, not from docker directly.
  So mentioned bp is make sense (add support for this feature to
 ceilomete, then to heat).


  Regards,
 Sergey.

 On 17 April 2015 at 17:11, VACHNIS, AVI (AVI) 
 avi.vach...@alcatel-lucent.com wrote:

  Hi,

 @Ashish, if the limitation you've mentioned for #1 still exists, I join
 your question how heat auto-scale-group may work w/o ceilometer being able
 to collect docker metrics?



 @Sergey, hey. Are you saying that ceilometer do collects metrics on
 docker underlying nova::server resource?







 -Avi



 -- Original message--

 *From: *ashish.jai...@wipro.com

 *Date: *Fri, Apr 17, 2015 4:56 PM

 *To: *openstack-dev@lists.openstack.org;

 *Subject:*Re: [openstack-dev] [nova-docker][ceilometer][heat]
 Autoscaling docker in openstack



 Hi Segey,


  So IIUC approach #2 may still help to autoscale docker on openstack. I
 will try that out and post questions on heat irc thanks.


  Regards

 Ashish
  --
 *From:* Sergey Kraynev skray...@mirantis.com
 *Sent:* Friday, April 17, 2015 7:01 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [nova-docker][ceilometer][heat]
 Autoscaling docker in openstack

   Hi, Ashish.

  Honestly I am not familiar with most part of these ways, but can add
 more information from Heat side (item 2).

  I am surprised, that you have missed Heat autoscaling mechanism (You
 should look it :) ). It's one of the important part of Heat project.
 It allows to scale vms/stacks by using Ceilometer alarms. There are
 couple examples of autoscale templates:


 https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml 
 (with
 LoadBalancer)

 https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml

 https://github.com/openstack/heat-templates/blob/master/hot/asg_of_stacks.yaml

 https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml


 https://github.com/openstack/heat-templates/blob/master/hot/asg_of_servers.yaml
 It's true, that Docker plugin for Heat create docker server on
 Nova::Server resource. So you may write template Docker resource + Server
 resource (similar on third template) and scale by using Ceilometer alarms.
 If you have any questions how to use it, please got to #heat irc channel
 and ask us :)
 Also another way (AFAIK) is to use SoftwareDeployment/Config and deploy
 Server with docker inside (without docker plugin). In this way, I suppose,
 Steve Baker can help with advise :)


 On 17 April 2015 at 16:06, ashish.jai...@wipro.com wrote:


 Hi,

 I have been working on running docker on openstack. I had a discussion
 on multiple IRC and IIUC there are 5 different ways of running docker on
 openstack. IIUC currently there is no way to autoscale docker on openstack.
 Please correct me if I am wrong


 1) Using nova-docker driver - Running docker as a Nova::Server using
 nova-docker hypervisor
 2) Using nova-plugin for heat - Running docker using
 DockerInc::Docker::Container
 3) Using magnum - IIUC no automation as of now, manually it is possible.
 Not enough documentation available
 4) heat compose - Saw some samples available @
 https://github.com/openstack/heat-templates/tree/master/hot/software-config/elements/heat-config-docker-compose
 5) Swarm support - Still in development

 Issues with each on the above approaches

 1) Using nova-docker driver - IIUC there is no way for ceilometer to
 collect and emit statistics for docker hypervisor. So that mean ceilometer
 does not have any stats available once you switch to docker driver.
 This link (
 https://github.com/openstack/ceilometer/tree/master/ceilometer/compute/virt)
 currently does not have anything for docker hypervisor.

 2) Using nova-plugin for heat - Using this approach docker containers
 run on a Nova VM. However I do not see any illustration which suggests that
 you can autoscale using this approach.

 3) Using magnum - Currently only possible by manually invoking it.

 4) heat compose - Sample available at the above link just talks about
 deploying it up but nothing about auto scaling

 5) Swarm Support

[openstack-dev] [Heat][Horizon] What we can do for Heat in Horizon else?

[Sergey Kraynev]

Hi community.

I want to ask feedback from our Heat team and also involve Horizon team in
this discussion.
AFAIK during Kilo was implemented bp:
https://blueprints.launchpad.net/horizon/+spec/heat-ui-improvement

This bp add more base Heat functionality to Horizon.
I asked some ideas from Heat guys. What we want to have here else ?

There is only one idea for me about topology:
create some filters for displaying only particular resources (by their type)
F.e. stack has 50 resources, but there is half of them network resources.
As user I want to see only network level, so I enable filtering by network
resources.


Regards,
Sergey.
__
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] [Ceilometer] [rc1] bug is unresolved due to requirements freeze

[Sergey Kraynev]

Hi Guys.


 A couple of concerns:

 #1 - would have been really nice if the commit message for the review
 included the above block of text. The current commit message is not
 clear that Heat *can not* work.


I will update commit message regarding info mentioned in this thread.



 #2 - why wasn't the fact that Heat *can not* work raised earlier,
 because I assume that means there are tests that are blocking all kinds
 of changes?


The reason, why we don't tell it early is:
 when issue was found we ask ceilometer team to bump new version,
after that I uploaded patch to global-requirements and believed that it
will be merged before release.
It does not block gates (due to reason mentioned above), but the reality is
so, that with 1.0.12 version
user can not use any ceilometer resources in Heat (as result we loose
autoscaling templates, where ceilometer plays one of major roles).



 If this is truly blocking we can raise with Thierry, he has final
 override here. However, if this means that one resource type doesn't
 work quite as expected, I don't think that warrants a freeze bump. The
 libraries are set to = here so nothing in Kilo that prevents users from
 deciding to take that upgrade.

 Forcing that upgrade on all users for 1 use case which a user may or may
 not be using is not the point of GR.

 -Sean

 --
 Sean Dague
 http://dague.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



Regards,
Sergey.
__
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] Stepping down from core

[Sergey Kraynev]

Thank you for the great contribution. Good luck in your new endeavors :)

Regards,
Sergey.

On 27 February 2015 at 23:23, Jeff Peeler jpee...@redhat.com wrote:

 As discussed during the previous Heat meeting, I'm going to be stepping
 down from core on the Heat project. My day to day focus is going to be more
 focused on TripleO for the foreseeable future, and I hope to be able to
 soon focus on reviews there.

 Being part of Heat core since day 0 has been a good experience, but
 keeping up with multiple projects is a lot to manage. I don't know how some
 of you do it!

 Jeff

 __
 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] [heat] operators vs users for choosing convergence engine

[Sergey Kraynev]

I really like some benefits of this approach:
 - easy use in functional tests (did not require additional job)
 - every user can try from this moment
 - we can use both code ways in the same time without service restarting

So I really close to give my +1, if someone give answers on questions from
other side:
 - as Angus said, how we plan deprecate it then (when new code will become
default) more softer for users?
 - As I understand the parameter option will have upper priority then
config.
   so operator has not way to block it from users and they should decide
themselves what they want (what is more safely)? (and of course choose new,
because it sounds better)
 - I really afraid, that some users will start use new option and will be
disappointed, due to they expect a lot of benefits, but the reality will be
different.
   IMO, exposing so young feature looks cool for development part and
gathering feedback, but dangerous for stable product users + bad example
of commercial.

If somebody help me to remove these doubts, I will be thankful to him :)

Regards,
Sergey.

On 3 February 2015 at 03:52, Steve Baker sba...@redhat.com wrote:

 A spec has been raised to add a config option to allow operators to choose
 whether to use the new convergence engine for stack operations. For some
 context you should read the spec first [1]

 Rather than doing this, I would like to propose the following:
 * Users can (optionally) choose which engine to use by specifying an
 engine parameter on stack-create (choice of classic or convergence)
 * Operators can set a config option which determines which engine to use
 if the user makes no explicit choice
 * Heat developers will set the default config option from classic to
 convergence when convergence is deemed sufficiently mature

 I realize it is not ideal to expose this kind of internal implementation
 detail to the user, but choosing convergence _will_ result in different
 stack behaviour (such as multiple concurrent update operations) so there is
 an argument for giving the user the choice. Given enough supporting
 documentation they can choose whether convergence might be worth trying for
 a given stack (for example, a large stack which receives frequent updates)

 Operators likely won't feel they have enough knowledge to make the call
 that a heat install should be switched to using all convergence, and users
 will never be able to try it until the operators do (or the default
 switches).

 Finally, there are also some benefits to heat developers. Creating a whole
 new gate job to test convergence-enabled heat will consume its share of CI
 resource. I'm hoping to make it possible for some of our functional tests
 to run against a number of scenarios/environments. Being able to run tests
 under classic and convergence scenarios in one test run will be a great
 help (for performance profiling too).

 If there is enough agreement then I'm fine with taking over and updating
 the convergence-config-option spec.

 [1] https://review.openstack.org/#/c/152301/2/specs/kilo/
 convergence-config-option.rst

 __
 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] [Heat] core team changes

[Sergey Kraynev]

+1

Regards,
Sergey.

On 28 January 2015 at 10:52, Pavlo Shchelokovskyy 
pshchelokovs...@mirantis.com wrote:

 +1

 Pavlo Shchelokovskyy
 Software Engineer
 Mirantis Inc
 www.mirantis.com

 On Wed, Jan 28, 2015 at 8:26 AM, Thomas Herve thomas.he...@enovance.com
 wrote:


  Hi all
 
  After having a look at the stats:
  http://stackalytics.com/report/contribution/heat-group/90
  http://stackalytics.com/?module=heat-groupmetric=person-day
 
  I'd like to propose the following changes to the Heat core team:
 
  Add:
  Qiming Teng
  Huang Tianhua
 
  Remove:
  Bartosz Górski (Bartosz has indicated that he is happy to be removed and
  doesn't have the time to work on heat ATM).
 
  Core team please respond with +/- 1.
 
  Thanks
  Angus

 +1!

 --
 Thomas


 __
 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] [Heat] Convergence Phase 1 implementation plan

[Sergey Kraynev]

On 24 January 2015 at 00:00, Zane Bitter zbit...@redhat.com wrote:

 I've mentioned this in passing a few times, but I want to lay it out here
 in a bit more detail for comment. Basically we're implementing convergence
 at a time when we still have a lot of 'unit' tests that are really
 integration tests, and we don't want to have to rewrite them to anticipate
 this new architecture, nor wait until they have all been converted into
 functional tests. And of course it goes without saying that we have to land
 all of these changes without breaking anything for users.

 To those ends, my proposal is that we (temporarily) support two code
 paths: the existing, legacy in-memory path and the new, distributed
 convergence path. Stacks will contain a field indicating which code path
 they were created with, and each stack will be operated on only by that
 same code path throughout its lifecycle (i.e. a stack created in legacy
 mode will always use the legacy code). We'll add a config option, off by
 default, to enable the new code path. That way users can switch over at a
 time of their choosing. When we're satisfied that it's stable enough we can
 flip the default (note: IMHO this would have to happen before kilo-3 in
 order to make it for the Kilo release).

 Based on this plan, I had a go at breaking the work down into discrete
 tasks, and because it turned out to be really long I put it in an etherpad
 rather than include it here:

 https://etherpad.openstack.org/p/heat-convergence-tasks

 If anyone has additions/changes then I suggest adding them to that
 etherpad and replying to this message to flag your changes.


I do not want to be assertive and greedy, so I toke several task, which IMO
are not required a lot of time for implementation and deep understanding
tricky things :) (Marked them on etherpad)
Also I don't want to steal work from guys who designed whole staff with
you. I think, that we could take more tasks later, when other volunteers
will be satisfied. I believe, that work will be enough for everyone. :)




 To be clear, it's unlikely I will have time to do the implementation work
 on any of these tasks myself (although I will be trying to review as many
 of them as possible). So the goal here is to get as many contributors
 involved in doing stuff in parallel as we can.

 There are obviously dependencies between many of these tasks, so my plan
 is to raise each one as a blueprint so we can see the magic picture that
 Launchpad shows. I want to get feedback first though, because there are 18
 of them so far, and rejigging everything in response to feedback would be a
 bit of a pain.

 I'm also prepared to propose specs for all of these _if_ people think that
 would be helpful. I see three options here:
  - Propose 18 fairly minimal specs (maybe in a single review?)
  - Propose 1 large spec (essentially the contents of that etherpad)
  - Just discuss in the etherpad rather than Gerrit


I tend to choose etherpad, because it makes review and discussion faster.
(i.e. all in one place is easier for reading and referencing).


 Obviously that's in decreasing order of the amount of work required, but
 I'll do whatever folks think best for discussion.

 cheers,
 Zane.

 __
 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,
Sergey.
__
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] Remove deprecation properties

[Sergey Kraynev]

Short summarize of discussion in email thread and IRC:

1. We plan to add follow information for property/attribute in release
notes.
- Deprecated in Juno
- Announce planned removal in Kilo release notes
- Remove in J  (I.e. we will return validation error on all templates
with this property)

2. Some improvements for Deprecation status code:
 - Add separate parameter Deprecated_Since (optionally may be added two
mentioned above - planned_removal, remove)

3. Add option in attr/prop schema:
property_schema = {
subnet:
  
  old_names (or something like that) = subnet_id
}

4. Add migration mechanism:
When user use old template, property automatically translated to the new
name.

Regards,
Sergey.

On 19 January 2015 at 14:51, Sergey Kraynev skray...@mirantis.com wrote:


 On 19 January 2015 at 05:13, Angus Salkeld asalk...@mirantis.com wrote:

 On Fri, Jan 16, 2015 at 11:10 PM, Sergey Kraynev skray...@mirantis.com
 wrote:

 Steve, Thanks for the feedback.

 On 16 January 2015 at 15:09, Steven Hardy sha...@redhat.com wrote:

 On Thu, Dec 25, 2014 at 01:52:43PM +0400, Sergey Kraynev wrote:
 Hi all.
 In the last time we got on review several patches, which removes
 old
 deprecation properties [1],A
 and one mine [2].
 The aim is to delete deprecated code and redundant tests. It looks
 simple,
 but the main problem, which we met, is backward compatibility.
 F.e. user has created resource (FIP) with old property schema,
 i.e. using
 SUBNET_ID instead of SUBNET. On first look nothing bad will not
 happen,
 because:

 FWIW I think it's too soon to remove the Neutron subnet_id/network_id
 properties, they were only deprecated in Juno [1], and it's evident that
 users are still using them on icehouse [2]

 I thought the normal deprecation cycle was at least two releases, but I
 can't recall where I read that.  Considering the overhead of maintaining
 these is small, I'd favour leaning towards giving more time for users to
 update their templates, rather then breaking them via very aggresive
 removal of deprecated interfaces.


 Honestly I thought, that we use 1 release cycle, but I have not any
 objections to do it after two releases.
 Will  be glad to know what is desired deprecation period.



 I'd suggest some or all of the following:

 - Add a planned for removal in $release to the SupportStatus string
   associated with the deprecation, so we can document the planned
 removal.
 - Wait for at least two releases between deprecation and removal, and
   announce the interfaces which will be removed in the release notes for
   the release before removal e.g:
 - Deprecated in Juno
 - Announce planned removal in Kilo release notes
 - Remove in J


 I like this idea, IMO it will make our deprecation process clear.





 [1] https://review.openstack.org/#/c/82853/
 [2]
 http://lists.openstack.org/pipermail/openstack/2015-January/011156.html

 1. handle_delete use resource_id and any changes in property
 schema does
 not affect other actions.
 2. If user want to use old template, he will get adequate error
 message,
 that this property is not presented in schema. After that he just
 should
 switch to new property and update stack using this new property.
 In the same time we have one big issues for shadow dependencies,
 which is
 actual for neutron resources. The simplest approach will not be
 worked
 [3], due to old properties was deleted from property_schema.
 Why is it bad ?
 - we will get again all bugs related with such dependencies.
 - how to make sure:A
 A  A  - create stack with old property (my template [4])
 A  A  - open horizon, and look on topology
 A  A  - download patch [2] and restart engine
 A  A  - reload horizon page with topology
 A  A  - as result it will be different
 A
 I have some ideas about how to solve this, but none of them is not
 enough
 good for me:
 A - getting such information from self.properties.data is bad,
 because we
 will skip all validations mentioned in properties.__getitem__
 A - renaming old key in data to new or creating copy with new key
 is not
 correct for me, because in this case we actually change properties
 (resource representation) invisibly from user.
 A - as possible we may leave old deprecated property and mark it
 something
 like (removed), which will have similar behavior such as for
 implemented=False. I do not like it, because it means, that we
 never
 remove this support code, because wants to be compatible with old
 resources. (User may be not very lazy to do simple update or
 something
 else ...)
 - last way, which I have not tried yet, is usingA
 _stored_properties_data
 forA extraction necessary information.
 So now I have the questions:
 Should we support such case with backward compatibility?A
 If yes, how will be better to do it for us and user

Re: [openstack-dev] [heat] Remove deprecation properties

[Sergey Kraynev]

On 19 January 2015 at 05:13, Angus Salkeld asalk...@mirantis.com wrote:

 On Fri, Jan 16, 2015 at 11:10 PM, Sergey Kraynev skray...@mirantis.com
 wrote:

 Steve, Thanks for the feedback.

 On 16 January 2015 at 15:09, Steven Hardy sha...@redhat.com wrote:

 On Thu, Dec 25, 2014 at 01:52:43PM +0400, Sergey Kraynev wrote:
 Hi all.
 In the last time we got on review several patches, which removes old
 deprecation properties [1],A
 and one mine [2].
 The aim is to delete deprecated code and redundant tests. It looks
 simple,
 but the main problem, which we met, is backward compatibility.
 F.e. user has created resource (FIP) with old property schema, i.e.
 using
 SUBNET_ID instead of SUBNET. On first look nothing bad will not
 happen,
 because:

 FWIW I think it's too soon to remove the Neutron subnet_id/network_id
 properties, they were only deprecated in Juno [1], and it's evident that
 users are still using them on icehouse [2]

 I thought the normal deprecation cycle was at least two releases, but I
 can't recall where I read that.  Considering the overhead of maintaining
 these is small, I'd favour leaning towards giving more time for users to
 update their templates, rather then breaking them via very aggresive
 removal of deprecated interfaces.


 Honestly I thought, that we use 1 release cycle, but I have not any
 objections to do it after two releases.
 Will  be glad to know what is desired deprecation period.



 I'd suggest some or all of the following:

 - Add a planned for removal in $release to the SupportStatus string
   associated with the deprecation, so we can document the planned
 removal.
 - Wait for at least two releases between deprecation and removal, and
   announce the interfaces which will be removed in the release notes for
   the release before removal e.g:
 - Deprecated in Juno
 - Announce planned removal in Kilo release notes
 - Remove in J


 I like this idea, IMO it will make our deprecation process clear.





 [1] https://review.openstack.org/#/c/82853/
 [2]
 http://lists.openstack.org/pipermail/openstack/2015-January/011156.html

 1. handle_delete use resource_id and any changes in property schema
 does
 not affect other actions.
 2. If user want to use old template, he will get adequate error
 message,
 that this property is not presented in schema. After that he just
 should
 switch to new property and update stack using this new property.
 In the same time we have one big issues for shadow dependencies,
 which is
 actual for neutron resources. The simplest approach will not be
 worked
 [3], due to old properties was deleted from property_schema.
 Why is it bad ?
 - we will get again all bugs related with such dependencies.
 - how to make sure:A
 A  A  - create stack with old property (my template [4])
 A  A  - open horizon, and look on topology
 A  A  - download patch [2] and restart engine
 A  A  - reload horizon page with topology
 A  A  - as result it will be different
 A
 I have some ideas about how to solve this, but none of them is not
 enough
 good for me:
 A - getting such information from self.properties.data is bad,
 because we
 will skip all validations mentioned in properties.__getitem__
 A - renaming old key in data to new or creating copy with new key
 is not
 correct for me, because in this case we actually change properties
 (resource representation) invisibly from user.
 A - as possible we may leave old deprecated property and mark it
 something
 like (removed), which will have similar behavior such as for
 implemented=False. I do not like it, because it means, that we never
 remove this support code, because wants to be compatible with old
 resources. (User may be not very lazy to do simple update or
 something
 else ...)
 - last way, which I have not tried yet, is usingA
 _stored_properties_data
 forA extraction necessary information.
 So now I have the questions:
 Should we support such case with backward compatibility?A
 If yes, how will be better to do it for us and user?
 May be we should create some strategy forA removingA A deprecated
 properties ?

 Yeah, other than the process issues I mentioned above, Angus has pointed
 out some technical challenges which may mean property removal breaks
 existing stacks.  IMHO this is something we *cannot* do - folks must be
 able to upgrade heat over multiple versions without breaking their
 stacks.

 As you say, delete may work, but it's likely several scenarios around
 update will break if the stored stack definition doesn't match the schema
 of the resource, and maintaining the internal references to removed or
 obsolete properties doesn't seem like a good plan long term.

 Could we provide some sort of migration tool, which re-writes the
 definition of existing stacks (via a special patch stack update maybe

Re: [openstack-dev] [heat] Remove deprecation properties

[Sergey Kraynev]

Steve, Thanks for the feedback.

On 16 January 2015 at 15:09, Steven Hardy sha...@redhat.com wrote:

 On Thu, Dec 25, 2014 at 01:52:43PM +0400, Sergey Kraynev wrote:
 Hi all.
 In the last time we got on review several patches, which removes old
 deprecation properties [1],A
 and one mine [2].
 The aim is to delete deprecated code and redundant tests. It looks
 simple,
 but the main problem, which we met, is backward compatibility.
 F.e. user has created resource (FIP) with old property schema, i.e.
 using
 SUBNET_ID instead of SUBNET. On first look nothing bad will not
 happen,
 because:

 FWIW I think it's too soon to remove the Neutron subnet_id/network_id
 properties, they were only deprecated in Juno [1], and it's evident that
 users are still using them on icehouse [2]

 I thought the normal deprecation cycle was at least two releases, but I
 can't recall where I read that.  Considering the overhead of maintaining
 these is small, I'd favour leaning towards giving more time for users to
 update their templates, rather then breaking them via very aggresive
 removal of deprecated interfaces.


Honestly I thought, that we use 1 release cycle, but I have not any
objections to do it after two releases.
Will  be glad to know what is desired deprecation period.



 I'd suggest some or all of the following:

 - Add a planned for removal in $release to the SupportStatus string
   associated with the deprecation, so we can document the planned removal.
 - Wait for at least two releases between deprecation and removal, and
   announce the interfaces which will be removed in the release notes for
   the release before removal e.g:
 - Deprecated in Juno
 - Announce planned removal in Kilo release notes
 - Remove in J


I like this idea, IMO it will make our deprecation process clear.





 [1] https://review.openstack.org/#/c/82853/
 [2]
 http://lists.openstack.org/pipermail/openstack/2015-January/011156.html

 1. handle_delete use resource_id and any changes in property schema
 does
 not affect other actions.
 2. If user want to use old template, he will get adequate error
 message,
 that this property is not presented in schema. After that he just
 should
 switch to new property and update stack using this new property.
 In the same time we have one big issues for shadow dependencies,
 which is
 actual for neutron resources. The simplest approach will not be worked
 [3], due to old properties was deleted from property_schema.
 Why is it bad ?
 - we will get again all bugs related with such dependencies.
 - how to make sure:A
 A  A  - create stack with old property (my template [4])
 A  A  - open horizon, and look on topology
 A  A  - download patch [2] and restart engine
 A  A  - reload horizon page with topology
 A  A  - as result it will be different
 A
 I have some ideas about how to solve this, but none of them is not
 enough
 good for me:
 A - getting such information from self.properties.data is bad,
 because we
 will skip all validations mentioned in properties.__getitem__
 A - renaming old key in data to new or creating copy with new key is
 not
 correct for me, because in this case we actually change properties
 (resource representation) invisibly from user.
 A - as possible we may leave old deprecated property and mark it
 something
 like (removed), which will have similar behavior such as for
 implemented=False. I do not like it, because it means, that we never
 remove this support code, because wants to be compatible with old
 resources. (User may be not very lazy to do simple update or something
 else ...)
 - last way, which I have not tried yet, is usingA
 _stored_properties_data
 forA extraction necessary information.
 So now I have the questions:
 Should we support such case with backward compatibility?A
 If yes, how will be better to do it for us and user?
 May be we should create some strategy forA removingA A deprecated
 properties ?

 Yeah, other than the process issues I mentioned above, Angus has pointed
 out some technical challenges which may mean property removal breaks
 existing stacks.  IMHO this is something we *cannot* do - folks must be
 able to upgrade heat over multiple versions without breaking their stacks.

 As you say, delete may work, but it's likely several scenarios around
 update will break if the stored stack definition doesn't match the schema
 of the resource, and maintaining the internal references to removed or
 obsolete properties doesn't seem like a good plan long term.

 Could we provide some sort of migration tool, which re-writes the
 definition of existing stacks (via a special patch stack update maybe?)
 before upgrading heat?


Yeah, I thought about it. Probably it's good solution for upgrading.
However one thing stops me to start doing it right now:
If we upgrade

[openstack-dev] [heat] Remove deprecation properties

[Sergey Kraynev]

Hi all.

In the last time we got on review several patches, which removes old
deprecation properties [1],
and one mine [2].

The aim is to delete deprecated code and redundant tests. It looks simple,
but the main problem, which we met, is backward compatibility.
F.e. user has created resource (FIP) with old property schema, i.e. using
SUBNET_ID instead of SUBNET. On first look nothing bad will not happen,
because:
1. handle_delete use resource_id and any changes in property schema does
not affect other actions.
2. If user want to use old template, he will get adequate error message,
that this property is not presented in schema. After that he just should
switch to new property and update stack using this new property.

In the same time we have one big issues for shadow dependencies, which is
actual for neutron resources. The simplest approach will not be worked [3],
due to old properties was deleted from property_schema.

Why is it bad ?
- we will get again all bugs related with such dependencies.
- how to make sure:
- create stack with old property (my template [4])
- open horizon, and look on topology
- download patch [2] and restart engine
- reload horizon page with topology
- as result it will be different

I have some ideas about how to solve this, but none of them is not enough
good for me:
 - getting such information from self.properties.data is bad, because we
will skip all validations mentioned in properties.__getitem__
 - renaming old key in data to new or creating copy with new key is not
correct for me, because in this case we actually change properties
(resource representation) invisibly from user.
 - as possible we may leave old deprecated property and mark it something
like (removed), which will have similar behavior such as for
implemented=False. I do not like it, because it means, that we never remove
this support code, because wants to be compatible with old resources.
(User may be not very lazy to do simple update or something else ...)
- last way, which I have not tried yet, is using _stored_properties_data
for extraction necessary information.

So now I have the questions:
Should we support such case with backward compatibility?
If yes, how will be better to do it for us and user?
May be we should create some strategy for removing  deprecated properties ?

[1]
https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:rm-depr-props,n,z
[2]  https://review.openstack.org/#/c/139990/7
[3]
https://review.openstack.org/#/c/139990/7/heat/engine/resources/neutron/floatingip.py
[4] http://paste.openstack.org/show/154591/

Regards,
Sergey.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Nominating Pavlo Shchelokovskyy for heat-core

[Sergey Kraynev]

+1

Regards,
Sergey.

On 7 October 2014 00:41, Zane Bitter zbit...@redhat.com wrote:

 I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core team.

 Pavlo has been a consistently active member of the Heat community - he's a
 regular participant in IRC and at meetings, has been making plenty of good
 commits[1] and maintains a very respectable review rate[2] with helpful
 comments. I think he's built up enough experience with the code base to be
 ready for core.

 Heat-cores, please vote by replying to this thread. As a reminder of your
 options[3], +1 votes from 5 cores is sufficient; a -1 is treated as a veto.

 cheers,
 Zane.

 [1] https://review.openstack.org/#/q/owner:%22Pavlo+
 Shchelokovskyy%22+status:merged+project:openstack/heat,n,z
 [2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt
 [3] https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_
 Removing_Members

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] heat.conf.sample is not up to date

[Sergey Kraynev]

Mike, I had same problem some time ago. The problem was that I had a vm
with installed devstack and file /etc/hosts contained string:

127.0.0.1   localhost ubuntu

and changing it to:

127.0.0.1   localhost

helped me. So we should have not any symbols (names) after localhost.

I am not sure that it's better solution (or may be it is wrong), but it
works for me.

Regards,
Sergey.


On 25 August 2014 08:22, Mike Spreitzer mspre...@us.ibm.com wrote:

 Ruslan Kamaldinov rkamaldi...@mirantis.com wrote on 08/24/2014 12:30:04
 PM:

  From: Ruslan Kamaldinov rkamaldi...@mirantis.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org,
  Date: 08/24/2014 12:32 PM
  Subject: Re: [openstack-dev] [heat] heat.conf.sample is not up to date
 
  On Sun, Aug 24, 2014 at 11:10 AM, Mike Spreitzer mspre...@us.ibm.com
 wrote:
   What I really need to know is what to do when committing a change that
   really does require a change in the sample configuration file.  Of
 course I
   tried running generate_sample.sh, but `tox -epep8` still complains.
  What is
   the right procedure to get a correct sample committed?  BTW, I am
 doing the
   following admittedly risky thing: I run DevStack, and make my changes
 in
   /opt/stack/heat/.
 
  Mike,
 
  It seems that you have oslo.messaging installed from master (default
  behavior of Devstack), while heat.sample.config is built for
  oslo.messaging v 1.3.1. As a quick workaround I'd suggest to downgrade
  oslo.messaging to 1.3.1 in pep8 virtual environment:
  $ cd /opt/stack/heat
  $ source .tox/pep8/bin/activate
  $ pip install oslo.messaging==1.3.1
  $ deactivate
  $ tox -e pep8 # should pass now

 In that same VM in which I ran DevStack, I also made an independent clone
 of heat in ~/code/heat; my original email quoted a failure from that clone,
 hoping that it might be easier to debug (being a simpler scenario).  Below
 is a typescript showing me try again there, including a trial of what
 Mathieu Gagné suggested (which has some kind of command line syntax error,
 and did nothing).  You will see that I investigated and found that in this
 case tox's venv contained oslo.messaging version 1.3.1, so no adjustment
 about that was needed.  Yet it still failed.

 ubuntu@mjs-dstk-821a:~/code/heat$ rm -rf .tox

 ubuntu@mjs-dstk-821a:~/code/heat$ tox -evenv bash
 ./tools/config/generate_sample.sh -b . -p heat -o etc/heat
 usage: tox [-h] [--version] [-v] [--showconfig] [-l] [-c CONFIGFILE]
[-e envlist] [--notest] [--sdistonly] [--installpkg PATH]
[--develop] [--set-home] [-i URL] [-r] [--result-json PATH]
[--hashseed SEED] [--force-dep REQ] [--sitepackages]
[--skip-missing-interpreters]
[args [args ...]]
 tox: error: unrecognized arguments: -b . -p heat -o etc/heat

 ubuntu@mjs-dstk-821a:~/code/heat$ tox -epep8
 pep8 create: /home/ubuntu/code/heat/.tox/pep8
 pep8 installdeps: -r/home/ubuntu/code/heat/requirements.txt,
 -r/home/ubuntu/code/heat/test-requirements.txt
 pep8 develop-inst: /home/ubuntu/code/heat
 pep8 runtests: PYTHONHASHSEED='0'
 pep8 runtests: commands[0] | flake8 heat bin/heat-api bin/heat-api-cfn
 bin/heat-api-cloudwatch bin/heat-engine bin/heat-manage contrib
 pep8 runtests: commands[1] |
 /home/ubuntu/code/heat/tools/config/check_uptodate.sh
 --- /tmp/heat.UnHAZD/heat.conf.sample2014-08-25 04:06:07.64884
 +
 +++ etc/heat/heat.conf.sample2014-08-24 06:53:51.54084 +
 @@ -159,10 +159,6 @@
  # Size of RPC connection pool. (integer value)
  #rpc_conn_pool_size=30

 -# Modules of exceptions that are permitted to be recreated
 -# upon receiving exception data from an rpc call. (list value)

 -#allowed_rpc_exception_modules=oslo.messaging.exceptions,nova.exception,cinder.exception,exceptions
 -
  # Qpid broker hostname. (string value)
  #qpid_hostname=heat

 @@ -301,15 +297,6 @@
  # Heartbeat time-to-live. (integer value)
  #matchmaker_heartbeat_ttl=600

 -# Host to locate redis. (string value)
 -#host=127.0.0.1
 -
 -# Use this port to connect to redis host. (integer value)
 -#port=6379
 -
 -# Password for Redis server (optional). (string value)
 -#password=None
 -
  # Size of RPC greenthread pool. (integer value)
  #rpc_thread_pool_size=64

 @@ -1229,6 +1216,22 @@
  #hash_algorithms=md5


 +[matchmaker_redis]
 +
 +#
 +# Options defined in oslo.messaging
 +#
 +
 +# Host to locate redis. (string value)
 +#host=127.0.0.1
 +
 +# Use this port to connect to redis host. (integer value)
 +#port=6379
 +
 +# Password for Redis server (optional). (string value)
 +#password=None
 +
 +
  [matchmaker_ring]

  #
 check_uptodate.sh: heat.conf.sample is not up to date.
 check_uptodate.sh: Please run
 /home/ubuntu/code/heat/tools/config/generate_sample.sh.
 ERROR: InvocationError:
 '/home/ubuntu/code/heat/tools/config/check_uptodate.sh'
 pep8 runtests: commands[2] |
 /home/ubuntu/code/heat/tools/requirements_style_check.sh requirements.txt
 

Re: [openstack-dev] [Heat] Live update of openstack

[Sergey Kraynev]

Added tag Heat

Regards,
Sergey.


On 1 August 2014 09:52, Manickam, Kanagaraj kanagaraj.manic...@hp.com
wrote:

  Hi,



 This mail is generic to all openstack service and explained the problem
 with respect to heat here.



 I have come across the situation where, updates are involved in the heat
 db model and corresponding code changes in the heat-engine component. Now
 assume that in a given deployment, there are two heat-engines and customer
 wants to update as follows:

 1.   Run db sync and update the first heat-engine and restart the
 heat-engine

 2.   Don’t touch the second heat-engine.



 In this scenario, first heat-engine will work properly as its updated with
 new db change done by the db sync. But second heat-engine is not updated
 and it will fail. To address this problem, would like to know if any other
 service came across the same scenario and a solution is already provided?
 Thanks.



 Regards

 Kanagaraj M

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] Uniform style of README file for contrib resources

[Sergey Kraynev]

Hello guys.

In the last time I meet again change related with changing content of
README for Docker resource.

https://review.openstack.org/#/c/110541/
https://review.openstack.org/#/c/101144/

Both changes try to improve current description.
I looked on other README files in contrib directories and met that all
instructions try to explain
information which is available here [1].
This and some other points pushed me on the follow ideas:

- Should we provide some commands like in docker's README which will add
required path to plugin_dirs ?

- Should we have several specific interpretations of [1] or will be better
to add reference on existing guide and
mention that some really specific notes?

- Should we leave empty sections? (For example, [2])

- Should we add README for barbican resources?

- How about one uniform template for README files?
I think that the right way to have list of allowed sections for README with
fixed names.
In my opinion it helps other developers and users with using all contrib
resources, because they will know what find
in each section.

I suggest to use follow structure (Note: if section is empty you just
should not use this section):

# Title with name of resource or for what this resource will be used
 (After this title you should provide description of resource)
## Resources - constant name. This section will  be used if plugin
directory contains more then one resource (F.e. rackspase resources)
# Installation   - constant name. What we should do for using this
plugin. (Possible will be enough to add link [1] instead sections below)
## Changes in configuration  - constant name. Which files and How we
should change them. (Possible will  be enough to add link [1])
## Restarting services - constant name. Names of services,
which should be restarted.
# Examples  - constant name. Section for
providing template examples (not full template, just definition of contrib
resource)
# Known issues  - constant name. All related issues.
# How it works - constant name. If you want to
tell some mechanism about this resource.
# Notes- constant name. Section for
information, which can not be classified for sections above.

I understand, that it's just README files, but I still think that it's
enough important for discussion. Hope on your thoughts.


[1]
https://wiki.openstack.org/wiki/Heat/Plugins#Installation_and_Configuration
[2] https://github.com/openstack/heat/tree/master/contrib/rackspace

Regards,
Sergey.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Uniform style of README file for contrib resources

[Sergey Kraynev]

On 30 July 2014 16:21, Angus Salkeld angus.salk...@rackspace.com wrote:

 On Wed, 2014-07-30 at 13:41 +0400, Sergey Kraynev wrote:
  Hello guys.
 
 
  In the last time I meet again change related with changing content of
  README for Docker resource.
 
 
 
  https://review.openstack.org/#/c/110541/

 I can ditch mine, just making a change after helping someone
 on IRC through it.


I don't mind about your change. It remembered me about current situation
with README files.




 
  https://review.openstack.org/#/c/101144/
 
 
 
  Both changes try to improve current description.
  I looked on other README files in contrib directories and met that all
  instructions try to explain
  information which is available here [1].
  This and some other points pushed me on the follow ideas:
 
 
  - Should we provide some commands like in docker's README which will
  add required path to plugin_dirs ?

 IMO no, it is really simple and this just makes it look harder than it
 is.

 
 
  - Should we have several specific interpretations of [1] or will be
  better to add reference on existing guide and
  mention that some really specific notes?
 
 
  - Should we leave empty sections? (For example, [2])
 
 
  - Should we add README for barbican resources?
 
 
  - How about one uniform template for README files?

 can't we just have one contrib/README (at least for the installing
 part)?



I wanted to suggest this way, but what about some specific keys
(keystone plugin require additional change in heat.conf).
And I correct understood that you offer to leave other information (not
installation) in own README files?



  I think that the right way to have list of allowed sections for README
  with fixed names.
  In my opinion it helps other developers and users with using all
  contrib resources, because they will know what find
  in each section.
 
 
  I suggest to use follow structure (Note: if section is empty you just
  should not use this section):
 
 
  # Title with name of resource or for what this resource will be used
   (After this title you should provide description of resource)
  ## Resources - constant name. This section will  be used if
  plugin directory contains more then one resource (F.e. rackspase
  resources)
  # Installation   - constant name. What we should do for using
  this plugin. (Possible will be enough to add link [1] instead sections
  below)
  ## Changes in configuration  - constant name. Which files and How
  we should change them. (Possible will  be enough to add link [1])
  ## Restarting services - constant name. Names of
  services, which should be restarted.
  # Examples  - constant name. Section for
  providing template examples (not full template, just definition of
  contrib resource)
  # Known issues  - constant name. All related
  issues.
  # How it works - constant name. If you want
  to tell some mechanism about this resource.
  # Notes- constant name. Section for
  information, which can not be classified for sections above.
 
  I understand, that it's just README files, but I still think that it's
  enough important for discussion. Hope on your thoughts.
 

 yeah, they are inconsistent.

 -Angus

 
 
 
  [1]
 https://wiki.openstack.org/wiki/Heat/Plugins#Installation_and_Configuration
  [2] https://github.com/openstack/heat/tree/master/contrib/rackspace
 
 
  Regards,
  Sergey.
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Upwards-compatibility for HOT

[Sergey Kraynev]

On 8 July 2014 01:25, Zane Bitter zbit...@redhat.com wrote:

 With the Icehouse release we announced that there would be no further
 backwards-incompatible changes to HOT without a revision bump. However, I
 notice that we've already made an upward-incompatible change in Juno:

 https://review.openstack.org/#/c/102718/

 So a user will be able to create a valid template for a Juno (or later)
 version of Heat with the version

   heat_template_version: 2013-05-23

 but the same template may break on an Icehouse installation of Heat with
 the stable HOT parser. IMO this is almost equally as bad as breaking
 backwards compatibility, since a user moving between clouds will generally
 have no idea whether they are going forward or backward in version terms.

 (Note: AWS don't use the version field this way, because there is only one
 AWS and therefore in theory they don't have this problem. This implies that
 we might need a more sophisticated versioning system.)

 I'd like to propose a policy that we bump the revision of HOT whenever we
 make a change from the previous stable version, and that we declare the new
 version stable at the end of each release cycle. Maybe we can post-date it
 to indicate the policy more clearly. (I'd also like to propose that the
 Juno version drops cfn-style function support.)

 +1 for idea creating new version for each release cycle. I think it will
help to modify format and additional features easier without backward
compatibility problems.

+1 for rejecting cfn functions in HOT. Sometimes it leads to confusing
situation (F.e. when user try to use Fn::GetAtt instead of get_attr in HOT,
where we have not such function).
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Sergey Kraynev for heat-core

[Sergey Kraynev]

Thanks you everyone for the chance to join to this awesome team!
It's honor for me and I hope, that my 5 cents will help to make Heat even
better :)

Regards,
Sergey.


On 27 June 2014 02:08, Steve Baker sba...@redhat.com wrote:

 I'd like to nominate Sergey Kraynev for heat-core. His reviews are
 valuable and prolific, and his commits have shown a sound understanding
 of heat internals.

 http://stackalytics.com/report/contribution/heat-group/60

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Uniform name for logger in projects

[Sergey Kraynev]

Hello, community.

I hope, that most of your know, that a bug with name Log debugs should not
have translations (f.e. [1], [2], [3]) was recently raised in several
projects. The reason for this work is related with the following concerns
[4].
There is a special check that is used (or will be used in some projects,
where the related patches have not merged yet) for verification process
(f.e. [5] or [6]). As you can see, this ([5]) verification uses the LOG
name of logger in regexp and if cases.
However, there are a lot of projects where both names LOG and logger
are used [7].
So I have a question about the current situation:
- Should we use one uniform name for logger or add support for both names
in checks?

In my opinion, declaration of one uniform name in hacking rules is
preferable, because it cleans code from useless duplicate names of one
variable and allows to create one uniform check for this rule.

[1] https://bugs.launchpad.net/neutron/+bug/1320867
[2] https://bugs.launchpad.net/swift/+bug/1318333
[3] https://bugs.launchpad.net/oslo/+bug/1317950
[4] https://wiki.openstack.org/wiki/LoggingStandards#Log_Translation
[5]
https://github.com/openstack/nova/blob/master/nova/hacking/checks.py#L201
[6] https://review.openstack.org/#/c/94255/11/heat/hacking/checks.py
[7] https://github.com/openstack/heat/search?q=getLoggertype=Code

Regards,
Sergey.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat][Nova][Neutron]Detach interface will delete the port

[Sergey Kraynev]

Hello Huang.

You are right, that this problem is presented in networks update for
OS::Nova::Server. I have known about it, and I wanted to discuss it with
Steve Baker, but possibly forgot to do it. Thank you, that you raise this
thread.

About issue.

The cause why it happens is simple: when nova calls detach_interface,  port
will be detached  and deleted at all.


I think there are two solutions:

 First:

 Heat get the port information before to “detach”, and to create the port
 again before to “attach”.

 But I think it looks ugly and will increase risk failure for re-create.


I agree that it's not useful solution. This approach has a lot of bad sides
and one of them :
 - if you update only server, your other resources should stay without
changes, but in this case port will be recreated. (so it will be new
different resource)


Second:

 Neutron provide a detach_port api to nova, so that nova provide the real
 “detach” not “delete” to heat.




I have told with folk from neutron team and they told me that neutron does
not have such api and it's not possible to do this thing.

So I think, that problem should be solved in nova. F.e. will be good to
provide detach_interface command with additional flag delete_port=True.
(some kind of soft detach).
In this case we could use existing port after detaching.

Regards,
Sergey.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat][Nova][Neutron]Detach interface will delete the port

[Sergey Kraynev]

There is interesting patch on review
https://review.openstack.org/#/c/77043/15.
I suppose that it's related with discussed problems. Possibly we should
wait when it will be merged and then check mentioned use-cases.

Regards,
Sergey.


On 17 April 2014 12:18, Huangtianhua huangtian...@huawei.com wrote:





 *发件人:* Sergey Kraynev [mailto:skray...@mirantis.com]
 *发送时间:* 2014年4月17日 15:35
 *收件人:* OpenStack Development Mailing List (not for usage questions)
 *主题:* Re: [openstack-dev] [Heat][Nova][Neutron]Detach interface will
 delete the port



 Hello Huang.



 You are right, that this problem is presented in networks update for
 OS::Nova::Server. I have known about it, and I wanted to discuss it with
 Steve Baker, but possibly forgot to do it. Thank you, that you raise this
 thread.



 About issue.



 The cause why it happens is simple: when nova calls detach_interface,
  port will be detached  and deleted at all.





  I think there are two solutions:

 First:

 Heat get the port information before to “detach”, and to create the port
 again before to “attach”.

 But I think it looks ugly and will increase risk failure for re-create.



 I agree that it's not useful solution. This approach has a lot of bad
 sides and one of them :

  - if you update only server, your other resources should stay without
 changes, but in this case port will be recreated. (so it will be new
 different resource)



  Second:

 Neutron provide a detach_port api to nova, so that nova provide the real
 “detach” not “delete” to heat.





 I have told with folk from neutron team and they told me that neutron does
 not have such api and it's not possible to do this thing.



 So I think, that problem should be solved in nova. F.e. will be good to
 provide detach_interface command with additional flag delete_port=True.
 (some kind of soft detach).

 In this case we could use existing port after detaching.



 --

We discuss it in our team, it’s relate to server_delete also, if
 we update the stack just to delete the server, the port will be deleted
 too.

 So if we want to solve the problem in nova, the process of delete instance
 need to modify. May be need to modify the server_delete api to add a flag
 too.

  But this change seems provide to heat only. And may be it’s not easy
 to doJ

 Regards,

 Sergey.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Heat][Neutron] Refactoring heat LBaaS architecture according Neutron API

[Sergey Kraynev]

Hello community.

I'd like to discuss feature of Neutron LBaaS in Heat.
Currently Heat resources are not identical to Neutron's.
There are four resources here:
'OS::Neutron::HealthMonitor'
'OS::Neutron::Pool'
'OS::Neutron::PoolMember'
'OS::Neutron::LoadBalancer'

According to this representation the VIP is a part of resource
Loadbalancer, whereas Neutron has separate object VIP.  I think it should
be changed to conform with Neutron's implementation.
So the main question: what is the best way to change it? I see following
options:

1. Move VIP in separate resource in icehouse release (without any
additions).
Possibly we should support both (old and new) implementation for users too.
 IMO, it has also one big danger, because now we have stable version of it
and have not enough time to check new approach.
Also I think it does not make sense now, because Neutron team are
discussing new object model (
http://lists.openstack.org/pipermail/openstack-dev/2014-February/027480.html)
and it will be implemented in Juno.

2. The second idea is to wait all architecture changes that are planed in
Juno in Neutron. (look at link above)
Then we could recreate or change Heat LBaaS architecture at all.

Your feedback and other ideas about better implementation plan are welcome.

Regards,
Sergey.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev