Re: [Openstack] Swift Client
--- I ever used --- 1) CyberDuck 2) Owncloud (What's the problem in your test?) 3) Gladinet client 4) SwiftStack Web Console 5) Most of AWS S3 client tools, but you need to enable Swift3 middleware support 6) OpenStack DashBoard 7) Maldivica gateway -- I never use but should work -- 8) SME Hope it help +Hugo Kuo+ h...@swiftstack.com tonyt...@gmail.com +886 935004793 2013/7/5 CHABANI Mohamed El Hadi > Hi people, > > I want to use my Swift all in One with a graphical client, to put / > retrieve objects. i heard that we can use Cyberduck (but there is problem > of port) or Owncloud as Swift client but didn't find good references. > > If any person could help me or suggest other clients, it would be really > great. > > Thank you > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] can't create LoadBalancer with heat
Hi stackers,
I am running devstack with heat enabled.
I was trying to create a new stack using WordPress_With_LB.template from github.
However, it failed and I got the following error in screen-h-eng.log
2013-07-05 10:00:13.998 26996 INFO heat.engine.resource [-] Validating
LoadBalancer "LoadBalancer"
2013-07-05 10:00:14.129 26996 DEBUG heat.openstack.common.rpc.amqp [-]
UNIQUE_ID is cb110b14dc064928a944f577ef96a06e. _add_unique_id
/opt/stack/heat/heat/openstack/common/rpc/amqp.py:325
2013-07-05 10:00:14.130 26996 DEBUG heat.engine.scheduler [-] Task create_task
from Stack "mystack" starting start /opt/stack/heat/heat/engine/scheduler.py:127
2013-07-05 10:00:14.130 26996 DEBUG heat.engine.scheduler [-] Task create_task
from Stack "mystack" running step /opt/stack/heat/heat/engine/scheduler.py:160
2013-07-05 10:00:14.163 26996 DEBUG heat.engine.scheduler [-] Task
resource_create starting start /opt/stack/heat/heat/engine/scheduler.py:127
2013-07-05 10:00:14.163 26996 INFO heat.engine.resource [-] creating
NestedStack "DatabaseServer"
2013-07-05 10:00:14.163 26996 DEBUG heat.engine.scheduler [-] Task
resource_create running step /opt/stack/heat/heat/engine/scheduler.py:160
2013-07-05 10:00:14.280 26996 INFO heat.common.urlfetch [-] Fetching data from
https://raw.github.com/openstack/heat-templates/master/cfn/MySQL_Single_Instance.template
2013-07-05 10:00:14.337 26996 DEBUG heat.openstack.common.rpc.amqp [-]
UNIQUE_ID is b1adf7d73f5544b5b9aecd16ab1db55f. _add_unique_id
/opt/stack/heat/heat/openstack/common/rpc/amqp.py:325
2013-07-05 10:00:14.342 26996 DEBUG heat.openstack.common.rpc.amqp [-] received
{u'_context_roles': [u'anotherrole', u'Member'], u'_msg_id':
u'8884a3955e4b433785bf563ca16f671b', u'_context_password': u'supersecret',
u'_context_auth_url': u'http://172.16.2.45:5000/v2.0',
u'_context_aws_auth_uri': None, u'_unique_id':
u'7d82fea1193748258569d3d91dc10b03', u'_reply_q':
u'reply_284c45add90e4b52a6a5e5f6d7982cad', u'_context_aws_creds': None,
u'args': {}, u'_context_tenant': u'demo', u'_context_auth_token':
'', u'_context_is_admin': True, u'version': u'1.0',
u'_context_tenant_id': u'd8983734739d48febde2d1f8fe2ac447', u'namespace': None,
u'method': u'list_stacks', u'_context_username': u'demo'} _safe_log
/opt/stack/heat/heat/openstack/common/rpc/common.py:298
2013-07-05 10:00:14.343 26996 DEBUG heat.openstack.common.rpc.amqp [-] unpacked
context: {'username': u'demo', 'roles': [u'anotherrole', u'Member'],
'aws_auth_uri': None, 'tenant_id': u'd8983734739d48febde2d1f8fe2ac447',
'auth_token': '', 'auth_url': u'http://172.16.2.45:5000/v2.0',
'is_admin': True, 'password': u'supersecret', 'aws_creds': None, 'tenant':
u'demo'} _safe_log /opt/stack/heat/heat/openstack/common/rpc/common.py:298
2013-07-05 10:00:14.351 26996 INFO requests.packages.urllib3.connectionpool [-]
Starting new HTTP connection (1): 172.16.2.45
2013-07-05 10:00:14.456 26996 DEBUG requests.packages.urllib3.connectionpool
[-] "POST /v2.0/tokens HTTP/1.1" 200 7667 _make_request
/usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/connectionpool.py:289
2013-07-05 10:00:14.457 26996 INFO requests.packages.urllib3.connectionpool [-]
Starting new HTTP connection (1): 172.16.2.45
2013-07-05 10:00:14.474 26996 DEBUG requests.packages.urllib3.connectionpool
[-] "GET /v2/d8983734739d48febde2d1f8fe2ac447/os-availability-zone HTTP/1.1"
200 97 _make_request
/usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/connectionpool.py:289
2013-07-05 10:00:14.478 26996 DEBUG heat.openstack.common.rpc.amqp [-]
UNIQUE_ID is 70b9a0126c5145b7955d9175928d75d3. _add_unique_id
/opt/stack/heat/heat/openstack/common/rpc/amqp.py:325
2013-07-05 10:00:14.479 26996 DEBUG heat.openstack.common.rpc.amqp [-]
UNIQUE_ID is 319e42f2a5224c5eba7ccc3e1f2170f1. _add_unique_id
/opt/stack/heat/heat/openstack/common/rpc/amqp.py:325
2013-07-05 10:00:15.113 26996 DEBUG heat.engine.scheduler [-] Task create_task
from Stack "mystack-DatabaseServer-ruht2gxmpi4h" starting start
/opt/stack/heat/heat/engine/scheduler.py:127
2013-07-05 10:00:15.113 26996 DEBUG heat.engine.scheduler [-] Task create_task
from Stack "mystack-DatabaseServer-ruht2gxmpi4h" running step
/opt/stack/heat/heat/engine/scheduler.py:160
2013-07-05 10:00:15.147 26996 DEBUG heat.engine.scheduler [-] Task
resource_create starting start /opt/stack/heat/heat/engine/scheduler.py:127
2013-07-05 10:00:15.147 26996 INFO heat.engine.resource [-] creating
WaitConditionHandle "MySqlWaitHandle"
2013-07-05 10:00:15.147 26996 DEBUG heat.engine.scheduler [-] Task
resource_create running step /opt/stack/heat/heat/engine/scheduler.py:160
2013-07-05 10:00:15.264 26996 INFO requests.packages.urllib3.connectionpool [-]
Starting new HTTP connection (1): 172.16.2.45
2013-07-05 10:00:15.373 26996 DEBUG requests.packages.urllib3.connectionpool
[-] "POST /v2.0/tokens HTTP/1.1" 200 7667 _make_request
/usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/connection
Re: [Openstack] Migrate volume from Essex to Folsom
On Thu, Jul 4, 2013 at 6:16 PM, pablo fernandez
wrote:
> Leandro, Brano,
I wrote the previous mail in a hurry.. I hope this one might clarify it a bit
1) DFM dataset metadata
Folsom driver is using DFM to store Project id (tenant) together with
the volume. Essex driver did not do that, so his volumes are missing
this metadata. When Folsom driver starts, it will ask DFM for the list
of datasets and he will pick only those name starts with the right
prefix ("OpenStack_") and contain this metadata. If I run the script I
get something like..
OpenStack_5d8e3d0868f54879a13dbc8a3b3dcac5
(ArrayOfDfmMetadataField){
DfmMetadataField[] =
(DfmMetadataField){
FieldName = "OpenStackProject"
FieldValue = "5d8e3d0868f54879a13dbc8a3b3dcac5"
},
(DfmMetadataField){
FieldName = "OpenStackVolType"
FieldValue = None
},
}
This is the output for a volume created by Folsom driver. Essex volume
would have that array empty.
The same script allows you to add metadata (if missing) to existing
volumes created in Essex.
If your Folsom installation is using different datasets (created in
Folsom), then you can ignore this comment. This only applies to you if
you plan to point Folsom driver to LUNs/volumes created in Essex.
2) UUID
If you plan to install Folsom by running DB migration scripts on a
copy of Essex database, then it will take care of generating uuids for
existing volumes and updating all foreign key references.
However, if you start with "blank" Folsom and plan to manually insert
one-by-one entries for Essex volumes, it's much more difficult.
Especially if you have snapshots and volumes created from snapshots
(they reference each other)
3) Update "host"
When you attach a volume, nova-compute will contact via RPC a node
which is specified in "host" column. For example, you have there
"cloud-desa03", which I assume is Essex's nova-volume with Netapp
driver. You will have to update this field to point to Folsom
nova-volume host (assuming you have it on separate node).
4) access Essex volume/snapshot from Folsom
After migration some operations on Essex volumes might not work in
Folsom. I'm quite certain that create Folsom volume from Essex
snapshot did not work. That's why we had to patch Folsom driver to
fall back to lookup LUN by EC2 id, instead of UUID. Eg. driver will
receive a request to delete snapshot. He will get snapshot's name
("snap-a9922eaf-a001-4c53-a584-1b57d45b6e21") as input parameter. So
he will try to find a LUN whose name ends with that string. However,
because the snapshot was created in Essex, the name of the LUN ends
with "/snap-0069". Operation will fail with "no such LUN.."
You might be lucky enough that you won't need any of those use-cases.
For example, attach/detach will probably work without any change.
Regards,
BranoZ
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Migrate volume from Essex to Folsom
Cool, thanks one more time Lean and Brano, you guys rock.
On Thu, Jul 4, 2013 at 2:26 PM, Leandro Reox wrote:
> Yep thats right pablo !
>
>
> On Thu, Jul 4, 2013 at 2:02 PM, pablo fernandez <
> fernandezpabl...@gmail.com> wrote:
>
>> Guys,
>>
>> I also found that the blocking_device_mapping table only contains entries
>> for the volumes that are "in-use".
>>
>> Since we're planning a less transparent cloud migration, with detached
>> volumes seems I don't have to copy this information. The only change needed
>> is to copy the volumes_* info and perform the id translation in between
>> (from ints to UUIDs). Am I right?
>>
>> Thank you!
>>
>>
>> On Thu, Jul 4, 2013 at 1:16 PM, pablo fernandez <
>> fernandezpabl...@gmail.com> wrote:
>>
>>> Leandro, Brano,
>>>
>>> I'm effectively migrating only the openstack installation, the DFM
>>> remains the same. However, if I read Brano's email correctly, besides
>>> migrating the information on openstack DB I also have to change metadata
>>> that DFM, is that right?
>>>
>>> Here's an example of a volume I have on Essex right now:
>>>
>>> https://gist.github.com/fernandezpablo85/fd4340f0150bdf574bbb
>>>
>>> And here's what DFM returns for that volume's LUN:
>>>
>>> https://gist.github.com/fernandezpablo85/219f78545166f0c030b3
>>>
>>> Is moving the data just from Essex db to Folsom safe in this case?
>>>
>>>
>>>
>>> On Thu, Jul 4, 2013 at 12:08 PM, Leandro Reox wrote:
>>>
Pablo,
On folsom the block_device_mappings table its on novadb too, i totally
miss the Brano's recommendation of uuid conversion and metadata, asumming
that you hit the same dfm.
We had to do that a couple of times, but generally as all our vms are
stateless, we create them on the "new" cloud, and replicate the content,
via sharding replicas or other mechanism, without intervention
Saludos
On Thu, Jul 4, 2013 at 11:27 AM, Brano Zarnovican >>> > wrote:
> On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
> wrote:
> > Hi list!
> >
> > Any advice on this? Has somebody already tried it (and hopefully
> succeeded).
>
> We did this migration "in-place". On day D, we dumped Essex
> Openstack/DFM DB and restored in Folsom. I have created a patch for
> Folsom Netapp driver to recognize Essex volumes/snapshots.
>
> I assume that both your clouds are hitting the same DFM. Otherwise,
> you would have to migrate entries not only between Openstack DB, but
> DFM DB, too. Would be painful..
>
> Folsom Netapp driver has added some meta-data to Openstack datasets
> (in DFM), so Folsom will not recognize DFM datasets created in Essex
> (and hence all Essex LUNs would be invisible). I have added that
> meta-data manually with the attached script.
>
> Volume is identified by (host, provider_location). Host is the one
> running nova-volume, provider_location is an object id in DFM db.. eg
> ("mgmt-netapp.example.com", 7574).
>
> So if you are using the same DFM, provider_location won't change, but
> you host probably would.
>
> Problem would be that you need to migrate id from decimal to UUIDs. In
> my case, this was done in Openstack DB as part of that in-place
> migration. The mapping is stored in new table "volume_id_mappings".
> Same comments apply also to snapshots. However, because of this UUID
> change, volumes names (LUNs on Netapp) are expected in different
> format.
>
> Essex:
> /OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-09a4/vol-09a4
> Folsom:
>
> /OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e
>
> That was the reason for driver patch, so I did not have to rename
> existing LUNs on Netapp and DFM.
>
> It's almost easier to create all volumes in Folsom and dd the content
> ;-)
>
> Regards,
>
> BranoZ
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Migrate volume from Essex to Folsom
Yep thats right pablo !
On Thu, Jul 4, 2013 at 2:02 PM, pablo fernandez
wrote:
> Guys,
>
> I also found that the blocking_device_mapping table only contains entries
> for the volumes that are "in-use".
>
> Since we're planning a less transparent cloud migration, with detached
> volumes seems I don't have to copy this information. The only change needed
> is to copy the volumes_* info and perform the id translation in between
> (from ints to UUIDs). Am I right?
>
> Thank you!
>
>
> On Thu, Jul 4, 2013 at 1:16 PM, pablo fernandez <
> fernandezpabl...@gmail.com> wrote:
>
>> Leandro, Brano,
>>
>> I'm effectively migrating only the openstack installation, the DFM
>> remains the same. However, if I read Brano's email correctly, besides
>> migrating the information on openstack DB I also have to change metadata
>> that DFM, is that right?
>>
>> Here's an example of a volume I have on Essex right now:
>>
>> https://gist.github.com/fernandezpablo85/fd4340f0150bdf574bbb
>>
>> And here's what DFM returns for that volume's LUN:
>>
>> https://gist.github.com/fernandezpablo85/219f78545166f0c030b3
>>
>> Is moving the data just from Essex db to Folsom safe in this case?
>>
>>
>>
>> On Thu, Jul 4, 2013 at 12:08 PM, Leandro Reox wrote:
>>
>>> Pablo,
>>>
>>> On folsom the block_device_mappings table its on novadb too, i totally
>>> miss the Brano's recommendation of uuid conversion and metadata, asumming
>>> that you hit the same dfm.
>>> We had to do that a couple of times, but generally as all our vms are
>>> stateless, we create them on the "new" cloud, and replicate the content,
>>> via sharding replicas or other mechanism, without intervention
>>>
>>> Saludos
>>>
>>>
>>> On Thu, Jul 4, 2013 at 11:27 AM, Brano Zarnovican
>>> wrote:
>>>
On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
wrote:
> Hi list!
>
> Any advice on this? Has somebody already tried it (and hopefully
succeeded).
We did this migration "in-place". On day D, we dumped Essex
Openstack/DFM DB and restored in Folsom. I have created a patch for
Folsom Netapp driver to recognize Essex volumes/snapshots.
I assume that both your clouds are hitting the same DFM. Otherwise,
you would have to migrate entries not only between Openstack DB, but
DFM DB, too. Would be painful..
Folsom Netapp driver has added some meta-data to Openstack datasets
(in DFM), so Folsom will not recognize DFM datasets created in Essex
(and hence all Essex LUNs would be invisible). I have added that
meta-data manually with the attached script.
Volume is identified by (host, provider_location). Host is the one
running nova-volume, provider_location is an object id in DFM db.. eg
("mgmt-netapp.example.com", 7574).
So if you are using the same DFM, provider_location won't change, but
you host probably would.
Problem would be that you need to migrate id from decimal to UUIDs. In
my case, this was done in Openstack DB as part of that in-place
migration. The mapping is stored in new table "volume_id_mappings".
Same comments apply also to snapshots. However, because of this UUID
change, volumes names (LUNs on Netapp) are expected in different
format.
Essex:
/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-09a4/vol-09a4
Folsom:
/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e
That was the reason for driver patch, so I did not have to rename
existing LUNs on Netapp and DFM.
It's almost easier to create all volumes in Folsom and dd the content
;-)
Regards,
BranoZ
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
>>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] Swift Client
Hi people, I want to use my Swift all in One with a graphical client, to put / retrieve objects. i heard that we can use Cyberduck (but there is problem of port) or Owncloud as Swift client but didn't find good references. If any person could help me or suggest other clients, it would be really great. Thank you ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Migrate volume from Essex to Folsom
Guys,
I also found that the blocking_device_mapping table only contains entries
for the volumes that are "in-use".
Since we're planning a less transparent cloud migration, with detached
volumes seems I don't have to copy this information. The only change needed
is to copy the volumes_* info and perform the id translation in between
(from ints to UUIDs). Am I right?
Thank you!
On Thu, Jul 4, 2013 at 1:16 PM, pablo fernandez
wrote:
> Leandro, Brano,
>
> I'm effectively migrating only the openstack installation, the DFM remains
> the same. However, if I read Brano's email correctly, besides migrating the
> information on openstack DB I also have to change metadata that DFM, is
> that right?
>
> Here's an example of a volume I have on Essex right now:
>
> https://gist.github.com/fernandezpablo85/fd4340f0150bdf574bbb
>
> And here's what DFM returns for that volume's LUN:
>
> https://gist.github.com/fernandezpablo85/219f78545166f0c030b3
>
> Is moving the data just from Essex db to Folsom safe in this case?
>
>
>
> On Thu, Jul 4, 2013 at 12:08 PM, Leandro Reox wrote:
>
>> Pablo,
>>
>> On folsom the block_device_mappings table its on novadb too, i totally
>> miss the Brano's recommendation of uuid conversion and metadata, asumming
>> that you hit the same dfm.
>> We had to do that a couple of times, but generally as all our vms are
>> stateless, we create them on the "new" cloud, and replicate the content,
>> via sharding replicas or other mechanism, without intervention
>>
>> Saludos
>>
>>
>> On Thu, Jul 4, 2013 at 11:27 AM, Brano Zarnovican
>> wrote:
>>
>>> On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
>>> wrote:
>>> > Hi list!
>>> >
>>> > Any advice on this? Has somebody already tried it (and hopefully
>>> succeeded).
>>>
>>> We did this migration "in-place". On day D, we dumped Essex
>>> Openstack/DFM DB and restored in Folsom. I have created a patch for
>>> Folsom Netapp driver to recognize Essex volumes/snapshots.
>>>
>>> I assume that both your clouds are hitting the same DFM. Otherwise,
>>> you would have to migrate entries not only between Openstack DB, but
>>> DFM DB, too. Would be painful..
>>>
>>> Folsom Netapp driver has added some meta-data to Openstack datasets
>>> (in DFM), so Folsom will not recognize DFM datasets created in Essex
>>> (and hence all Essex LUNs would be invisible). I have added that
>>> meta-data manually with the attached script.
>>>
>>> Volume is identified by (host, provider_location). Host is the one
>>> running nova-volume, provider_location is an object id in DFM db.. eg
>>> ("mgmt-netapp.example.com", 7574).
>>>
>>> So if you are using the same DFM, provider_location won't change, but
>>> you host probably would.
>>>
>>> Problem would be that you need to migrate id from decimal to UUIDs. In
>>> my case, this was done in Openstack DB as part of that in-place
>>> migration. The mapping is stored in new table "volume_id_mappings".
>>> Same comments apply also to snapshots. However, because of this UUID
>>> change, volumes names (LUNs on Netapp) are expected in different
>>> format.
>>>
>>> Essex:
>>> /OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-09a4/vol-09a4
>>> Folsom:
>>>
>>> /OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e
>>>
>>> That was the reason for driver patch, so I did not have to rename
>>> existing LUNs on Netapp and DFM.
>>>
>>> It's almost easier to create all volumes in Folsom and dd the content ;-)
>>>
>>> Regards,
>>>
>>> BranoZ
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Migrate volume from Essex to Folsom
Leandro, Brano,
I'm effectively migrating only the openstack installation, the DFM remains
the same. However, if I read Brano's email correctly, besides migrating the
information on openstack DB I also have to change metadata that DFM, is
that right?
Here's an example of a volume I have on Essex right now:
https://gist.github.com/fernandezpablo85/fd4340f0150bdf574bbb
And here's what DFM returns for that volume's LUN:
https://gist.github.com/fernandezpablo85/219f78545166f0c030b3
Is moving the data just from Essex db to Folsom safe in this case?
On Thu, Jul 4, 2013 at 12:08 PM, Leandro Reox wrote:
> Pablo,
>
> On folsom the block_device_mappings table its on novadb too, i totally
> miss the Brano's recommendation of uuid conversion and metadata, asumming
> that you hit the same dfm.
> We had to do that a couple of times, but generally as all our vms are
> stateless, we create them on the "new" cloud, and replicate the content,
> via sharding replicas or other mechanism, without intervention
>
> Saludos
>
>
> On Thu, Jul 4, 2013 at 11:27 AM, Brano Zarnovican wrote:
>
>> On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
>> wrote:
>> > Hi list!
>> >
>> > Any advice on this? Has somebody already tried it (and hopefully
>> succeeded).
>>
>> We did this migration "in-place". On day D, we dumped Essex
>> Openstack/DFM DB and restored in Folsom. I have created a patch for
>> Folsom Netapp driver to recognize Essex volumes/snapshots.
>>
>> I assume that both your clouds are hitting the same DFM. Otherwise,
>> you would have to migrate entries not only between Openstack DB, but
>> DFM DB, too. Would be painful..
>>
>> Folsom Netapp driver has added some meta-data to Openstack datasets
>> (in DFM), so Folsom will not recognize DFM datasets created in Essex
>> (and hence all Essex LUNs would be invisible). I have added that
>> meta-data manually with the attached script.
>>
>> Volume is identified by (host, provider_location). Host is the one
>> running nova-volume, provider_location is an object id in DFM db.. eg
>> ("mgmt-netapp.example.com", 7574).
>>
>> So if you are using the same DFM, provider_location won't change, but
>> you host probably would.
>>
>> Problem would be that you need to migrate id from decimal to UUIDs. In
>> my case, this was done in Openstack DB as part of that in-place
>> migration. The mapping is stored in new table "volume_id_mappings".
>> Same comments apply also to snapshots. However, because of this UUID
>> change, volumes names (LUNs on Netapp) are expected in different
>> format.
>>
>> Essex:
>> /OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-09a4/vol-09a4
>> Folsom:
>>
>> /OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e
>>
>> That was the reason for driver patch, so I did not have to rename
>> existing LUNs on Netapp and DFM.
>>
>> It's almost easier to create all volumes in Folsom and dd the content ;-)
>>
>> Regards,
>>
>> BranoZ
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Migrate volume from Essex to Folsom
Pablo,
On folsom the block_device_mappings table its on novadb too, i totally miss
the Brano's recommendation of uuid conversion and metadata, asumming that
you hit the same dfm.
We had to do that a couple of times, but generally as all our vms are
stateless, we create them on the "new" cloud, and replicate the content,
via sharding replicas or other mechanism, without intervention
Saludos
On Thu, Jul 4, 2013 at 11:27 AM, Brano Zarnovican wrote:
> On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
> wrote:
> > Hi list!
> >
> > Any advice on this? Has somebody already tried it (and hopefully
> succeeded).
>
> We did this migration "in-place". On day D, we dumped Essex
> Openstack/DFM DB and restored in Folsom. I have created a patch for
> Folsom Netapp driver to recognize Essex volumes/snapshots.
>
> I assume that both your clouds are hitting the same DFM. Otherwise,
> you would have to migrate entries not only between Openstack DB, but
> DFM DB, too. Would be painful..
>
> Folsom Netapp driver has added some meta-data to Openstack datasets
> (in DFM), so Folsom will not recognize DFM datasets created in Essex
> (and hence all Essex LUNs would be invisible). I have added that
> meta-data manually with the attached script.
>
> Volume is identified by (host, provider_location). Host is the one
> running nova-volume, provider_location is an object id in DFM db.. eg
> ("mgmt-netapp.example.com", 7574).
>
> So if you are using the same DFM, provider_location won't change, but
> you host probably would.
>
> Problem would be that you need to migrate id from decimal to UUIDs. In
> my case, this was done in Openstack DB as part of that in-place
> migration. The mapping is stored in new table "volume_id_mappings".
> Same comments apply also to snapshots. However, because of this UUID
> change, volumes names (LUNs on Netapp) are expected in different
> format.
>
> Essex:
> /OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-09a4/vol-09a4
> Folsom:
>
> /OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e
>
> That was the reason for driver patch, so I did not have to rename
> existing LUNs on Netapp and DFM.
>
> It's almost easier to create all volumes in Folsom and dd the content ;-)
>
> Regards,
>
> BranoZ
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Migrate volume from Essex to Folsom
On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
wrote:
> Hi list!
>
> Any advice on this? Has somebody already tried it (and hopefully succeeded).
We did this migration "in-place". On day D, we dumped Essex
Openstack/DFM DB and restored in Folsom. I have created a patch for
Folsom Netapp driver to recognize Essex volumes/snapshots.
I assume that both your clouds are hitting the same DFM. Otherwise,
you would have to migrate entries not only between Openstack DB, but
DFM DB, too. Would be painful..
Folsom Netapp driver has added some meta-data to Openstack datasets
(in DFM), so Folsom will not recognize DFM datasets created in Essex
(and hence all Essex LUNs would be invisible). I have added that
meta-data manually with the attached script.
Volume is identified by (host, provider_location). Host is the one
running nova-volume, provider_location is an object id in DFM db.. eg
("mgmt-netapp.example.com", 7574).
So if you are using the same DFM, provider_location won't change, but
you host probably would.
Problem would be that you need to migrate id from decimal to UUIDs. In
my case, this was done in Openstack DB as part of that in-place
migration. The mapping is stored in new table "volume_id_mappings".
Same comments apply also to snapshots. However, because of this UUID
change, volumes names (LUNs on Netapp) are expected in different
format.
Essex:
/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-09a4/vol-09a4
Folsom:
/OpenStack_103a49bb861e485ea05aa78f9b0216bd/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e/vol-dcc14978-4ff1-422b-97e7-f7f668718b9e
That was the reason for driver patch, so I did not have to rename
existing LUNs on Netapp and DFM.
It's almost easier to create all volumes in Folsom and dd the content ;-)
Regards,
BranoZ
dfm_meta.py
Description: Binary data
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Migrate volume from Essex to Folsom
Hey Lean,
Thanks a ton, I would have totally missed the block_device_mapping table
(because on Folsom it lives on the nova db, not cinder's).
Seems you guys already did this stuff? or something similar?
Pablo
On Thu, Jul 4, 2013 at 9:57 AM, Leandro Reox wrote:
> Pablo,
>
> All the logic for device mappings its on the database, so be sure to
> replicate (carefull no to overlap volumes id) all your volume data from the
> table :
>
> - volumes
> - volumes metadata
>
> An the most important one:
>
> - block_device_mappings
>
> On this tables is where actually resides the conection parameters for the
> LUN and the connection method (driver specs)
>
> {"driver_volume_type": "iscsi", "data": {"device_path":
> "/dev/disk/by-path/ip-10.1.1.100:3260-iscsi-iqn.1992-08.com.netapp:sn.1874337601-lun-0",
> "target_discovered": false, "target_iqn":
> "iqn.1992-08.com.netapp:sn.1874337601", "target_portal": "10.1.1.100:3260",
> "volume_id": 26, "target_lun": "0"}}
>
> This info is what nova uses to trigger the isciadm commands to attach the
> lun to the VM when volume_attach() is called,
>
> And dont you forget to respect all the metadata and types values on the
> tables:
>
> volume_types
> volume_types_extra_specs
>
> And the values matches the ones that you have dumped on the migrated volume
>
> With all of this you should be good to go without issues
>
> Best
>
> Lean
> Mercadolibre Cloudbuilders Team
>
>
> On Wed, Jul 3, 2013 at 6:24 PM, pablo fernandez <
> fernandezpabl...@gmail.com> wrote:
>
>> Hi list!
>>
>> I'm working on a company that has 2 openstack clouds, an essex
>> installation and a folsom one. I'm trying to migrate a netApp volume from
>> one to the other, checking the required fields in the database to copy the
>> metadata. Obviously both volumes would be detached.
>>
>> Any advice on this? Has somebody already tried it (and hopefully
>> succeeded). It's really important for us in order to upgrade our openstack
>> version, you'll understand it's impossible for us to do a "flip-the-switch"
>> migration.
>>
>> Thanks a lot.
>>
>> Pablo
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Migrate volume from Essex to Folsom
Pablo,
All the logic for device mappings its on the database, so be sure to
replicate (carefull no to overlap volumes id) all your volume data from the
table :
- volumes
- volumes metadata
An the most important one:
- block_device_mappings
On this tables is where actually resides the conection parameters for the
LUN and the connection method (driver specs)
{"driver_volume_type": "iscsi", "data": {"device_path":
"/dev/disk/by-path/ip-10.1.1.100:3260-iscsi-iqn.1992-08.com.netapp:sn.1874337601-lun-0",
"target_discovered": false, "target_iqn":
"iqn.1992-08.com.netapp:sn.1874337601", "target_portal": "10.1.1.100:3260",
"volume_id": 26, "target_lun": "0"}}
This info is what nova uses to trigger the isciadm commands to attach the
lun to the VM when volume_attach() is called,
And dont you forget to respect all the metadata and types values on the
tables:
volume_types
volume_types_extra_specs
And the values matches the ones that you have dumped on the migrated volume
With all of this you should be good to go without issues
Best
Lean
Mercadolibre Cloudbuilders Team
On Wed, Jul 3, 2013 at 6:24 PM, pablo fernandez
wrote:
> Hi list!
>
> I'm working on a company that has 2 openstack clouds, an essex
> installation and a folsom one. I'm trying to migrate a netApp volume from
> one to the other, checking the required fields in the database to copy the
> metadata. Obviously both volumes would be detached.
>
> Any advice on this? Has somebody already tried it (and hopefully
> succeeded). It's really important for us in order to upgrade our openstack
> version, you'll understand it's impossible for us to do a "flip-the-switch"
> migration.
>
> Thanks a lot.
>
> Pablo
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] Migrate volume from Essex to Folsom
Hi list! I'm working on a company that has 2 openstack clouds, an essex installation and a folsom one. I'm trying to migrate a netApp volume from one to the other, checking the required fields in the database to copy the metadata. Obviously both volumes would be detached. Any advice on this? Has somebody already tried it (and hopefully succeeded). It's really important for us in order to upgrade our openstack version, you'll understand it's impossible for us to do a "flip-the-switch" migration. Thanks a lot. Pablo ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Swift] Updating best practices for XFS inode size
On Mon, Jul 1, 2013 at 9:02 AM, Robert van Leeuwen wrote: >> I would like to thank the XFS folks at Redhat for letting us know about the >> improvements in XFS, >> and the XFS team in general for the great work they have done. > Thanks for the heads up. > Do you, or any of the Redhat people, know if the Red Hat 6 kernel is also > recent enough (are those improvements back-ported to RHEL 6)? I was wondering that too and would love to know which distro/kernel version have those improvements. The only thing I can find in the kernel logs is that patch : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8daaa83145ef1f0a146680618328dbbd0fa76939 which is quite old (but recent when if are talking stable ;)) Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Horizon] [UX] phabriactor/pholio as a possible UX option
Hi! I am very sorry for the late answer - I was really busy last week. Going back to this topic, answering inline: On 2013/26/06 23:05, Monty Taylor wrote: Hi! Thanks for looking in to Phabricator for us! The feedback is helpful. I think we've also got some concerns around elements of it as well. However, I still don't feel like I fully understand what the requirements list are here. github isn't a requirement, it's a suggested solution, and one with already distressing massive negative implications. so I'd like us to work on what requirements the tool needs to have so that we can figure out solutions that will solve them. Agree with you. So far, my understanding is that requirements are: - discussion Yes, very well handled discussions are #1. I'd also add few features which I'd love to see there if possible: * Great threading of discussions * Labels (E.g. label for closed discussion, or implementation discussion, or design proposals, etc) - so the users know what is happening in the thread * Formatting of messages (there might happen also implementation discussion above designed solution and I wouldn't be afraid of better formatting and letting these conversations happen there) - messages containing images +1, yes. - possibly specific image annotation/commenting Inline comments on images are not that necessary from my experience. Are there any others I've missed? * I think also important are well handled notifications. With features like e-mail/web based, watch/unwatch thread or similar functionality. * It might be indirect requirement, but I see very important that the tool is user-friendly for designers as well as developers. So I'd expect something not that much graphical, but very well organized and effective supporting all needs for both sides. - I guess designers (or creative people) are not that much demanding :). As long as it is not happening in Terminal and is well organized, I think they can get used to very easily. - For developers, I'd expect something not very graphic oriented/shiny, but more efficient and good possibility of formatting (e.g. for very short code examples). To summarize things we've learned so far about possible solutions: - Launchpad Bugs don't work due to lack of images - Phabricator is too image centric, and also confusing - github issues is not open source, and also increases confusion about OpenStack's use of github, and is not integrated with the rest of the project - mailing list is too text oriented and has a bad threading model OK, agree here. We've got folks working on the area - so let's figure out what we need and then we can move forward. Great, if there are folks who could help with finding best solution, they are very welcome! thanks! Monty [snip of replied message] Cheers -- Jarda ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack] OpenStack XCP with Quantum
Hi, I am not a Neutron expert, but what I learned, is that it has a very flexible architecture. With XenServer, your compute openvswitch is in dom0, so you need to get an agent to controll that, to create the ports for you. The issue is, that your OpenStack VM is not the same as dom0. One option would be to run the agent somehow in dom0. That would require you to install all the dependencies of the agent in dom0. I never tried this way, and changing dom0 is not really what I would do. The other option is to run the agent in your domU, and ask that agent to execute commands on dom0 instead of domU. Maru's patch is doing this: https://review.openstack.org/#/c/15022/ This change got merged to trunk. All in one In devstack, you could install an all in one installation, this is what described in the linked wiki page. There is a picture referenced, which might help you to understand the resulting configuration: http://goo.gl/BuAdg So, in that case, you end up with two agents running in domU. One is controlling the domU openvswitch, the other is controlling the dom0s. So if you install the agent in dom1, and you have the mentioned patch, or something equivalent, then you can configure your agent to controll the dom0 bridge (depends on what rootwrap are you using). Let me know if further help is needed. Also, if you could draw a diagram to describe your problem, that would also help. Mate On Thu, Jul 04, 2013 at 11:18:18AM +0800, yuanpu wrote: > Hi Mate, Chandler, > i have the same problem, and now my biggest question is (where i cannot > google or baidu a answer) > whether i should make port like "ovs-vsctl add-port br-int tap tag=3" > manually on dom0(XCP host,compute node), > or install a openvswitch agent on dom1(control node,vm) then the openvswitch > agent remote add this port on dom0, > for a new vm that run on dom0. > > the xcp + openstack + quantum + openvswitch make me confused. > > the following figure is our topology use kvm, do you have xcp map? > > > > > > > yuan > > From: Mate Lakat > Date: 2013-07-03 17:19 > To: Chandler Li > CC: OpenStack > Subject: Re: [Openstack] [OpenStack] OpenStack XCP with Quantum > Hi Chandler, > > XenServer quantum-ovs patches did not make grizzly unfortunately. Trunk > should be fine, although remember, that it is a fast moving target. > > See https://wiki.openstack.org/wiki/QuantumDevstackOvsXcp > > Mate > > > On Wed, Jul 03, 2013 at 01:33:10PM +0800, Chandler Li wrote: > > Hi, > > > > I am trying to use OpenStack grizzly to control XCP hypervisor, and trying > > to use quantum ovs plugin to implement network function. But the official > > document makes me confused. ( > > http://docs.openstack.org/grizzly/openstack-compute/install/apt/content/introduction-to-xen.html#xen-config-reference). > > Does that means XCP + OpenStack only can use nova-network? Is there any > > document can briefly describe how OpenStack + XCP with Quantum and manual > > installation guide? > > > > Thanks, > > Chandler Li > > > ___ > > Mailing list: https://launchpad.net/~openstack > > Post to : openstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > > -- > Mate Lakat > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp -- Mate Lakat ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Design] Why/how object storage(Swift) better than scale-out NAS?
On Wed, Jul 3, 2013 at 8:47 AM, Li, Leon wrote: > However a scale-out NAS could also have these benefits, if you build the > scale-out NAS with open source cluster FS(for example HDFS), just like many > Internet company did. Please feel free to considerate contributing to this blueprint effort : https://blueprints.launchpad.net/swift/+spec/diskfile-databasebroker-as-apis which would potentially allows you to plug your scale-out NAS (or whatever you call it) to swift Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
