Re: [openstack-dev] [zaqar-ui][zaqar] Nominating Thai Tran for zaqar-ui core

]. If no one objects, I'll proceed and add him in a week from now. [1] http://stackalytics.com/report/contribution/zaqar-ui/90 +1, and thank you for your work on Zaqar's UI! -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc

Re: [openstack-dev] [Zaqar] Nominating Eva Balycheva for Zaqar core

to the team. If no one objects, I'll proceed and add her in a week from now. +1, cheers! -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions

[openstack-dev] Foundation Sponsorship for tox/pytest Sprint

at work and at play. If OpenStack pays your salary, consider giving the tox/pytest team a slice. Cheers, Ryan -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List

Re: [openstack-dev] [api] create openstack/service-registry

) is something we can agree API-WG both does and should care about. -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 01:00 PM, Sean Dague wrote: On 02/05/2016 12:16 PM, Ryan Brown wrote: On 02/05/2016 09:08 AM, michael mccune wrote: On 02/04/2016 12:57 PM, Hayes, Graham wrote: On 04/02/2016 15:40, Ryan Brown wrote: [snipped lots] This isn't a perfect solution, but maybe instead

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 09:08 AM, michael mccune wrote: On 02/04/2016 12:57 PM, Hayes, Graham wrote: On 04/02/2016 15:40, Ryan Brown wrote: [snipped lots] This isn't a perfect solution, but maybe instead of projects.yml there could be a `registry.yml` project that would (of course) have all

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

functional as an openstack product chock-full of syntax errors ** Shed Cat Enterprise Leopard is strictly fictional, and not based on any company that currently or ever has existed. -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. ___

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

akes it easier to use the different vendors of commodity services, and that's not a reason to boot it. Sidebar: I recall a few years ago that Rackspace's CDN offering was based on Akamai, so read into that whatever you want I guess. They at least used to have a relation with Akamai at some po

Re: [openstack-dev] [all] the trouble with names

hear Everett's and Chris' opinions. regards, mike __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailm

Re: [openstack-dev] [api] service type vs. project name for use in headers

On 01/27/2016 03:31 PM, Dean Troyer wrote: On Wed, Jan 27, 2016 at 1:47 PM, michael mccune > wrote: i am not convinced that we would ever need to have a standard on how these names are chosen for the header values, or if we would even need to

Re: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forward

penstack to be "good" but they also have deadlines to meet internally. Having a freeze upstream for stabilization is going to put downstream development into overdrive, no doubt. That would be a poor precedent to have set given where the bulk of contributions come from. -- Ryan Br

Re: [openstack-dev] [neutron][api] GET call with huge argument list

s to work. Its a hack, but complies with HTTP standard. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/ma

Re: [openstack-dev] [Heat] Status of the Support Conditionals in Heat templates

openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Developme

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

m what I understand of the Magnum architecture, this is indeed true) then nesting them makes sense. Of course, it's a big change and will have to be communicated to users & client libraries, probably via a version bump. -- Ryan Brown /

Re: [openstack-dev] [TripleO] Driving workflows with Mistral

ions. I am about to implement your nodes workflow in the GUI to test how it works. Jirka -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubs

Re: [openstack-dev] [TripleO] Driving workflows with Mistral

mailman/listinfo/openstack-dev -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstac

Re: [openstack-dev] [TripleO] Driving workflows with Mistral

On 01/12/2016 10:50 AM, Jiri Tomasek wrote: On 01/12/2016 04:22 PM, Ryan Brown wrote: On 01/12/2016 06:52 AM, Jiri Tomasek wrote: On 01/11/2016 04:51 PM, Dan Prince wrote: Background info: We've got a problem in TripleO at the moment where many of our workflows can be driven by the command

Re: [openstack-dev] [heat] Client checking of server version

questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Develo

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

_____ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Senior Software Engineer, O

Re: [openstack-dev] [TripleO] Removing the Tuskar repos

?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev +1 +1 -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [Zaqar] OpenStack Tokyo Summit Summary

e http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-de

Re: [openstack-dev] [devstack] Logging - filling up my tiny SSDs

cut all the logfiles down to size when the total size of your log directory exceeds 1 GB. I have it set to run every 3 hours on my vms. -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mail

Re: [openstack-dev] [api][ironic] some questions about tags

/ 2: http://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-methods -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage quest

Re: [openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

e projects. Your thoughts? Cheers, Thomas Goirand (zigo) P.S: It wasn't the point of this message, but do we have a fix for designateclient? It'd be nice to have this fixed before Liberty is out. -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __

Re: [openstack-dev] [heat] Convergence: Detecting and handling worker failures

be useful for heat. A lot of boiler plate needed for locking and running centralized tasks (such as timeout) will not be needed in heat. Given that we are moving towards distribution of tasks and horizontal scaling is preferred, it will be advantageous to use them. Please share your thoughts. - Anan

Re: [openstack-dev] [TripleO] Defining a public API for tripleo-common

urces |- events |- services I think versioning the public API is the way to go, since it will make it easier to maintain backwards compatibility while new needs/uses evolve. -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

Re: [openstack-dev] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

slow time. Anybody else think this could be useful? -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstac

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

e: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (no

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

On 08/27/2015 11:28 PM, Chen, Wei D wrote: > > I agree that return 400 is good idea, thus client user would know what > happened. > +1, I think a 400 is the sensible choice here. It'd be much more likely to help devs catch their errors . -- Ryan Brown / Software Engineer, Opensta

Re: [openstack-dev] [app-catalog][heat] Heat template contributors repo

repo is how does reviewing work? are heat cores expected to also be cores on this new repo, or maybe just take anything that gets 5 +1's? -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development

Re: [openstack-dev] [glance][api] Response when a illegal body is sent

requests and execute the request as normal. Best, -jay -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

OS::Zaqar::Queue is disabled on this cloud. I'm not sure if validate currently makes that distinction, but it likely should. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List

Re: [openstack-dev] Should project name be uppercase or lowercase?

darn near every service a module. It doesn't seem to be a valuable distinction, and I know that within the heat team, we say service. Do operators, users, or developers find this distinction useful? Calling everything [blank] service seems like it'd be more consistent. -- Ryan Brown / Software

Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

/186436/ [2]: https://review.openstack.org/#/c/186555/ [3]: https://review.openstack.org/#/c/185822/ ...[snip]... -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] Redis as Messaging System

not messaging for OpenStack internally. Good catch Clint, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

for the mail Flavio, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] Redis as Messaging System

Zaqar provides an option to use Redis as a backend, and Zaqar provides pubsub messaging. On 05/23/2015 03:09 PM, Todd Crane wrote: Does anybody know of a way (either current projects or future plans) to use Redis PubSub as the messaging system for OpenStack? -Todd -- Ryan Brown / Software

Re: [openstack-dev] [api] Proposing Michael McCune as an API Working Group core

On 05/11/2015 04:18 PM, Everett Toews wrote: I would like to propose Michael McCune (elmiko) as an API Working Group core. Not core, but +1 from me! -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc

Re: [openstack-dev] [api] Changing 403 Forbidden to 400 Bad Request for OverQuota was: [nova] Which error code should we return when OverQuota

...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [api] Changing 403 Forbidden to 400 Bad Request for OverQuota was: [nova] Which error code should we return when OverQuota

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

Re: [openstack-dev] [swift] Go! Swift!

than logical. I imagine there are others who are also nervous about that. I don't think it tries to be magical, it tries to be developer friendly by default, and lets your VCS handle versioning your dependencies. It just so happens version control systems are great at that. -- Ryan Brown

Re: [openstack-dev] [all] Question for the TC candidates

out at all. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] Please stop reviewing code while asking questions

nominal level of somewhat unhelpful reviews so long as, when possible, we try to teach those reviewers how they can be more helpful. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing

Re: [openstack-dev] [api] API WG Meeting Time

would still love to hear more thoughts from folks in Australia/Asia time zones to see if we can arrive at something that will accommodate the most number of interested parties. regards, mike I'd be more than happy with a 1200UTC-1300UTC meeting (I'm US-based). -- Ryan Brown / Software Engineer

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

. Especially in a service like Zaqar where the vast majority of usage isn't by humans in a web interface, the horizon bit becomes mostly a dashboard/auditing/testing destination instead of a primary interface. [snip] -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc

Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0

pkg_resources pkg_resources.get_distribution('nova').version Where, of course, s/nova/any-package-name/ -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

-tenant cases, etc. As someone who wants to adopt Zaqar, I'd really like to see it continue as a project because it provides things other message broker approaches don't. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc

Re: [openstack-dev] [all] how to send messages (and events) to our users

as-is to view those raw notifications, not just the indexed k/v pairs? In StackTach.v3 we ship the raw notifications to HDFS for archiving, but expose the reduced event via the API. The message-id links the two. Lots more here: http://www.stacktach.com Thanks! I'll have to read up. -- Ryan Brown

Re: [openstack-dev] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

life more complicated because that means pbr will obviously need to be added as a runtime requirement for that package. RDO actually patches out calls to pbr to avoid the runtime requirement, FWIW. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc

Re: [openstack-dev] [all] how to send messages (and events) to our users

-replaced-resources, autoscaling actions, and info about stack errors. Is there a way for users as-is to view those raw notifications, not just the indexed k/v pairs? Thanks, Ryan [1]: https://review.openstack.org/#/c/167793/ -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc

Re: [openstack-dev] [api] API WG Meeting Time

it to tomorrow’s meeting. Can someone else please #startmeeting? Thanks, Everett +1 for moving to only 16:00UTC -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List

Re: [openstack-dev] [Heat] Decoupling Heat integration tests from Heat tree

I (and you) mentioned earlier. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org

Re: [openstack-dev] Is yaml-devel still needed for Devstack

, but there may be performance implications. Since it's a soft requirement should we patch devstack to reflect that? -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List

Re: [openstack-dev] [Heat] Decoupling Heat integration tests from Heat tree

for avoiding submodules. What do you think about it? Please share your comments. Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com http://www.mirantis.com -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

with internal forks/patches - those will likely all have to be redone too.. Ooof, that's huge. If we can configure it to be less aggressive I love the *idea* of having everything formatted semantically, but that's a pretty major burden for everyone involved. -- Ryan Brown / Software Engineer, Openstack

Re: [openstack-dev] [API] Do we need to specify follow the HTTP RFCs?

that is/isn't RFC compliant for clarity -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org

Re: [openstack-dev] The API WG mission statement

://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

Re: [openstack-dev] [Heat][API] Filtering by metadata values

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

Re: [openstack-dev] [Murano] [API WG] Environment status

?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack

[openstack-dev] [Openstack] [Heat][convergence] Formal model for SyncPoints

Oops, sent this to openstack@ not openstack-dev@. On 02/10/2015 04:52 PM, Ryan Brown wrote: Heat team, After looking at Zane's prototype[1] and the ML threads on SyncPoint, I thought it'd be helpful to make a model of *just* the logic around resource locking. Hopefully, it'll help during

Re: [openstack-dev] The API WG mission statement

/listinfo/openstack-dev -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [api] Next meeting agenda

...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc

Re: [openstack-dev] [Openstack] [Ceilometer] [API] Batch alarm creation

-dev -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Nailgun] Web framework

larger (though the average flask project seems pretty small). I'm not sure what determines production readiness, but it seems to me like Fuel developers fall more in Pecan's target audience than in Flask's. My $0.02, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc

Re: [openstack-dev] [Heat] Using Job Queues for timeout ops

sensible way to add this would be to make timeout polling a responsibility of the Observer instead of the engine. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http

Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

On 11/12/2014 07:50 AM, Zane Bitter wrote: On 12/11/14 06:48, Angus Salkeld wrote: (it's nice that there would be a consistent user experience between these projects -mistral/heat/murano). It's actually potentially horrible, because you introduce potential quoting issues when you embed

Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

Javascript. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] image requirements for Heat software config

___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] [Heat] Defining what is a SupportStatus version

for this, and so I think that using the version number is probably fine. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Software Engineer, Openstack

Re: [openstack-dev] [Heat] Defining what is a SupportStatus version

On 09/16/2014 09:49 AM, Ryan Brown wrote:. (From Zane's other message) snip I think the first supported release is probably the right information to add. snip I feel like for anything with nonzero upgrade effort (and upgrading your openstack install takes significantly more than 0

Re: [openstack-dev] [all] Bringing back auto-abandon

particular itch, there's always gerrit-dash-creator[1] to help you make one that fits your needs. [1]: https://github.com/stackforge/gerrit-dash-creator -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list

Re: [openstack-dev] znc as a service (was Re: [nova] Is the BP approval process broken?)

results. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] znc as a service (was Re: [nova] Is the BP approval process broken?)

(or at least would receive private messages) and OpenStack probably shouldn't take responsibility for keeping all those safe. Just my 0.02 USD. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

On 08/27/2014 12:15 PM, Kurt Griffiths wrote: On 8/25/14, 9:50 AM, Ryan Brown rybr...@redhat.com wrote: I'm actually quite partial to roles because, in my experience, service accounts rarely have their credentials rotated more than once per eon. Having the ability to let instances grab

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo

Re: [openstack-dev] [git-review] Supporting development in local branches

feature: A-B-...-C-D-...-E snip +1, this is definitely a feature I'd want to see. Currently I run two branches bug/LPBUG#-local and bug/LPBUG# where the local is my full history of the change and the other branch is the squashed version I send out to Gerrit. Cheers, -- Ryan Brown / Software

Re: [openstack-dev] [git-review] Supporting development in local branches

On 08/05/2014 09:27 AM, Sylvain Bauza wrote: Le 05/08/2014 13:06, Ryan Brown a écrit : -1 to this as git-review default behaviour. Ideally, branches should be identical in between Gerrit and local Git. Probably not as default behaviour (people who don't want that workflow would be driven

Re: [openstack-dev] [heat]Heat Db Model updates

any benefit here. Agreed I'd actually be in favor of the change from rsrc-resource, I feel like rsrc is a pretty opaque abbreviation. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev