date:20130704

Re: [Openstack] [Design] Why/how object storage(Swift) better than scale-out NAS?

2013-07-04 Thread Chmouel Boudjnah

On Wed, Jul 3, 2013 at 8:47 AM, Li, Leon leon@emc.com 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

Re: [Openstack] [OpenStack] OpenStack XCP with Quantum

2013-07-04 Thread Mate Lakat

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] [Horizon] [UX] phabriactor/pholio as a possible UX option

2013-07-04 Thread Jaromir Coufal


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] [Swift] Updating best practices for XFS inode size

2013-07-04 Thread Chmouel Boudjnah

On Mon, Jul 1, 2013 at 9:02 AM, Robert van Leeuwen
robert.vanleeu...@spilgames.com 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

[Openstack] Migrate volume from Essex to Folsom

2013-07-04 Thread pablo fernandez

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] Migrate volume from Essex to Folsom

2013-07-04 Thread Leandro Reox

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.comwrote:

 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

2013-07-04 Thread pablo fernandez

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 leandro.r...@gmail.com 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

2013-07-04 Thread Brano Zarnovican

On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
fernandezpabl...@gmail.com 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

2013-07-04 Thread Leandro Reox

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 zarnovi...@gmail.comwrote:

On Wed, Jul 3, 2013 at 11:24 PM, pablo fernandez
fernandezpabl...@gmail.com 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..

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.

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

Re: [Openstack] Migrate volume from Essex to Folsom

2013-07-04 Thread pablo fernandez

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 leandro.r...@gmail.comwrote:

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