Open Stack

On Wed, Jul 09, 2014 at 10:33:26PM +0000, Randall Burt wrote:
> On Jul 9, 2014, at 4:38 PM, Zane Bitter <zbitter at redhat.com>
>  wrote:
> > On 08/07/14 17:17, Steven Hardy wrote:
> > 
> >> Regarding forcing deployers to make a one-time decision, I have a question
> >> re cost (money and performance) of the Swift approach vs just hitting the
> >> Heat API
> >> 
> >> - If folks use the Swift resource and it stores data associated with the
> >>   signal in Swift, does that incurr cost to the user in a public cloud
> >>   scenario?
> > 
> > Good question. I believe the way WaitConditions work in AWS is that it sets up a pre-signed URL in a bucket owned by CloudFormation. If we went with that approach we would probably want some sort of quota, I imagine.
> 
> Just to clarify, you suggest that the swift-based signal mechanism use containers that Heat owns rather than ones owned by the user?

I guess it's probably best to just make this configurable, so the swift
data can be either owned by the stack owner (same as all other resources,
probably the default), or put in a container owned by the heat service
user.

> > The other approach is to set up a new container, owned by the user, every time. In that case, a provider selecting this implementation would need to make it clear to customers if they would be billed for a WaitCondition resource. I'd prefer to avoid this scenario though (regardless of the plug-point).
> 
> Why? If we won't let the user choose, then why wouldn't we let the provider make this choice? I don't think its wise of us to make decisions based on what a theoretical operator may theoretically do. If the same theoretical provider were to also charge users to create a trust, would we then be concerned about that implementation as well? What if said provider decides charges the user per resource in a stack regardless of what they are? Having Heat own the container(s) as suggested above doesn't preclude that operator from charging the stack owner for those either.
> 
> While I agree that these examples are totally silly, I'm just trying to illustrate that we shouldn't deny an operator an option so long as its understood what that option entails from a technical/usage perspective.

I don't really get why this question is totally silly - I made a genuine
request for education based on near-zero knowledge of public cloud provider
pricing models.

The reason for the question was simply that we're discussing the two
alternate WaitCondition implementations which may, possibly, have very
different implications from a cost perspective.

I'm not saying we shouldn't let the provider make that decision on behalf
of the user, just pointing out that if their particular use-case demands
sending a gadzillion signals, they might like the option to choose the
lightweight API signal approach.

> >> - What sort of overhead are we adding, with the signals going to swift,
> >>   then in the current implementation being copied back into the heat DB[1]?
> > 
> > I wasn't aware we were doing that, and I'm a bit unsure about it myself. I don't think it's a big overhead, though.
> 
> In the current implementation, I think it is minor as well, just a few extra Swift API calls which should be pretty minor overhead considering the stack as a whole. Plus, it minimizes the above concern around potentially costly user containers in that it gets rid of them as soon as its done.
> 
> >> It seems to me at the moment that the swift notification method is good if
> >> you have significant data associated with the signals, but there are
> >> advantages to the simple API signal approach I've been working on when you
> >> just need a simple "one shot" low overhead way to get data back from an
> >> instance.
> >> 
> >> FWIW, the reason I revived these patches was I found that
> >> SoftwareDeployments did not meet my needs for a really simple signalling
> >> mechanism when writing tempest tests:
> >> 
> >> https://review.openstack.org/#/c/90143/16/tempest/scenario/orchestration/test_volumes_create_from_backup.yaml
> >> 
> >> These tests currently use the AWS WaitCondition resources, and I wanted a
> >> native alternative, without the complexity of using SoftwareDeployments
> >> (which also won't work with minimal cirros images without some pretty hacky
> >> workarounds[2])
> > 
> > Yep, I am all for this. I think that Swift is the best way when we have it, but not every cloud has Swift (and the latest rumours from DefCore are that it's likely to stay that way), so we need operators (& developers!) to be able to plug in an alternative implementation.
> 
> Very true, but not every cloud has trusts either. Many may have trusts, but they don't employ the EC2 extensions to Keystone and therefore can't use the "native" signals either (as I understand them anyway). Point being that either way, we already impose requirements on a cloud you want to run Heat against. I think it in our interest to make the effort to provide choices with obvious trade-offs.

The whole point of the resources I've proposed is they don't need the EC2
extensions (or trusts btw).  They do require stack domain users though (e.g
keystone v3 will be required).

All they do is generate a curl string containing a token, which is a token
for a user in the heat stack domain, so all you need to have running is
heat (the native API), there's no requirement for the CFN-compatible API or
EC2 keystone extensions at all:

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

> >> I'm all for making things simple, avoiding duplication and confusion for
> >> users, but I'd like to ensure that making this a one-time deployer level
> >> decision definitely makes sense, vs giving users some choice over what
> >> method is used.
> > 
> > Agree, this is an important question to ask. The downside to leaving the choice to the user is that it reduces interoperability between clouds. (In fact, it's unclear whether operators _would_ give users a choice, or just deploy one implementation anyway.) It's not insurmountable (thanks to environments), but it does add friction to the ecosystem so we have to weigh up the trade-offs.
> 
> Agreed that this is an important concern, but one of mine is that no other resource has "selectable" back-ends. The way an operator controls this today is via the global environment where they have the option to disable one or more of these resources or even alias one to the other. Seems a large change for something an operator already has the ability to deal with. The level of interoperability is at least partly an operator choice already and out of our hands.

Yeah this is my concern as well - we already have a well understood
mechanism for aliasing resource types, so provided we keep the resource
properties compatible, there's no reduction in interoperability -
providers have the choice to either allow both resources, or just alias one
to another if they support only one transport.  It probably makes no
appreciable difference which config file they edit to do it IMO.

The main disadvantage I see with forcing this to be a one-time operator
decision is that it removes control from users, if they have use-cases
where using one transport over the other might be preferred.

Steve