Re: [Openstack] Grizzly on Laptop running Ubuntu 12.04 Desktop 64-bit and having 2 NICs (one Ethernet and other Wireless)

[Philip Keogh]

Given this node is your laptop, I assume the OpenStack environment is for 
testing.

If that is the case, have you considered running a VM? (using Virtual Box for 
example) You can add virtual
NICs to VMs for testing.

Something like RDO on top of CentOS or Fedora would get you going quickly. 
There's also DevStack for Ubuntu.

http://openstack.redhat.com/Quickstart
http://devstack.org/guides/single-vm.html

On May 13, 2013, at 7:36 AM, "Devendra Gupta" 
mailto:dev29...@gmail.com>> wrote:

Hi,

I am setting up Grizzly in single node on my laptop running Ubuntu
12.04 Desktop 64-bit for POC, I am using a doc which say 2 NICs are
required (please see
https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_SingleNode/OpenStack_Grizzly_Install_Guide.rst
doc).

I have two NICs in my laptop one is Ethernet and other is Wireless so
is it fine to setup the environment on it ? Another thing, what if I
am disconnected from any of the network because then I don't have IP
in that specific NIC ?

Please see the result of ifconfig below (when network is connected):

root@devendra-HP-ProBook-6460b:/home/devendra# ifconfig -a
eth0  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
 inet addr:10.128.249.72  Bcast:10.128.249.255  Mask:255.255.254.0
 inet6 addr: fe80::2e41:38ff:fe00:ab9d/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:7026 errors:0 dropped:155 overruns:0 frame:0
 TX packets:4870 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:3349362 (3.3 MB)  TX bytes:1076679 (1.0 MB)
 Interrupt:20 Memory:d470-d472

eth1  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
 inet addr:172.16.3.152  Bcast:172.16.3.255  Mask:255.255.255.0
 inet6 addr: fe80::ae81:12ff:fe91:6efa/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:15 errors:0 dropped:0 overruns:0 frame:0
 TX packets:49 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:6392 (6.3 KB)  TX bytes:9341 (9.3 KB)
 Interrupt:19

loLink encap:Local Loopback
 inet addr:127.0.0.1  Mask:255.0.0.0
 inet6 addr: ::1/128 Scope:Host
 UP LOOPBACK RUNNING  MTU:16436  Metric:1
 RX packets:15737 errors:0 dropped:0 overruns:0 frame:0
 TX packets:15737 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:1884492 (1.8 MB)  TX bytes:1884492 (1.8 MB)

So my OpenStack environment would be working in case IP is not
available on any/both of the NICs when network is disconnected ?
Please suggest.

Thanks,
Devendra Gupta

___
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] Grizzly on Laptop running Ubuntu 12.04 Desktop 64-bit and having 2 NICs (one Ethernet and other Wireless)

[Lloyd Dewolf]

On Mon, May 13, 2013 at 7:34 AM, Devendra Gupta  wrote:
> Hi,
>
> I am setting up Grizzly in single node on my laptop running Ubuntu
> 12.04 Desktop 64-bit for POC, I am using a doc which say 2 NICs are
> required (please see
> https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_SingleNode/OpenStack_Grizzly_Install_Guide.rst
> doc).
>
> I have two NICs in my laptop one is Ethernet and other is Wireless so
> is it fine to setup the environment on it ? Another thing, what if I
> am disconnected from any of the network because then I don't have IP
> in that specific NIC ?

Skimming through those instructions it looks like the requirement for
2 nics is specific to making your OpenStack install available on the
Internet in a secure-ish manner.

___
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] ConnectQuantum to VLAN-tagged physical network

[Yiting Wu]

Hi Angelo,


I had the same problem with you.
when I try:

# ovs-vsctl add-br br-dev
# ovs-vsctl add-port br-dev eth1 tag=108

and it doesn't work.

Does it mean we have to use vconfig to add a eth1.108 virtual interface,
and add it into bridge?
But OpenVSwitch suppose to support vlan directly.

That's a bit tricky.



On Mon, May 13, 2013 at 4:06 AM, Angelo Olivera  wrote:

> Salvatore, thanks for your reply. It took me a few tries but I finally
> solved this issue by creating the vlan devices on the respective
> interfaces, adding them to the corresponding bridges with ovs-vsctl
> and configuring two external networks with quantum.
>
> This would correspond to the "Multiple Flat Network" use case
> described in the Grizzly Networking Administration Guide[1], although
> the configuration is not explained. Quantum provides DHCP with default
> routes 10.33.8.1 (vlan 108) and 10.33.9.1 (vlan 109). Namespaces are
> used and there is one instance of the metadata proxy per each
> namespace.
>
> [1]
> http://docs.openstack.org/grizzly/openstack-network/admin/content/use_cases_multi_flat.html
>
> /etc/network/interfaces
> auto lo
> iface lo inet loopback
>
> auto eth0
> iface eth0 inet static
> address 10.33.10.210
> netmask 255.255.255.0
> gateway 10.33.10.1
>
> auto eth1
> iface eth1 inet manual
>
> auto eth1.108
> iface eth1.108 inet manual
> vlan-raw-device eth1
> up /sbin/ifconfig eth1.108 up
>
> auto eth1.109
> iface eth1.109 inet manual
> vlan-raw-device eth1
> up /sbin/ifconfig eth1.109 up
>
> /etc/quantum/quantum.conf
> [DEFAULT]
> lock_path = $state_path/lock
> bind_host = 0.0.0.0
> bind_port = 9696
> core_plugin =
> quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
> api_paste_config = /etc/quantum/api-paste.ini
> control_exchange = quantum
> rabbit_host = 10.33.10.210
> notification_driver = quantum.openstack.common.notifier.rpc_notifier
> default_notification_level = INFO
> notification_topics = notifications
> [QUOTAS]
> [DEFAULT_SERVICETYPE]
> [AGENT]
> root_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf
> [keystone_authtoken]
> auth_host = 127.0.0.1
> auth_port = 35357
> auth_protocol = http
> admin_tenant_name = service
> admin_user = quantum
> admin_password = ###
> signing_dir = /var/lib/quantum/keystone-signing
>
> /etc/quantum/dhcp_agent.ini
> [DEFAULT]
> interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver
> dhcp_driver = quantum.agent.linux.dhcp.Dnsmasq
> use_namespaces = True
> enable_isolated_metadata = True
>
> /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini
> [DATABASE]
> sql_connection = mysql://quantum##@10.33.10.210/quantum?charset=utf8
> reconnect_interval = 2
> [OVS]
> # even when using flat networking these two variables had to be
> defined for the multiple physical networks to work
> tenant_network_type = vlan
> network_vlan_ranges = physdev:2048:4094,physqa:2048:4094
> bridge_mappings = physdev:br-dev,physqa:br-qa
> [AGENT]
> polling_interval = 2
> [SECURITYGROUP]
> firewall_driver =
> quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
>
> # ovs-vsctl add-br br-int
> # ovs-vsctl add-br br-dev
> # ovs-vsctl add-port br-dev eth1.108
> # ovs-vsctl add-br br-qa
> # ovs-vsctl add-port br-qa eth1.109
> # quantum net-create --shared dev --provider:network_type flat
> --router:external=True --provider:physical_network physdev
> # quantum net-create --shared qa --provider:network_type flat
> --router:external=True --provider:physical_network physqa
> # quantum subnet-create dev 10.33.8.0/24 --name dev-subnet
> --allocation-pool start=10.33.8.10,end=10.33.8.254
> # quantum subnet-create qa 10.33.9.0/24 --name qa-subnet
> --allocation-pool start=10.33.9.10,end=10.33.9.254
>
> (Question also posted on
> https://answers.launchpad.net/quantum/+question/228437/)
>
> Regards,
>
> --
> Angelo
>
> On Thu, May 9, 2013 at 8:07 AM, Salvatore Orlando 
> wrote:
> > Your configuration looks correct, and provider networks are what you need
> > for implementing this use case.
> >
> > Is the traffic for your subnets improperly tagged, or are you unable at
> all
> > to forward traffic?
> > If you're not using GRE overlays it might make sense verifying that VLAN
> > 108/109 are allowed on physical switch ports or that the physical switch
> > ports are in trunk mode.
> >
> >
> > Regards,
> > Salvatore
> >
> >
> > On 8 May 2013 20:21, Ashok Kumaran  wrote:
> >>
> >> Hi Angelo,
> >>
> >> This should be possible. Make sure that eth1 is connected to the Vlan
> >> trunk with necessary port configurations.
> >>
> >> Create 2 network with segmentation's ID as 108 and 109 respectively.
> >> Create the respective subnets for both network and then proceed with
> further
> >> configurations as needed. Are you facing any specific issues here?
> >>
> >> -Ashok
> >>
> >>
> >> On Wed, May 8, 2013 at 9:57 PM, Angelo Olivera 
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I am using Ubuntu 12.04 and OpenStack Grizzly from the Ub

[Openstack] Unable to run Instance, Ends with status Error in OpenStack

[Dhanasekaran Anbalagan]

Hi Guys,

I am trying to start instance it's says instance status Error.
In horizon log tab  Unable to get log for instance
"c307ae2b-c09d-4c05-9525-906ed35d81c5".

This my /var/log/nova/nova-compute.log

2013-05-13 15:59:38.717 3014 TRACE nova.compute.manager [instance:
c307ae2b-c09d-4c05-9525-906ed35d81c5] QuantumClientException: 404 Not Found
2013-05-13 15:59:38.717 3014 TRACE nova.compute.manager [instance:
c307ae2b-c09d-4c05-9525-906ed35d81c5]
2013-05-13 15:59:38.717 3014 TRACE nova.compute.manager [instance:
c307ae2b-c09d-4c05-9525-906ed35d81c5] The resource could not be found.

http://paste.ubuntu.com/5662352/

Please guide me.

Did I learn something today? If not, I wasted it.
___
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] Guest PXE Boot

[David Hill]

Hello Monty,

I haven't had the time to play with baremetal yet but it is on my todo 
list. 
I know I may be doing it wrong but when I create my Linux/Windows/ETC images, 
I'm 
using the kickstarting solution we already have in place and I was simply 
trying to PXE
boot my images from my lab as it is faster (better hardware, more memory).

I'm wondering if this patch could make it trunk?   I enjoyed the 
libvirt.xml.template before 
it got removed and found this solution (quick and easy).

I will definitely look at the baremetal (after seeing what it can do at the 
summit).

Thank you very much,

Dave


-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com] 
Sent: May-11-13 4:18 PM
To: David Hill
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Guest PXE Boot

Neat!

Have you seen any of the work around nova baremetal (which is
transitioning to be called ironic?) Related to that is a set of "virtual
power drivers" which allow for treating virtual machines like real
machines - so that you can use nova to pxe boot a kvm or a virtualbox or
a vmware instance.

I know it's not exactly the same thing, but I don't know what you're
trying to accomplish. Perhaps what you want is similar enough to work
together?

Monty

On 05/10/2013 12:55 PM, David Hill wrote:
> Hi guys,
> 
>  
> 
> I was trying to PXE boot a guest for quite some time now and I think
> I've found a solution that is kind of hackish but pretty simple.   I'm
> not quite sure it's good to go in trunk but felt like I'd share it since
> I've been messing a while on this.  
> 
> If anybody have a better solution, I would really like to hear/see/try it ...
> 
>  
> 
> Here is how I did it:
> 
>  
> 
> First, patch the libvirt/driver.py file:
> 
> --- /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py.orig  
> 2013-05-10 16:25:17.787862177 +
> 
> +++ /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py   
> 2013-05-10 16:26:39.442022870 +
> 
> @@ -87,6 +87,9 @@
> 
> LOG = logging.getLogger(__name__)
> 
>  
> 
> libvirt_opts = [
> 
> +cfg.StrOpt('default_guest_boot_dev',
> 
> +   default='hd',
> 
> +   help='Sets the default guest boot device'),
> 
>  cfg.StrOpt('rescue_image_id',
> 
> default=None,
> 
> help='Rescue ami image'),
> 
> @@ -1792,7 +1795,7 @@
> 
> instance['name'],
> 
> "ramdisk")
> 
>  else:
> 
> -guest.os_boot_dev = "hd"
> 
> +guest.os_boot_dev = FLAGS.default_guest_boot_dev
> 
>  
> 
>  if FLAGS.libvirt_type != "lxc" and FLAGS.libvirt_type != "uml":
> 
>  guest.acpi = True
> 
>  
> 
>  
> 
> And add to nova.conf:
> 
> default_guest_boot_dev=network
> 
>  
> 
> And finally add to /etc/dnsmasq.conf
> 
> dhcp-boot=boot\x86\pxelinux.com,host_name,host_ip
> 
> dhcp-no-override
> 
>  
> 
> And restart dnsmasq.conf
> 
>  
> 
> In my actual setup, the guest will PXE boot, show the menu 60 seconds
> and then boot from hard disk after the 60 seconds timeout.
> 
>  
> 
>  
> 
> Thank you very much,
> 
>  
> 
> Dave
> 
> 
> 
> ___
> 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] Understanding the metadata service

[Greg Chavez]

Even after reading all the posts and IRC chatter regarding how to
configure VM metadata services, I'm no closer to understanding how
this should be set up in *my* environment. As it stands, my VMs are
fully functional (available from external network via floaters) but
cannot connect to 169.254.169.254.

I am running Grizzly on Raring, with per-tenant routers,
ip-namespaces/overlapping-ips, GRE tunneling, and a separate network
node with three NICs for public, management, and vm config nets.
Also:

I have nova-api installed on the compute node.  It is listening for
8775 on the controller's management network.

The relavent configurations:


controller nova.conf:
--
service_quantum_metadata_proxy = True
quantum_metadata_proxy_shared_secret = PvUafKreIImX3OePynlc
metadata_host = 192.168.241.100
metadata_listen = 192.168.241.100
metadata_listen_port = 8775

net-node quantum.conf / dhcp_agent.ini / l3_agent.ini
--
allow_overlapping_ips = True

net-node metadata_agent.ini
--
nova_metadata_ip = 192.168.241.100
nova_metadata_port = 8775
metadata_proxy_shared_secret = PvUafKreIImX3OePynlc

compute nodes nova.conf
--
service_quantum_metadata_proxy = True
quantum_metadata_proxy_shared_secret = PvUafKreIImX3OePynlc


What am I missing here?  Thanks in advance.

--
\*..+.-
--Greg Chavez
+//..;};

___
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-community] [Ask] Guidelines for answering question on Ask

[Stefano Maffulli]

[trimming the cc]

On Sat 11 May 2013 07:30:13 AM PDT, John Wong wrote:

Can we have a template?
I think it would be really helpful if by default there is a template /
form to fill out. Not sure if the underlying software has that mechanism.

Basically to do support, it'd really important to know the version
used, system.


I think it's a good idea. The software allows already to insert a short 
text blurb on


https://ask.openstack.org/questions/ask/

People don't usually read but I think it's better to put something 
there than nothing :) What would you write there?



--
Ask and answer questions on https://ask.openstack.org

___
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 and disk usage

[Paras pradhan]

Thanks Christian you have been a good help !

Paras.


On Sat, May 11, 2013 at 3:14 AM, Christian Schwede  wrote:

> Hi Paras,
>
> Am 08.05.13 22:02, schrieb Paras pradhan:
> > Thanks Christian. How do we keep track of the usage? For example with 5
> > nodes i.e 40TB. How do we know how much space has been consumed out of
> > this 40TB?
>
> well, that depends on the used authentication scheme. If you are using
> swauth and don't have thousands of users, this gist might help you:
>
> https://gist.github.com/cschwede/5559268
>
> It reports the used bytes for every account and the total size. Please
> note that the returned account list is not sorted.
>
> On the other side you can simply monitor all of your disks, sum up all
> used byte values and divide by the number of replicas (3).
>
> You might also use account_quotas, which blocks further write requests
> if the quota on an account is exceeded. It is especially useful for
> smaller private storage clusters.
>
>
> http://docs.openstack.org/developer/swift/misc.html#module-swift.common.middleware.account_quotas
>
>
> Christian
>
>
> >
> > Paras.
> >
> >
> >
> > On Wed, May 8, 2013 at 2:44 PM, Christian Schwede  > > wrote:
> >
> > Am 08.05.13 21:18, schrieb Paras pradhan:
> > > I have a three nodes swift cluster. I can see the objects being
> > > replicated to all three nodes.  Each node has 12 2TB disks. Since I
> > > have 3 replicas the usable space is only 24TB ?
> >
> > Yes, that's correct.
> >
> > > How this will scale up if we add two more storage nodes of the same
> > > capacity?
> >
> > 5 * 12 * 2 / 3: ~ 40TB usable capacity.
> >
> > > Also, is there any tool to monitor the usage, health of the whole
> > > cluster?
> >
> > To detect failed drives you might have a look at
> >
> http://docs.openstack.org/developer/swift/admin_guide.html#detecting-failed-drives
> >
> > For Swift-related monitoring please refer to
> >
> http://docs.openstack.org/trunk/openstack-object-storage/admin/content/ch_introduction-to-openstack-object-storage-monitoring.html
> >
> > For general node monitoring you can use your preferred tool (Nagios,
> > Icinga, Shinken, RHQ, Hyperic...).
> >
> > ___
> > 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] Folsom 2012.2.4 Ubuntu Packages

[Joe Topjian]

Hello,

Does anyone know when the Folsom 2012.2.4 release will be available in the
Ubuntu Cloud Archive?

Thanks,
Joe

-- 
Joe Topjian
Systems Administrator
Cybera Inc.

www.cybera.ca

Cybera is a not-for-profit organization that works to spur and support
innovation, for the economic benefit of Alberta, through the use
of cyberinfrastructure.
___
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] New code name for networks

[Monty Taylor]

On 05/13/2013 11:03 AM, Doug Hellmann wrote:
> 
> 
> 
> On Sat, May 11, 2013 at 5:48 PM, Anne Gentle  > wrote:
> 
> 
> 
> 
> On Sat, May 11, 2013 at 3:12 PM, Monty Taylor  > wrote:
> 
> 
> 
> On 05/11/2013 04:07 PM, Asher Newcomer wrote:
> > Or even better, just continue to call it openstack networking.
> The code
> > names only serve to confuse the uninitiated. They needlessly
> steepen the
> > learning curve and slow uptake.
> 
> The problem with OpenStack Networking (or getting rid of
> codenames) is
> seen with pre-incubation->incubation->integrated cycle.
> 
> A project cannot call itself "OpenStack Foo" until it actually _is_
> openstack foo. So any new project by necessity has to start off as
> something else.
> 
> But - if we then require them to drop that name and become
> openstack foo
> when they become incubated or integrated, then we've got what's
> become a
> stable project with a decent amount of contributors renaming itself.
> 
> Every. Time.
> 
> The code names aren't just cute. I kind of wish they were,
> because it
> would make several things much easier if we could just ditch
> them and do
> a pure openstack. code namespace. But the reality is that it
> gets really
> really tricky to deal with a bunch of things if they go away.
> 
> 
> I told Monty and the TC this at the Summit (sorry I couldn't attend
> the session about code names). I find this trickiness a weak
> argument in the face of the invented names that are getting to be as
> bad as U.S. pharmaceuticals. Plus it forces us to put a "lookup"
> table in the docs forever. [1] Let's find a process for naming that
> meets a few reqs:
> - describes the service
> - goes through a legal review
> - enables new eyes to understanding it by reading the English word
> that the service represents (that can be translated into a
> meaningful word in other languages)
> 
> If we have to preface with Stackforge to indicate pre-incubation,
> that's fine. Use Incubating or some such to indicate incubation.
> Meaningful words have meaning. 
> 
> 
> +1
> 
> Use a namespace package "openstack" then each project has a unique
> package under that for their meaningfully named package (compute,
> networking, etc.).
> 
> We only have to rename projects if they start out with "bad" names to
> begin with. Projects that want to be integrated should be developing on
> stackforge and using the openstack namespace package.

It's just logically infeasible. If we were to make that choice, I'm
pretty sure we'd have to stop everything that everyone is doing and just
deal the fallout from doing it.

In any case - we did have a session on this at the summit, and we did
lay out a strategy for moving forward. The etherpad is here

https://etherpad.openstack.org/ProjectsReNaming

tl;dr - we are going to rename quantum to a new codename, and we are
going to do our best as a community to lessen the external usage of our
codenames.

> I acknowledge we still have to indicate what commands, daemon names,
> and so on are related to a particular service. That issue is also
> fixable with some resources and effort and pays off in easier
> adoption and understanding.
> 
> 
> The unified command line project will resolve the command issue because
> all commands will be "openstack $noun $verb" (end users shouldn't have
> to know which OpenStack component owns a resource in order to operate on
> it via the command line). Daemon startup scripts could use a similar
> framework, or just a naming convention ("openstack-compute-api",
> "openstack-network-api", etc.).

I agree - having the unified command line client will be very helpful to
lessening our externally-facing usages of code names.

> Doug
>  
> 
> 
> Anne
> 
> 1. 
> http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/terminology-codenames.html
>  
>  
> 
> 
> > On May 11, 2013 3:59 PM, "Davanum Srinivas"  
> > >> wrote:
> >
> > Lattice
> >
> > -- dims
> >
> > On Sat, May 11, 2013 at 3:52 PM, Mark Turner
> mailto:m...@amerine.net>
> > >> wrote:
> > > Tubes
> > >
> > > ;-)
> > >
> > >
> > > On Sat, May 11, 2013 at 12:51 PM, Jason Smith
> >  
>  >>
> > > wrote:
> > >>
> > >> Hello,
> >   

Re: [Openstack] New code name for networks

[Doug Hellmann]

On Mon, May 13, 2013 at 11:30 AM, Sean Dague  wrote:

> On 05/13/2013 11:03 AM, Doug Hellmann wrote:
>
>>
>>
>> +1
>>
>> Use a namespace package "openstack" then each project has a unique
>> package under that for their meaningfully named package (compute,
>> networking, etc.).
>>
>
> Sounds great and all, except when you try to do something like quantum, or
> even cinder, where you break out function into another project.
>
> from openstack import network <- wait, is that what used to be nova
> network, or quantum, or some abstraction?
>

Fair point, and those specific examples of names may not be good. :-)

On the other hand, there's no reason each team needs to be limited to
deploying a single package. If nova network was "openstack.network" to
begin with, then perhaps quantum could have just been an evolution of that.


>
> from openstack.compute import network as compute_network ?
>
> Code names are actually incredibly useful in developing this stuff,
> because it lets us think about an implementation separate from a concept,
> and work with non native english speakers a lot easier where concept vs.
> implementation.
>
> Honestly, there is already incredible confusion when you talk with people
> about "compute". Where you have to be really paying attention to nuance to
> figure out if people meant "Nova as a whole", "the Nova compute daemon", "A
> nova compute node, which might also have nova-network on it". The number of
> times we had to explain no-db-compute blueprint because of that speaks to
> the fact that generic names do not make anything easier, they generate more
> confusion quite often.
>
> Code names are useful because it gives us a whole other namespace of words
> to work with to be very specific about what we mean, that can't be confused
> for the generic concepts of networking or computing. Yes, it's inside
> baseball, but when you are dealing with code as complicated as OpenStack,
> not having that inside baseball really slows things down.
>

This seems like a stronger argument than "it's hard to rename things"
(which I think is at least a large part of the argument against moving away
from code names during/after incubation).

FWIW, I'm in favor of not branding every little thing we do "openstack,"
especially when components can be reused by other projects (I would love to
see us acquire a few downstream users of some of the Oslo libraries, for
example). But for the big core stuff, it feels weird to have separate
commands, separate package namespaces, etc.


>
> Just look at the regular confusion new people have about the 2 uses of the
> term migrations in Nova, one for the database schema, and one for moving
> guests around. :)


I'm not sure we're going to eliminate confusion entirely. I'm not even sure
changing anything will reduce it. But it does seem like we can minimize
legal issues by avoiding using code names in the code, which is where this
thread started.

Doug


>
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
___
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] heat and quantum

[Molnár Mihály László]

Hi all!

I want to try heat, but my instance doesnt start up. As I can see the
network doesn't configured.
So I looked into the template:
https://github.com/openstack/heat-templates/blob/master/cfn/WordPress_Single_Instance_With_Quantum.template

As I can see, there is something configured for quantum, but I cant find
any documentation how should I configure it for an existing network. I
tried to replace IPs with mine, but it doesn't work.

Do you have any idea where should I look for more info?
Except this letter:
http://lists.openstack.org/pipermail/openstack-dev/2012-November/002355.htmlI
couldnt find anything relating these options.

Thanks!

Rusty
___
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] New code name for networks

[Sean Dague]

On 05/13/2013 11:03 AM, Doug Hellmann wrote:



+1

Use a namespace package "openstack" then each project has a unique
package under that for their meaningfully named package (compute,
networking, etc.).


Sounds great and all, except when you try to do something like quantum, 
or even cinder, where you break out function into another project.


from openstack import network <- wait, is that what used to be nova 
network, or quantum, or some abstraction?


from openstack.compute import network as compute_network ?

Code names are actually incredibly useful in developing this stuff, 
because it lets us think about an implementation separate from a 
concept, and work with non native english speakers a lot easier where 
concept vs. implementation.


Honestly, there is already incredible confusion when you talk with 
people about "compute". Where you have to be really paying attention to 
nuance to figure out if people meant "Nova as a whole", "the Nova 
compute daemon", "A nova compute node, which might also have 
nova-network on it". The number of times we had to explain no-db-compute 
blueprint because of that speaks to the fact that generic names do not 
make anything easier, they generate more confusion quite often.


Code names are useful because it gives us a whole other namespace of 
words to work with to be very specific about what we mean, that can't be 
confused for the generic concepts of networking or computing. Yes, it's 
inside baseball, but when you are dealing with code as complicated as 
OpenStack, not having that inside baseball really slows things down.


Just look at the regular confusion new people have about the 2 uses of 
the term migrations in Nova, one for the database schema, and one for 
moving guests around. :)


-Sean

--
Sean Dague
http://dague.net

___
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] New code name for networks

[Doug Hellmann]

On Sat, May 11, 2013 at 5:48 PM, Anne Gentle  wrote:

>
>
>
> On Sat, May 11, 2013 at 3:12 PM, Monty Taylor wrote:
>
>>
>>
>> On 05/11/2013 04:07 PM, Asher Newcomer wrote:
>> > Or even better, just continue to call it openstack networking. The code
>> > names only serve to confuse the uninitiated. They needlessly steepen the
>> > learning curve and slow uptake.
>>
>> The problem with OpenStack Networking (or getting rid of codenames) is
>> seen with pre-incubation->incubation->integrated cycle.
>>
>> A project cannot call itself "OpenStack Foo" until it actually _is_
>> openstack foo. So any new project by necessity has to start off as
>> something else.
>>
>> But - if we then require them to drop that name and become openstack foo
>> when they become incubated or integrated, then we've got what's become a
>> stable project with a decent amount of contributors renaming itself.
>>
>> Every. Time.
>>
>> The code names aren't just cute. I kind of wish they were, because it
>> would make several things much easier if we could just ditch them and do
>> a pure openstack. code namespace. But the reality is that it gets really
>> really tricky to deal with a bunch of things if they go away.
>>
>
> I told Monty and the TC this at the Summit (sorry I couldn't attend the
> session about code names). I find this trickiness a weak argument in the
> face of the invented names that are getting to be as bad as U.S.
> pharmaceuticals. Plus it forces us to put a "lookup" table in the docs
> forever. [1] Let's find a process for naming that meets a few reqs:
> - describes the service
> - goes through a legal review
> - enables new eyes to understanding it by reading the English word that
> the service represents (that can be translated into a meaningful word in
> other languages)
>
> If we have to preface with Stackforge to indicate pre-incubation, that's
> fine. Use Incubating or some such to indicate incubation. Meaningful words
> have meaning.
>

+1

Use a namespace package "openstack" then each project has a unique package
under that for their meaningfully named package (compute, networking, etc.).

We only have to rename projects if they start out with "bad" names to begin
with. Projects that want to be integrated should be developing on
stackforge and using the openstack namespace package.


>
> I acknowledge we still have to indicate what commands, daemon names, and
> so on are related to a particular service. That issue is also fixable with
> some resources and effort and pays off in easier adoption and understanding.
>

The unified command line project will resolve the command issue because all
commands will be "openstack $noun $verb" (end users shouldn't have to know
which OpenStack component owns a resource in order to operate on it via the
command line). Daemon startup scripts could use a similar framework, or
just a naming convention ("openstack-compute-api", "openstack-network-api",
etc.).

Doug


>
> Anne
>
> 1.
> http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/terminology-codenames.html
>
>
>
>>
>> > On May 11, 2013 3:59 PM, "Davanum Srinivas" > > > wrote:
>> >
>> > Lattice
>> >
>> > -- dims
>> >
>> > On Sat, May 11, 2013 at 3:52 PM, Mark Turner > > > wrote:
>> > > Tubes
>> > >
>> > > ;-)
>> > >
>> > >
>> > > On Sat, May 11, 2013 at 12:51 PM, Jason Smith
>> > mailto:jason.sm...@rackspace.com>>
>> > > wrote:
>> > >>
>> > >> Hello,
>> > >> I understand why we had to give up Quantum code name but rather
>> > than just
>> > >> refer to it as networking let's come up with a new code name!
>> > >>
>> > >> Thoughts?
>> > >>
>> > >> Thanks,
>> > >> -js
>> > >> ___
>> > >> 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
>> > >
>> >
>> >
>> >
>> > --
>> > Davanum Srinivas :: http://davanum.wordpress.com
>> >
>> > ___
>> > 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: h

[Openstack] Grizzly on Laptop running Ubuntu 12.04 Desktop 64-bit and having 2 NICs (one Ethernet and other Wireless)

[Devendra Gupta]

Hi,

I am setting up Grizzly in single node on my laptop running Ubuntu
12.04 Desktop 64-bit for POC, I am using a doc which say 2 NICs are
required (please see
https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_SingleNode/OpenStack_Grizzly_Install_Guide.rst
doc).

I have two NICs in my laptop one is Ethernet and other is Wireless so
is it fine to setup the environment on it ? Another thing, what if I
am disconnected from any of the network because then I don't have IP
in that specific NIC ?

Please see the result of ifconfig below (when network is connected):

root@devendra-HP-ProBook-6460b:/home/devendra# ifconfig -a
eth0  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
  inet addr:10.128.249.72  Bcast:10.128.249.255  Mask:255.255.254.0
  inet6 addr: fe80::2e41:38ff:fe00:ab9d/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:7026 errors:0 dropped:155 overruns:0 frame:0
  TX packets:4870 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3349362 (3.3 MB)  TX bytes:1076679 (1.0 MB)
  Interrupt:20 Memory:d470-d472

eth1  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
  inet addr:172.16.3.152  Bcast:172.16.3.255  Mask:255.255.255.0
  inet6 addr: fe80::ae81:12ff:fe91:6efa/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:15 errors:0 dropped:0 overruns:0 frame:0
  TX packets:49 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:6392 (6.3 KB)  TX bytes:9341 (9.3 KB)
  Interrupt:19

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:15737 errors:0 dropped:0 overruns:0 frame:0
  TX packets:15737 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:1884492 (1.8 MB)  TX bytes:1884492 (1.8 MB)

So my OpenStack environment would be working in case IP is not
available on any/both of the NICs when network is disconnected ?
Please suggest.

Thanks,
Devendra Gupta

___
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 Marketing] New code name for networks

[Jason Smith]

Hello Stefano,
Thank you for the information. 

I apologize for cross-posting. I'll make sure and stay away from that in the 
future. 

Thanks,
-js

-- Typo's courtesy of Apple --

On May 12, 2013, at 11:58 PM, "Stefano Maffulli"  wrote:

> Hi Jason,
> 
> thank you for picking up this topic: some people may not be aware of the work 
> that is happening.
> 
> Remember that cross-posting is *evil*: please just don't do it. The best way 
> is to pick one list, the one you think is the best place to start a 
> conversation, and start there. If it's the wrong place, somebody will tell 
> you that and give suggestions.
> 
> On 05/11/2013 12:50 PM, Jason Smith wrote:
> > Hello, I understand why we had to give up Quantum code name but
> > rather than just refer to it as networking let's come up with a new
> > code name!
> 
> This could have been a topic for openstack-dev, IMHO: it needs to be 
> discussed among the developers because it has lots of technical implications 
> for future of the project.
> 
> Anyway, there is a blueprint filed:
> 
> https://blueprints.launchpad.net/quantum/+spec/remove-use-of-quantum
> 
> and the progress is tracked at the weekly meetings. I encourage you to
> participate to them:
> 
> https://wiki.openstack.org/wiki/Meetings#OpenStack_Project_.26_Release_Status_meeting
> 
> In the past meeting
> 
> http://eavesdrop.openstack.org/meetings/project/2013/project.2013-05-07-21.02.log.html
> 
> Mark McClain said:
> 
> 21:31:18  for naming? yes.. will submit a list of name for 
> vetting
> 
> I guess the marketing team can be consulted to help pick the final name from 
> the list, together with the other groups involved in this important decisions.
> 
> Cheers,
> stef
> 
> -- 
> Ask and answer questions on https://ask.openstack.org

___
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] [OSSG][OSSN] Keystone configuration should not be world readable.

[Clark, Robert Graham]

Keystone configuration should not be world readable
---

### Summary ###
In some deployments keystone.conf which contains confidential information, is 
set to world readable.

### Affected Services / Software ###
Keystone, DevStack, Deployment

### Discussion ###
It is important that deployers of OpenStack ensure that keystone.conf is not 
world readable. In some deployments the keystone configuration file is readable 
by all users (and processes) on the installation system. This file should be 
set with the most restrictive permissions that allow the system to continue 
proper operations.

In particular, the password configuration of the LDAP section and the 
admin_token contain secret information:

 being example config snippet 
[ldap]
url = ldap://localhost
user = dc=Manager,dc=example,dc=com
password = None <- should be secret
suffix = cn=example,cn=com
use_dumb_member = False
allow_subtree_delete = False
dumb_member = cn=dumb,dc=example,dc=com

[DEFAULT]
admin_token = passw0rd <- should be secret
 end example config snippet 

### Recommended Actions ###
Ensure that in your deployment keystone.conf uses the most restrictive 
permissions that allow the system to continue proper operations.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1168252
Original LaunchPad Bug : https://bugs.launchpad.net/devstack/+bug/1168252
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2013-1977


___
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] New code name for networks

[Thierry Carrez]

Monty Taylor wrote:
> So, with all due respect to the many awesome lawyers who are involved with 
> the project, what I'm getting at is that we need to do the right thing as 
> best we can based on unofficial advice from well meaning people who may or 
> may not have legal backgrounds as well as input and help from Jonathan Bryce 
> and the foundation board where appropriate.

FWIW Mark McLoughlin tried to organize a bit that "unofficial advice"
and set up a "legal-discuss" mailing-list where this unofficial advice
can be easily and publicly discussed.

http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss

-- 
Thierry Carrez (ttx)
Chair, OpenStack Technical Committee

___
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] New code name for networks

[MARGOLIN, Udi (Udi)]

Since networks are moving quite rapidly, can be quite messy and its pretty
cold out there my suggestion is:

"Blizzard"

-Udi

-Original Message-
From: Openstack
[mailto:openstack-bounces+udi.margolin=alcatel-lucent@lists.launchpad.ne
t] On Behalf Of Thierry Carrez
Sent: Monday, May 13, 2013 12:47 PM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] New code name for networks

Anne Gentle wrote:
> > I told Monty and the TC this at the Summit (sorry I couldn't attend 
> > the session about code names).
> 
> I promise, it wasn't the world's most fun session. :)
> 
> I'm sure. :) I think I don't have much regret but do feel sorry that I 
> don't know more.

The Etherpad is here:
https://etherpad.openstack.org/ProjectsReNaming

I think there is much more value to codenames than just "avoiding the cost
of a rename when the project becomes OpenStack". This was captured in the
session:

Codenames drawbacks and benefits
(-) Lack of trademark protection
(-) Confusing to newcomers
(-) Shadow their more official counterparts
(+) Short names are highly-convenient and efficient, often less ambiguous
(in conversations, executables,  modules...)
(+) Help building project and team identity
(+) Separate the project itself from its functional scope (so they remain
valid even if that scope evolves)

Those last two bits are pretty essential. There is a reason why a functional
description cannot be used as a project name. The project (as in, the code
repository and the community of contributors around it) is
*distinct* from the functional scope of what its code does.

Take Ceilometer ("OpenStack Metering"). What happens when they grow to cover
Monitoring ? You rename the project to "OpenStack Metering and Monitoring" ?
Or you keep the partial functional description ? I'd rather avoid to rename
everything every time a project evolves. Those renames are *extremely*
costly, as we'll soon enough realize.

I find the "confusing" argument pretty weak myself. Brands are used
everywhere, so we are used to make the translation between a name and a
function. Microsoft named its desktop environment "Windows", rather than
"Operating system" or "Desktop environment", and it took people about 5
minutes to get used to it.

> Go with kumquat, but don't call the CLI kumquat. Call your team kumquat
and your repo kumquat. 

If you call the CLI "os-metering", you'll have to rename it when the scope
expands, or live with a name that looks like a functional description but is
not an accurate one. I very much prefer to call it "ceilometer".

--
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


smime.p7s
Description: S/MIME cryptographic signature
___
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] New code name for networks

[Thierry Carrez]

Anne Gentle wrote:
> > I told Monty and the TC this at the Summit (sorry I couldn't attend the
> > session about code names).
> 
> I promise, it wasn't the world's most fun session. :)
> 
> I'm sure. :) I think I don't have much regret but do feel sorry that I
> don't know more. 

The Etherpad is here:
https://etherpad.openstack.org/ProjectsReNaming

I think there is much more value to codenames than just "avoiding the
cost of a rename when the project becomes OpenStack". This was captured
in the session:

Codenames drawbacks and benefits
(-) Lack of trademark protection
(-) Confusing to newcomers
(-) Shadow their more official counterparts
(+) Short names are highly-convenient and efficient, often less
ambiguous (in conversations, executables,  modules...)
(+) Help building project and team identity
(+) Separate the project itself from its functional scope (so they
remain valid even if that scope evolves)

Those last two bits are pretty essential. There is a reason why a
functional description cannot be used as a project name. The project (as
in, the code repository and the community of contributors around it) is
*distinct* from the functional scope of what its code does.

Take Ceilometer ("OpenStack Metering"). What happens when they grow to
cover Monitoring ? You rename the project to "OpenStack Metering and
Monitoring" ? Or you keep the partial functional description ? I'd
rather avoid to rename everything every time a project evolves. Those
renames are *extremely* costly, as we'll soon enough realize.

I find the "confusing" argument pretty weak myself. Brands are used
everywhere, so we are used to make the translation between a name and a
function. Microsoft named its desktop environment "Windows", rather than
"Operating system" or "Desktop environment", and it took people about 5
minutes to get used to it.

> Go with kumquat, but don't call the CLI kumquat. Call your team kumquat and 
> your repo kumquat. 

If you call the CLI "os-metering", you'll have to rename it when the
scope expands, or live with a name that looks like a functional
description but is not an accurate one. I very much prefer to call it
"ceilometer".

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

___
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] Safe to expose various ports to the public (5000, 8774, etc, and via NAT)?

[Michael S. Moody]

Something that doesn't seem to be well discussed is how safe Openstack
(and the corresponding services/API's) is to be exposed to the public.
For instance, how safe is it to expose port 5000 to the general
public? Port 8774?

Right now, the only thing we have exposed to the public is the Horizon
dashboard. Our controller current sits on a private LAN segment
(172.x.x.x). Anything that we do with the API, we utilize a VPN for
(for the moment).

So, how safe is it, and what can be safely exposed? We would like to
enable our users (even if it is closely controlled via hardware
firewall rules) to utilize the various API's.

On an alternate topic, since we utilizing hardware firewalls, and
thus, NAT, when we attempt to connect the the PUBLIC IP address (API,
say 5000), our connection stalls attempting to make a connection to
private_ip:8774. We assume this is what the public_endpoint directive
in keystone.conf is for?

(If it matters, we are running the Essex release on Ubuntu 12.04).

Michael

___
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 questions - container sync

[Mark Brown]

Has anyone used container sync in their implementations? It would be great to 
know your experiences, because real world use case studies are scarce:) 
Anything to be aware of, whether its performance, setup, problems seen, 
recommendations..?

--Mark


 From: Mark Brown 
To: David Hadas  
Cc: "openstack@lists.launchpad.net"  
Sent: Sunday, May 12, 2013 11:25 PM
Subject: Re: [Openstack] Swift questions.
 


Thanks again, David. Definitely helps.

Is the alternative node you refer to here the "handoff" node? Is the handoff 
node something that is in the ring database? I am trying to piece together 
where in the stack this would happen. If it is transparent, it would probably 
happen in the object server somehow, but it would need to know where the 
handoff node is.

-- Mark.



 From: David Hadas 
To: Mark Brown  
Cc: "openstack@lists.launchpad.net"  
Sent: Sunday, May 12, 2013 11:13 PM
Subject: Re: [Openstack] Swift questions.
 


Mark, 

It would mark the server as having insufficient storage (to avoid retrying the 
same server for a while) and try to place the object in an alternative node -  
same as it would do with any other error. Once the object is placed in an 
alternative node, the alternative node would try to send the object back to its 
originated place every once in a while such that if the problem is reolved, it 
will move to the right place. 

This being said, there are N replicas - and this would repeat for each of the N 
replicas. So if one server is full you can still access the data using the 
other N-1 replicas and you still maintain N replicas in your system of the 
object (although one of them is misplaced until the administrator would
 resolve the space issue). 

Swift doe snot use df, it would try to allocate the space on the disk and if it 
fails it fails.
Failure is just a natural part of live as far as swift is concerned ;)

Hope this helps. 

DH



Regards, 
David Hadas
Research Staff Member, Master Inventor

IBM Research Labs, Haifa
Tel:Int+972-4-829-6104
Fax:   Int+972-4-829-6112

-Mark Brown  wrote: -
To: David Hadas/Haifa/IBM@IBMIL
From: Mark Brown 
Date: 05/12/2013 08:27PM
Cc: "openstack@lists.launchpad.net" 
Subject: Re: [Openstack] Swift questions.


Thanks for the response David.

I do understand Swift, by its design, tries to keep things in balance among 
various nodes. I was curious what it does when it encounters a full 
partition(say hard disk is full)? Lets just say it is balanced and the all 
nodes are nearing capacity. If I dont add any nodes, what happens when it tries 
to write on a specific node (which it was directed to based on the hashing 
ring) and there is not enough space to write the object?

Also, what does it use to determine a full partition? Does it use a df? 

Mark



 From: David Hadas 
To: Mark Brown  
Cc: "openstack@lists.launchpad.net"  
Sent: Sunday, May 12, 2013 10:36 PM
Subject: Re: [Openstack] Swift questions.
 


Mark, 

Regarding your first Q:

Swift evenly balance the hard-drives such that in a correctly configured 
system, you should expect one hard-drive being more full than the other. 
There is manual a mechanism in swift to balance hard-drives by moving partitions
 to/from hard-drive but you should need to use it under normal conditions, it 
is likely that if your had-drives get full the right thing to do would be to 
add more hard-drives.

In any case you should care not about individual partitions 'getting full' as 
partitions are not allocated any specific space and can grow and shrink as 
needed as long as the hard-drive they are in have space.


DH



Regards, 
David Hadas
Research Staff Member, Master Inventor

IBM Research Labs, Haifa
Tel:Int+972-4-829-6104
Fax:   Int+972-4-829-6112

-"Openstack"  
wrote: -
To: "openstack@lists.launchpad.net" 
From: Mark Brown 
Sent by: "Openstack" 
Date:
 05/12/2013 07:50PM
Subject: [Openstack] Swift questions.


Hello guys,
Been looking at Swift for some projects, and had some very basic questions.

1. How does Swift determine a certain partition is full? And when it does 
detect that, what does it do? Does it return an error to the client?

2. Regarding container sync, has anyone used container sync in their 
implementations? It would be great to know your experiences, because real world 
use case studies are scarce:)


-- Mark

___
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___
Mailing list: https://launch