Open Stack

On 09/01/15 21:07, Mark Kirkwood wrote:
> On 09/01/15 15:50, Mark Kirkwood wrote:
>> On 01/11/14 05:10, Ali Nazemian wrote:
>>> Dear all,
>>> Hi,
>>> I was wondering is there anybody out there that could install and
>>> initialize openstack trove using devstack script? I almost tried
>>> different
>>> scenarios on local.conf for both icehouse and juno releases! It seems
>>> all
>>> of them stuck in the same situation as this bug report:
>>> https://bugs.launchpad.net/trove/+bug/1386817
>>>
>>> Probably It is related to devstack or its networking as it is
>>> mentioned in
>>> this bug. But I am not sure that anybody tested trove module
>>> successfully
>>> in this way.
>>> I really appreciate if you can help me in this regard.
>>> Thank you very much.
>>
>> I did *previously* have this working. I'll update my devstack and see if
>> I can reproduce.
>>
>> Are you using trove with nova network or neutron (I can setup both, but
>> may as well test the same case you are doing)?
>>
>
> Booting an Ubuntu 14.04 server and running stack.sh with branch set to
> stable/juno setup config (note nova networking) as follows:
>
> $ cat devstack/local.sh
> [[local|localrc]]
> ADMIN_PASSWORD=password
> MYSQL_PASSWORD=password
> RABBIT_PASSWORD=password
> SERVICE_PASSWORD=password
> SERVICE_TOKEN=tokentoken
> ENABLED_SERVICES+=,trove,tr-api,tr-tmgr,tr-cond
> ENABLED_SERVICES+=,s-proxy,s-object,s-container,s-account
> ENABLED_SERVICES+=,heat,h-api,h-api-cfn,h-api-cw,h-eng
> ENABLED_SERVICES+=,-n-novnc,-n-xvnc
> NOVNC_FROM_PACKAGE=false
> SWIFT_HASH=12go358snjw24501
> LOGFILE=$DEST/logs/stack.sh.log
> VERBOSE=True
> SCREEN_LOGDIR=$DEST/logs/screen
>
> I get an instance in ERROR state, taskmanager log is different from
> yours but looks to be a similar problem (see below). I will need to hack
> into the VM to see what actually went wrong (no admin ssh keys installed
> it seems...secure but annoying. I've had this working fine when I built
> my own images with disk-image-builder). Will update when I figure out
> what the problem is:
>
> 2015-01-09 20:42:04.841 ERROR trove.common.utils
> [req-238c407a-833b-4d9c-88ca-32f9fd42edc9
> 87248e2a69a2454aa088d37bb989d604 1bbc70f7e0d04b38a4a7eacc6a7573c1] In
> looping call.
> 2015-01-09 20:42:04.841 TRACE trove.common.utils Traceback (most recent
> call last):
> 2015-01-09 20:42:04.841 TRACE trove.common.utils   File
> "/opt/stack/trove/trove/common/utils.py", line 213, in _inner
> 2015-01-09 20:42:04.841 TRACE trove.common.utils     self.f(*self.args,
> **self.kw)
> 2015-01-09 20:42:04.841 TRACE trove.common.utils   File
> "/opt/stack/trove/trove/common/utils.py", line 254, in poll_and_check
> 2015-01-09 20:42:04.841 TRACE trove.common.utils     raise
> exception.PollTimeOut
> 2015-01-09 20:42:04.841 TRACE trove.common.utils PollTimeOut: Polling
> request timed out.
> 2015-01-09 20:42:04.841 TRACE trove.common.utils
> 2015-01-09 20:42:04.842 ERROR trove.taskmanager.models
> [req-238c407a-833b-4d9c-88ca-32f9fd42edc9
> 87248e2a69a2454aa088d37bb989d604 1bbc70f7e0d04b38a4a7eacc6a7573c1]
> Failed to create instance a5dfdf4a-753d-40ad-9482-2f8815fcf735. Timeout
> waiting for instance to become active. No usage create-event was sent.
> 2015-01-09 20:42:04.930 ERROR trove.taskmanager.models
> [req-238c407a-833b-4d9c-88ca-32f9fd42edc9
> 87248e2a69a2454aa088d37bb989d604 1bbc70f7e0d04b38a4a7eacc6a7573c1]
> Service status: ERROR
> 2015-01-09 20:42:04.930 ERROR trove.taskmanager.models
> [req-238c407a-833b-4d9c-88ca-32f9fd42edc9
> 87248e2a69a2454aa088d37bb989d604 1bbc70f7e0d04b38a4a7eacc6a7573c1]
> Service error description: guestagent error
> 2015-01-09 20:42:04.933 DEBUG trove.db.models
> [req-238c407a-833b-4d9c-88ca-32f9fd42edc9
> 87248e2a69a2454aa088d37bb989d604 1bbc70f7e0d04b38a4a7eacc6a7573c1]
> Saving DBInstance: {u'cluster_id': None, u'shard_id': None,
> u'deleted_at': None, u'id': u'a5dfdf4a-753d-40ad-9482-2f8815fcf735',
> u'datastore_version_id': u'278f8bcf-71db-47d0-9f8d-04ed56cc281c',
> 'errors': {}, u'hostname': None, u'server_status': None,
> u'task_description': 'Build error: guestagent timeout.', u'volume_size':
> 2L, u'type': None, u'updated': datetime.datetime(2015, 1, 9, 7, 42, 4,
> 933387), '_sa_instance_state': <sqlalchemy.orm.state.InstanceState
> object at 0x7f4ea63bedd0>, u'deleted': 0, u'configuration_id': None,
> u'volume_id': u'd88c533d-58d2-4303-a485-b755d4dcb03b', u'slave_of_id':
> None, u'task_start_time': None, u'name': u'db0', u'task_id': 84,
> u'created': datetime.datetime(2015, 1, 9, 7, 31, 59), u'tenant_id':
> u'1bbc70f7e0d04b38a4a7eacc6a7573c1', u'compute_instance_id':
> u'df41582f-75a1-4e86-9215-9ff274e45fb7', u'flavor_id': 2L} from
> (pid=26513) save /opt/stack/trove/trove/db/models.py:61
> 2015-01-09 20:42:04.963 ERROR trove.taskmanager.models
> [req-238c407a-833b-4d9c-88ca-32f9fd42edc9
> 87248e2a69a2454aa088d37bb989d604 1bbc70f7e0d04b38a4a7eacc6a7573c1] Trove
> instance status: ERROR
> 2015-01-09 20:42:04.964 ERROR trove.taskmanager.models
> [req-238c407a-833b-4d9c-88ca-32f9fd42edc9
> 87248e2a69a2454aa088d37bb989d604 1bbc70f7e0d04b38a4a7eacc6a7573c1] Trove
> instance status description: Build error: guestagent timeout.
>
>

After some analysis of what was happening in the VM, it seems there are 
a number of things not setup to work with devstack. The takeaway here is 
that the problems are all todo with the config of the image 
(ubuntu_mysql) used by the datastore. The list (and how to fix 'em) follows:

1/ No ssh authorized key for VM to rsync trove config from devstack host

Mount and edit the image to add public key from 
/home/stack/.ssh/id_rsa.pub into /home/ubuntu/.ssh/authroized_keys in 
the image.

2/ Image guestagent wants to rsync from ubuntu user

Typically devstack uses a 'stack' user. So edit 
/etc/init/trove-guest.conf in the image to rsync from 'stack' not 'ubuntu'.

3/ Guest agent needs netifaces module

This *may* be because I'm running 14.04 on the host running devstack. 
But anyway installing the python2.7-netifaces package in the image fixes 
this.

With all these sets performed and (obviously) a new image uploaded to 
glance, creating a trove instance finally goes to ACTIVE.

So in conclusion, a more suitably configured image for the devstack 
install procedure (i.e stack.sh) to upload is required.

Regards

Mark