Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core

[Jason Dunsmore]

Thanks everyone.  It's an honor to join the team.  I'm looking forward
to meeting you all in Atlanta.

On Mon, Feb 10 2014, Jeff Peeler wrote:

 On Mon, Feb 10, 2014 at 11:38:40AM +1300, Steve Baker wrote:
 I would like to nominate Jason Dunsmore for heat-core.
 
 His reviews are valuable and prolific, his code contributions have
 demonstrated a good knowledge of heat internals, and he has endured a
 sound hazing to get multi-engine into heat.
 
 http://russellbryant.net/openstack-stats/heat-reviewers-60.txt
 http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore
 
 Heat cores, please reply with your vote.

 +1!

 ___
 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] testr help

[Jason Dunsmore]

On Wed, Mar 12 2014, John Dennis wrote:

 On 03/12/2014 01:22 PM, Zane Bitter wrote:
 On 10/03/14 20:29, Robert Collins wrote:
 Which bits look raw? It should only show text/* attachments, non-text
 should be named but not dumped.
 
 I was thinking of the:
 
 pythonlogging:'': {{{
 
 part.

 Yes, this is the primary culprit, it's output obscures most everything
 else concerning test results. Sometimes it's essential information.
 Therefore you should be able to control whether it's displayed or not.

The pythonlogging section didn't used to be so verbose, at least for
Heat's unit tests.  I submitted 3 bugs to clean up the test output a few
weeks ago:

https://bugs.launchpad.net/heat/+bug/1281226
https://bugs.launchpad.net/oslo/+bug/1280454
https://bugs.launchpad.net/oslo/+bug/1280435

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

Re: [openstack-dev] [Heat] Resource dependencies

[Jason Dunsmore]

This is what you're looking for:
http://docs.openstack.org/developer/heat/glossary.html#term-dependency

On Thu, Mar 20 2014, Shaunak Kashyap wrote:

 Hi,

 In a Heat template, what does it mean for a resource to depend on
 another resource? As in, what is the impact of creating a dependency?

 I read
 http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#resources-section
 and found this definition of the “depends_on” attribute:

 This optional attribute allows for specifying dependencies of the
 current resource on one or more other resources. Please refer to
 section hot_spec_resources_dependencies for details.


 Unfortunately, I can’t seem to find the referenced
 “hot_spec_resources_dependencies” section anywhere.

 Thank you,

 Shaunak
 ___
 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] User mailing lists for OpenStack projects

[Jason Dunsmore]

Here is the mailing list for openstack usage questions (for all
projects):
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


On Thu, Mar 20 2014, Shaunak Kashyap wrote:

 Hi folks,

 I am relatively new to OpenStack development as one of the developers
 on the unified PHP SDK for OpenStack [1].

 We were recently discussing about a mailing list for the users of this
 SDK (as opposed to it’s contributors who will use openstack-dev@). The
 purpose of such as mailing list would be for users of the SDK to
 communicate with the contributors as well as each other. Of course,
 there would be other avenues for such communication as well (IRC, for
 instance).

 Specifically, we would like to know whether existing OpenStack
 projects have mailing lists for their users and, if so, where they are
 being hosted.

 Thanks,

 Shaunak

 [1] https://wiki.openstack.org/wiki/OpenStack-SDK-PHP
 ___
 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] [Solum/Heat] Is Solum really necessary?

[Jason Dunsmore]

Great description of Heat vs. Solum!  This belongs in the FAQs of both
projects IMO.  This question is bound to keep coming up (for good
reason).

On Thu, Nov 14 2013, Angus Salkeld wrote:

 On 14/11/13 13:41 -0500, Jay Pipes wrote:
So while I have been on vacation, I've been thinking about Solum and Heat.

 And I have some lingering questions in my mind that make me question
 whether a new server project is actually necessary at all, and
 whether we really should just be targeting innovation and resources
 towards the Heat project.

 What exactly is Solum's API going to control that is not already
 represented in Heat's API and the HOT templating language? At this
 point, I'm really not sure, and I'm hoping that we can discuss this
 important topic before going any further with Solum. Right now, I
 see so much overlap that I'm questioning where the differences
 really are.

Thoughts?

 I am very happy with how other projects have built on top
 of heat. I think one reason this happens is Heat is trying
 to focus on one main problem - Orchestrating restful resources.

 If we stick to this (and we are not overly opinionated) this
 fosters other projects to develop on top. If we were in
 a situation where Heat included solum's features it might
 hinder Heat's adoption for other usecases.

 To me solum brings an opionated view to the world where
 there is a specific way of creating/managing applications/services
 that may not appeal to everyone. Hopefully it will apeal
 to lots though! (just a particular user).

 One of Heat's main jobs is to make developing projects like solum,
 tuskar, tripleO, trove  xlcloud easier to implement.

 And these projects will encourage more exciting projects further
 up the stack. The further up the stack we go the more inovation
 we can inspire. It all starts with building reliable simple
 building blocks that can be easily used.


 -Angus

-jay

___
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][horizon]Heat UI related requirements roadmap

[Jason Dunsmore]

On Wed, Nov 27 2013, Zane Bitter wrote:


  Parameters:
  db_name:
  group: db
  order: 0
  db_username:
  group: db
  order: 1
  db_password:
  group: db
  order: 2
  web_node_name:
  group: web_node
  order: 0
  keypair:
  group: web_node
  order: 1

 -2 this is horrible.

 Imagine how much work this is for the poor author! At least they don't
 have to maintain parallel hierarchies of matching key names like in
 the original proposal, but they still have to manually maintain
 multiple lists of orderings. What if you wanted to add another
 parameter at the beginning? Maybe we should encourage authors to
 number parameters with multiples of 10. Like BASIC programmers in the
 80s.

 And of course if you don't specify the order explicitly then you get
 random order again. Sigh.

 There's only one way that this is even remotely maintainable for a
 template author, and that's if they group and order stuff manually
 anyway (like you have in your example - people will do this
 automatically by themselves even if the syntax doesn't require them
 to). Since they have to do this, just display the parameters in the UI
 in the same order that they are defined in the file. This does the
 Right Thing even if the author doesn't know about it, unlike the
 explicit order thing which completely breaks down if the order is not
 explicitly stated. You probably won't even have to document it because
 literally 100% of people will either (a) not care, or (b) expect it to
 work that way anyway. In fact, you will almost certainly get bug
 reports if you don't display them in the same order as written.

+1 for implicit ordering.  I think this will be intuitive for users.

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

Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects

[Jason Dunsmore]

On Mon, Jun 30 2014, Joshua Harlow wrote:

 There is a balance here that needs to be worked out and I've seen
 specs start to turn into requirements for every single patch (even if
 the patch is pretty small). I hope we can rework the 'balance in the
 force' to avoid being so strict that every little thing requires a
 spec. This will not end well for us as a community.

 How have others thought the spec process has worked out so far? To
 much overhead, to little…?

 I personally am of the opinion that specs should be used for large
 topics (defining large is of course arbitrary); and I hope we find the
 right balance to avoid scaring everyone away from working with
 openstack. Maybe all of this is part of openstack maturing, I'm not
 sure, but it'd be great if we could have some guidelines around when
 is a spec needed and when isn't it and take it into consideration when
 requesting a spec that the person you have requested may get
 frustrated and just leave the community (and we must not have this
 happen) if you ask for it without explaining why and how clearly.

+1 I think specs are too much overhead for small features.  A set of
guidelines about when specs are needed would be sufficient.  Leave the
option about when to submit a design vs. when to submit code to the
contributor.

Jason

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

Re: [openstack-dev] [Heat] Proposing Thomas Spatzier for heat-core

[Jason Dunsmore]

+1

On Tue, Apr 22 2014, Steven Dake wrote:

 HOT seemed like a job for Ethan Hunt.

 Nice  work on finishing the job!

 big +1 from me


 On 04/22/2014 11:43 AM, Zane Bitter wrote:
 Resending with [Heat] in the subject line. My bad.

 On 22/04/14 14:21, Zane Bitter wrote:
 I'd like to propose that we add Thomas Spatzier to the heat-core team.

 Thomas has been involved in and consistently contributing to the Heat
 community for around a year, since the time of the Havana design summit.
 His code reviews are of extremely high quality IMO, and he has been
 reviewing at a rate consistent with a member of the core team[1].

 One thing worth addressing is that Thomas has only recently started
 expanding the focus of his reviews from HOT-related changes out into the
 rest of the code base. I don't see this as an obstacle - nobody is
 familiar with *all* of the code, and we trust core reviewers to know
 when we are qualified to give +2 and when we should limit ourselves to
 +1 - and as far as I know nobody else is bothered either. However, if
 you have strong feelings on this subject nobody will take it personally
 if you speak up :)

 Heat Core team members, please vote on this thread. A quick reminder of
 your options[2]:
 +1  - five of these are sufficient for acceptance
   0  - abstention is always an option
 -1  - this acts as a veto

 cheers,
 Zane.


 [1] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt
 [2]
 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


 ___
 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] [neutron] [trove] [swift] Uniform name for logger in projects

[Jason Dunsmore]

(Adding relevant projects to subject.  Hope I didn't miss any.)

Heat, Neutron, Trove, and Swift devs,

Do we want to change all instances of logger variable names to LOG
(like most OpenStack projects use) and enforce that via the hacking
rules?

Regards,
Jason


On Wed, May 21 2014, Sergey Kraynev wrote:

 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

___
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

[Jason Dunsmore]

+1!

On Mon, Oct 06 2014, Zane Bitter 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

[openstack-dev] [Heat] Multi-engine design feedback requested

[Jason Dunsmore]

Heat devs,

Liang pointed out a race-condition in the current multi-engine
implementation that will be difficult to fix without a DB lock.  I've
discussed the multi-engine design with my teammates and written up a few
alternative designs here:
https://etherpad.openstack.org/vJKcZcQOU9

Every design has its own downsides, so I was hoping to get some feedback
from the core devs as to which one is preferable.

Feel free to add comments in-line.  Please don't click Clear Authorship
Colors ;)

Thanks,
Jason

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

Re: [openstack-dev] [Heat] Multi-engine design feedback requested

[Jason Dunsmore]

Heat devs,

There's been some good discussion on the Etherpad:
https://etherpad.openstack.org/vJKcZcQOU9

I've added a Votes section under alternate options 1-5.  Please read
over the discussion and add your vote.

Thanks,
Jason


On Thu, Aug 29 2013, Jason Dunsmore wrote:

 Heat devs,

 Liang pointed out a race-condition in the current multi-engine
 implementation that will be difficult to fix without a DB lock.  I've
 discussed the multi-engine design with my teammates and written up a few
 alternative designs here:
 https://etherpad.openstack.org/vJKcZcQOU9

 Every design has its own downsides, so I was hoping to get some feedback
 from the core devs as to which one is preferable.

 Feel free to add comments in-line.  Please don't click Clear Authorship
 Colors ;)

 Thanks,
 Jason

 ___
 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] core team changes

[Jason Dunsmore]

+1

On Tue, Jan 27 2015, Angus Salkeld 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
 __
 OpenStack Development Mailing 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 nomination

[Jason Dunsmore]

+1!

From: Sergey Kraynev 
Sent: Tuesday, October 20, 2015 8:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev]  [Heat] core team nomination

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

Re: [openstack-dev] [heat] Unable to launch nova instance with the new flavor

[Jason Dunsmore]

Hi Bharath,


It sounds like you've hit this bug https://bugs.launchpad.net/heat/+bug/1556317


A fix is in progress https://review.openstack.org/#/c/291971/?


Regards,

Jason



From: bharath thiruveedula 
Sent: Monday, March 14, 2016 1:12 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [heat] Unable to launch nova instance with the new 
flavor

Hi,

With the master branch, I couldn't launch heat stack with the following 
template, giving the error "ERROR: No Flavor matching {'name': u'flavor_1'}. 
(HTTP 404)"

heat_template_version: 2015-04-30

description: Simple template to deploy a single compute instance

resources:
   ins1:
 type: OS::Nova::Server
 properties:
   flavor: {get_resource: flavor_1}
   image: Fedora

   flavor_1:
 type: OS::Nova::Flavor
 properties:
 disk: 1
 vcpus: 1
 ram: 1


But with "stable/liberty" branch, I can launch the heat stack.

Anyone aware of this issue? Can anyone help me on this issue?

Regards
Bharath T

__
OpenStack Development Mailing 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] update_allowed vs. immutable

[Jason Dunsmore]

Hi Praveen,


The docs you referred to in the plugin guide is for the resource property 
attributes - they have nothing to do with parameters.  This is an important 
distinction because there is also an "immutable" parameter attribute.


The "immutable" property attribute was added because an equivalent to AWS' 
"Updates are not supported" functionality was needed:

https://specs.openstack.org/openstack/heat-specs/specs/juno/implement-aws-updates-not-supported.html#aws-cloudformation


Jason



From: Praveen Yalagandula 
Sent: Monday, May 2, 2016 11:55 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [heat] update_allowed vs. immutable

What is the difference between "update_allowed" and "immutable" parameters for 
a property? According to the plugin guide at
http://docs.openstack.org/developer/heat/developing_guides/pluginguide.html:

update_allowed:
True if an existing resource can be updated, False means update is accomplished 
by delete and re-create. Default is False.

immutable:
True means updates are not supported, resource update will fail on every change 
of this property. False otherwise. Default is False.

Since any resource can be deleted and then re-created, it seems 
"update_allowed" is the right parameter to define. Why do we need "immutable"?

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