Open Stack

No problem. 

Filed here: https://bugs.launchpad.net/heat/+bug/1302578 for continued 
discussion. 

-M

________________________________
Kind Regards,

Michael D. Elder

STSM | Master Inventor
mdelder at us.ibm.com  | linkedin.com/in/mdelder

"Success is not delivering a feature; success is learning how to solve the 
customer’s problem.” -Mark Cook



From:   Steve Baker <sbaker at redhat.com>
To:     openstack-dev at lists.openstack.org
Date:   04/03/2014 10:13 PM
Subject:        Re: [openstack-dev] [heat] Problems with software config 
and Heat standalone configurations



On 04/04/14 14:26, Michael Elder wrote:
Hello, 

While adopting the latest from the software configurations in Icehouse, we 
discovered an issue with the new software configuration type and its 
assumptions about using the heat client to perform behavior. 

The change was introduced in: 

commit 21f60b155e4b65396ebf77e05a0ef300e7c3c1cf 
Author: Steve Baker <sbaker at redhat.com> 
Change: https://review.openstack.org/#/c/67621/ 

The net is that the software config type in software_config.py lines 
147-152 relies on the heat client to create/clone software configuration 
resources in the heat database: 

    def handle_create(self): 
        props = dict(self.properties) 
        props[self.NAME] = self.physical_resource_name() 

        sc = self.heat().software_configs.create(**props) ## HERE THE HEAT 
CLIENT IS CREATING A NEW SOFTWARE_CONFIG TO MAKE EACH ONE IMMUTABLE 
        self.resource_id_set(sc.id) 

My concerns with this approach: 

When used in standalone mode, the Heat engine receives headers which are 
used to drive authentication (X-Auth-Url, X-Auth-User, X-Auth-Key, ..): 

curl -i -X POST -H 'X-Auth-Key: password' -H 'Accept: application/json' -H 
'Content-Type: application/json' -H 'X-Auth-Url: http://[host]:5000/v2.0' 
-H 'X-Auth-User: admin' -H 'User-Agent: python-heatclient' -d '{...}' 
http://10.0.2.15:8004/v1/{tenant_id} 

In this mode, the heat config file indicates standalone mode and can also 
indicate multicloud support: 

# /etc/heat/heat.conf 
[paste_deploy] 
flavor = standalone 

[auth_password] 
allowed_auth_uris = http://[host1]:5000/v2.0,http://[host2]:5000/v2.0 
multi_cloud = true 

Any keystone URL which is referenced is unaware of the orchestration 
engine which is interacting with it. Herein lies the design flaw. 
Its not so much a design flaw, its a bug where a new piece of code 
interacts poorly with a mode that currently has few users and no 
integration test coverage.


When software_config calls self.heat(), it resolves clients.py's heat 
client: 

    def heat(self): 
        if self._heat: 
            return self._heat 
 
        con = self.context 
        if self.auth_token is None: 
            logger.error(_("Heat connection failed, no auth_token!")) 
            return None 
        # try the token 
        args = { 
                'auth_url': con.auth_url, 
                'token': self.auth_token, 
                'username': None, 
                'password': None, 
                'ca_file': self._get_client_option('heat', 'ca_file'), 
                'cert_file': self._get_client_option('heat', 'cert_file'), 

                'key_file': self._get_client_option('heat', 'key_file'), 
                'insecure': self._get_client_option('heat', 'insecure') 
         } 

        endpoint_type = self._get_client_option('heat', 'endpoint_type') 
        endpoint = self._get_heat_url() 
        if not endpoint: 
            endpoint = self.url_for(service_type='orchestration', 
                                    endpoint_type=endpoint_type) 
        self._heat = heatclient.Client('1', endpoint, **args) 

        return self._heat 

Here, an attempt to look up the orchestration URL (which is already 
executing in the context of the heat engine) comes up wrong because 
Keystone doesn't know about this remote standalone Heat engine. 

If you look at self._get_heat_url() you'll see that the heat.conf 
[clients_heat] url will be used for the heat endpoint if it is set. I 
would recommend setting that for standalone mode. A devstack change for 
HEAT_STANDALONE would be helpful here.

Further, at this point, the username and password are null, and when the 
auth_password standza is applied in the config file, Heat will deny any 
attempts at authorization which only provide a token. As I understand it 
today, that's because it doesn't have individual keystone admin users for 
all remote keystone services in the list of allowed_auth_urls. Hence, if 
only provided with a token, I don't think the heat engine can validate the 
token against the remote keystone. 

One workaround that I've implemented locally is to change the logic to 
check for standalone mode and send the username and password. 

       flavor = 'default' 
        try: 
            logger.info("Configuration is %s" % str(cfg.CONF)) 
            flavor = cfg.CONF.paste_deploy.flavor 
        except cfg.NoSuchOptError as nsoe: 
            flavor = 'default' 
        logger.info("Flavor is %s" % flavor) 
 
        # We really should examine the pipeline to determine whether we're 
using authtoken or authpassword. 
        if flavor == 'standalone': 
 
            context_map = self.context.to_dict() 
 
            if 'username' in context_map.keys(): 
                username = context_map['username'] 
            else: 
                username = None 
 
            if 'password' in context_map.keys(): 
                password = context_map['password'] 
            else: 
                password = None 
 
            logger.info("Configuring username='%s' and password='%s'" % 
(username, password)) 
            args = { 
                'auth_url': con.auth_url, 
                'token': None, 
                'username': username, 
                'password': password, 
                'ca_file': self._get_client_option('heat', 'ca_file'), 
                'cert_file': self._get_client_option('heat', 'cert_file'), 

                'key_file': self._get_client_option('heat', 'key_file'), 
                'insecure': self._get_client_option('heat', 'insecure') 
            }   
        else: 
            if self.auth_token is None: 
                logger.error(_("Heat connection failed, no auth_token!")) 
                return None 
... 

Is this a known issue? 
This is a great summary of the problem, but it really belongs in a 
launchpad bug. Lets discuss potential solutions there.

https://bugs.launchpad.net/heat/+filebug

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140404/1e1085bb/attachment.html>