[Openstack] [Neutron][Horizon]Create Instance With a Subnet
Hi, All I am new for openstack and focusing on networking. When I create a instance from dashboard, I can only chose a network for my instance. But in my opinion, the instance should belong to one given subnet but not a network. Then I read the nova manual. I found that a instance can boot with a fixed-ip from a nic. So , when my private network has two subnets(subnet1 10.0.0.0/24 and subnet2 10.0.1.0/24), the instance launched from dashboard was allocated to the isubnet1 by default. How can I launch a instance and allocatedit to a subnet I chosen? Should I allocate a fixed ip to the instance instead of dhcp? By the way, when I transfer a instance form subnet1 to subnet2, what can I do in dashboard? The test environment is devstack juno in ubuntu 14.04. Appreciate your help in advance. Thanks, Wilence ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Heat "Unknown property floating_network" Error
On Tue, Jan 13, 2015 at 11:11:09AM -0800, Richard Raseley wrote: > This is RDO Icehouse-4 on CentOS 7 > > I am attempting to deploy a very basic stack using a slightly modified > version of a template found in openstack/heat-templates on GitHub[1]. > > However, both this base template and my modified vesion fail 'heat > template-validate'. Adding the debug flag revealed an inner exception > of 'heatclient.exc. > HTTPBadRequest: ERROR: Unknown Property > floating_network'.[2] > > According to the documentation[3], 'floating_network' is a valid > property for 'OS::Neutron::FloatingIP'. > > Can anyone provide some insight as to why this might be occurring? This is a documentation issue - "floating_network" was only added in Juno Heat, so you'll have to use "floating_network_id" on Icehouse. I'll look at posting a patch which clarifies that in our documentation, thanks for pointing it out. The main difference between these properties is that floating_network can accept a name or ID, and we'll resolve the ID lookup, whereas if you're using Icehouse you'll always have to pass the network UUID to floating_network_id (this should just work if you're referring to another resource inside a template rather than passing in a parameter). Steve ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Auto sizing filesystem using cloud-init is not always working
hi i am using cloud-init on Centos6.6 instances. Issue is instance's disk size is increasing but partition size not expanding according to flavor size i have growpart installed. growpart /dev/vda 1 shows following error NOCHANGE: partition 1 is 83883776.It can not be grown. But if i resize its working but not completely. Actual qcow2 disk is 2G size and allocated is ~1G. Strange Behaviour: With flavor disk size of 20G,fdisk shows disk size of 20G, but partition is still 2G. If resized to different flavor with disk size of 40G,fdisk shows 40G and partition is 20G!! if resized to larger flavor with disk size 80G,fdisk shows 80G and partition is 40G !! So the issue from first flavor continues,if start with 40G disk then difference will always be 40G Why is cloud-init behaving like this ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Auto sizing filesystem using cloud-init is not always working
i have cloud-utils.x86_64 cloud-init.x86_64 cloud-utils-growpart.x86_64 installed i think the other is for debian distros as i can not find in yum repos.I am using centos6.6. One strange thing is if i restart instance after creating,its working,But not during the first boot. On Thu, Jan 15, 2015 at 3:24 PM, gustavo panizzo (gfa) wrote: > do you have installed dracut-module-growpart in the image? > have you rebuild the initramfs after installing it? > > On January 15, 2015 5:32:54 PM GMT+08:00, mad Engineer > wrote: >>hi i am using cloud-init on Centos6.6 instances. >>Issue is instance's disk size is increasing but partition size not >>expanding according to flavor size >> >>i have growpart installed. >> >>growpart /dev/vda 1 shows following error >>NOCHANGE: partition 1 is 83883776.It can not be grown. >> >>But if i resize its working but not completely. >> >>Actual qcow2 disk is 2G size and allocated is ~1G. >> >>Strange Behaviour: >>With flavor disk size of 20G,fdisk shows disk size of 20G, but >>partition is still 2G. >>If resized to different flavor with disk size of 40G,fdisk shows 40G >>and partition is 20G!! >>if resized to larger flavor with disk size 80G,fdisk shows 80G and >>partition is 40G !! >> >>So the issue from first flavor continues,if start with 40G disk then >>difference will always be 40G >> >>Why is cloud-init behaving like this >> >>___ >>Mailing list: >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>Post to : openstack@lists.openstack.org >>Unsubscribe : >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > -- > 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 > > Sent from mobile. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Auto sizing filesystem using cloud-init is not always working
On 01/15/2015 06:28 PM, mad Engineer wrote: i have cloud-utils.x86_64 cloud-init.x86_64 cloud-utils-growpart.x86_64 installed i think the other is for debian distros as i can not find in yum repos.I am using centos6.6. One strange thing is if i restart instance after creating,its working,But not during the first boot. yeah, you need dracut-modules-growroot it comes from epel repo after install (in your golde image), rebuild your /boot/initramfs mkinitrd is your friend ,not as good friend as update-initramfs but still a friend. the old kernel that comes with centos 6 is to blame -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] MagnetoDB kilo-1 milestone release
Hello OpenStack users, MagnetoDB, key-value store for OpenStack, kilo-1 milestone has been released [1] This milestone we focused on operability and monitoring aspects of MagnetoDB. * Backup/Restore API has been introduced * Monitoring API has been introduced and implemented for Cassandra * The API URI format has been changed to split logically different functionality and simplify deployment * Updated documentation [2] The bunch of bags have been fixed [1]. With best regards, Ilya Sviridov [1] https://launchpad.net/magnetodb/kilo/kilo-1 [2] https://magnetodb.readthedocs.org/en/2015.1.0b1/ signature.asc Description: OpenPGP digital signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Auto sizing filesystem using cloud-init is not always working
On 01/15/2015 07:05 PM, mad Engineer wrote: Thanks gustavo, i have epel configured,through which i installed cloud-utils and utils-growpart but not able to find "dracut-modules-growroot " is it part of some other rpm? no $ yum info dracut-modules-growroot Installed Packages Name: dracut-modules-growroot Arch: noarch Version : 0.20 Release : 2.el6 Size: 43 k Repo: installed From repo : epel Summary : Automatically resize the root partition on first boot URL : https://launchpad.net/ubuntu/saucy/+source/cloud-initramfs-tools/0.20ubuntu1/+files/cloud-initramfs-tools_0.20ubuntu1.tar.gz License : GPLv3 Description : This dracut module will re-write the partition table of a disk so that the : root partition has as much space as possible, bumping it up to the edge of the : disk, or the edge of the next partition. sorry i can't help you more, i'm not a rpm guy but i assure you that's what you need On Thu, Jan 15, 2015 at 4:04 PM, gustavo panizzo (gfa) wrote: On 01/15/2015 06:28 PM, mad Engineer wrote: i have cloud-utils.x86_64 cloud-init.x86_64 cloud-utils-growpart.x86_64 installed i think the other is for debian distros as i can not find in yum repos.I am using centos6.6. One strange thing is if i restart instance after creating,its working,But not during the first boot. yeah, you need dracut-modules-growroot it comes from epel repo after install (in your golde image), rebuild your /boot/initramfs mkinitrd is your friend ,not as good friend as update-initramfs but still a friend. the old kernel that comes with centos 6 is to blame -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Auto sizing filesystem using cloud-init is not always working
Thanks gustavo, i have epel configured,through which i installed cloud-utils and utils-growpart but not able to find "dracut-modules-growroot " is it part of some other rpm? On Thu, Jan 15, 2015 at 4:04 PM, gustavo panizzo (gfa) wrote: > > > On 01/15/2015 06:28 PM, mad Engineer wrote: >> >> i have >> cloud-utils.x86_64 >> cloud-init.x86_64 >> cloud-utils-growpart.x86_64 installed >> i think the other is for debian distros as i can not find in yum >> repos.I am using centos6.6. >> >> One strange thing is if i restart instance after creating,its >> working,But not during the first boot. > > yeah, you need dracut-modules-growroot > > it comes from epel repo > > > after install (in your golde image), rebuild your /boot/initramfs mkinitrd > is your friend ,not as good friend as update-initramfs but still a friend. > > > the old kernel that comes with centos 6 is to blame > > > -- > 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] Openstack Havana installation using devstack
I'm also facing the same trouble. On Jan 15, 2015 12:05 PM, "masoom alam" wrote: > No > > I want Havana purposefully. > > Thanks > > On Thu, Jan 15, 2015 at 10:45 AM, iKhan wrote: > >> Go with stable/icehouse then. >> >> On Thu Jan 15 2015 at 11:13:37 AM masoom alam >> wrote: >> >>> Hi every one, >>> >>> How can I install Openstack Havana using devstack. >>> >>> The problem is that Havana branch does not exist on Github. >>> >>> git clone https://github.com/openstack-dev/devstack.git -b stable/havana >>> >>> Please guide. >>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >>> unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Auto sizing filesystem using cloud-init is not always working
Thanks gustavo,its working now :) On Thu, Jan 15, 2015 at 4:38 PM, gustavo panizzo (gfa) wrote: > > > On 01/15/2015 07:05 PM, mad Engineer wrote: >> >> Thanks gustavo, >> i have epel configured,through which i >> installed cloud-utils and utils-growpart but not able to find >> "dracut-modules-growroot " is it part of some other rpm? > > no > > $ yum info dracut-modules-growroot > > Installed Packages > Name: dracut-modules-growroot > Arch: noarch > Version : 0.20 > Release : 2.el6 > Size: 43 k > Repo: installed > From repo : epel > Summary : Automatically resize the root partition on first boot > URL : > https://launchpad.net/ubuntu/saucy/+source/cloud-initramfs-tools/0.20ubuntu1/+files/cloud-initramfs-tools_0.20ubuntu1.tar.gz > License : GPLv3 > Description : This dracut module will re-write the partition table of a disk > so that the > : root partition has as much space as possible, bumping it up to > the edge of the > : disk, or the edge of the next partition. > > sorry i can't help you more, i'm not a rpm guy but i assure you that's what > you need > > >> >> On Thu, Jan 15, 2015 at 4:04 PM, gustavo panizzo (gfa) >> wrote: >>> >>> >>> >>> On 01/15/2015 06:28 PM, mad Engineer wrote: i have cloud-utils.x86_64 cloud-init.x86_64 cloud-utils-growpart.x86_64 installed i think the other is for debian distros as i can not find in yum repos.I am using centos6.6. One strange thing is if i restart instance after creating,its working,But not during the first boot. >>> >>> >>> yeah, you need dracut-modules-growroot >>> >>> it comes from epel repo >>> >>> >>> after install (in your golde image), rebuild your /boot/initramfs >>> mkinitrd >>> is your friend ,not as good friend as update-initramfs but still a >>> friend. >>> >>> >>> the old kernel that comes with centos 6 is to blame >>> >>> >>> -- >>> 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 > > > -- > 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] VPN setup with central external router
Hi All, I am running a Juno OpenStack installation with neutron networking and many tenants. To preserve IPs in the floating IP range I have only one external router owned by admin and each tenant has a subnet that is attached to this router. Running instances with floating IPs works fine but I have run into some bugs before due to this particular deployment. When a user without admin role wants to do a 'neutron vpn-service-create' this fails with an error message like this: Unable to find router with name '' The reason for the error is obviously that the router is owned by admin. I have tried to set up a VPN for each tenant as admin using '--tenant-id' but that confuses Horizon and users get the dreaded 'Something went wrong!' when they go on the 'VPN' tab. This method hits either a bug in Horizon or is not the right way to go. My next approach would be to alter /etc/neutron/policy.json but I'm sort of lost there. Does anybody know what rules need to be added/changed in policy.json to get this working without opening security holes? Did anybody here get this to work in a similar setup? Thanks, Stefan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Ip not assigned to instance in kilo devstack
Hi, i deployed kilo devstack in ubuntu 14.04 server VM. I have one network interface but when i am creating a instance in kilo devstack,ip is not assigned to instance My local.conf for creating kilo devstack is http://paste.openstack.org/show/158107/ I also tried this local.conf http://paste.openstack.org/show/158118/ But none is assigning ip to created instance in kilo devstack any idea,any one please Regards Nikesh ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Juno (Ubuntu) Flat Network
Hi Ross, > * can I share the br-ex interface or do I need to use a separate physical > interface on the network node? Neutron complains loudly when I try to do > this, so I suspect the answer is an emphatic NO. If you already have a flat network associated with a provider bridge, you will be unable to associate another to that bridge. You would need a separate bridge configured on the host, along with a corresponding label in the Neutron config, before you could create this second flat network. > * is a GRE tunnel still used for a simple flat network between the compute > nodes and the network node? You can still leverage GRE for tenant networks, connect them to a router, and have the external router interface connected to the new flat network (as long as external=true). This works in Icehouse and beyond. > when I bring up a separate external interface (call this br-ex2) and try to > create the simple flat network using this physical interface, then when I try > to boot an instance it fails with a “No available host” found”, with errors > also in the nova-conductor log regarding vif interface mapping problems. If you are attempting to connect instances directly to this flat network, rather than a GRE network, you would need to create the bridge on every compute node. The bridge label must be consistent among the hosts, but the bridge interface mapped to the label can vary. You can get creative with how these flat bridges are created. Typically, one might expect a bridge to contain a physical interface (ie. eth2) and allow Neutron to tag traffic (vlan) or not tag traffic (flat). The latter requires the use of a native vlan on the trunk. I have seen folks create multiple bridges and add host-level vlan interfaces to them so that they could create multiple “flat” networks in Neutron. To me, this defeats the purpose of having Neutron manage tagging and I don’t recommend it. Let me know if this didn’t address your questions. James > On Jan 13, 2015, at 8:14 PM, Ross Lillie > wrote: > > All, > > I’ve just upgraded our cloud from Havana to Juno. > > I’ve succeeded in configuring Neutron with a flat, external network and > individual tenants can attach to it via a virtual router and floating > address, using GRE tunnels. However, I also need to configure a simple flat > network for a given tenant that maps directly to our campus network (i.e. > WAN). > > I’m having problems getting this configured correctly. Neutron is configured > entirely on its own node, with multiple interfaces: eth0 is attached to our > campus network and serves as the management interface, br-ex (eth2) is > attached to our campus backbone and is used to create the “external" flat > network, br-data (eth1) is attached to the cloud’s data network. Compute > nodes are configured with a single interface br-data (eth0). > > Now to create a simple flat network: > > * can I share the br-ex interface or do I need to use a separate physical > interface on the network node? Neutron complains loudly when I try to do > this, so I suspect the answer is an emphatic NO. > * when I bring up a separate external interface (call this br-ex2) and try > to create the simple flat network using this physical interface, then when I > try to boot an instance it fails with a “No available host” found”, with > errors also in the nova-conductor log regarding vif interface mapping > problems. > > I had this working in Havana using VLAN networks, but can’t seem to get > things working with GRE tunnels. > > Any tips/pointers would be appreciated > — > Ross Lillie, Motorola Solutions > CTO, SST, Applications & Services Research > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [OSSA 2015-002] Glance v2 API unrestricted path traversal through filesystem:// scheme
= OSSA-2015-002: Glance v2 API unrestricted path traversal through filesystem:// scheme = :Date: January 15, 2015 :CVE: Requested Affects ~~~ - Glance: up to 2014.1.3 and 2014.2 versions up to 2014.2.1 Description ~~~ Jin Liu from EMC reported that path traversal vulnerabilities in Glance were not fully patched in OSSA 2014-041. By setting a malicious image location to a filesystem:// scheme an authenticated user can still download or delete any file on the Glance server for which the Glance process user has access to. Only setups using the Glance V2 API are affected by this flaw. Patches ~~~ - https://review.openstack.org/145974 (Icehouse) - https://review.openstack.org/145916 (Juno) - https://review.openstack.org/145640 (Kilo) Credits ~~~ - Jin Liu from EMC References ~~ - https://launchpad.net/bugs/1408663 Notes ~ - This fix was included in the kilo-1 development milestone and will be included in future 2014.2.2 (juno) and 2014.1.4 (icehouse) releases. - The OpenStack VMT recommends revoking all credentials stored in files accessible by Glance as a precautionary measure. - A CVE has been requested for this issue, the OpenStack VMT will issue an errata with the correct CVE number assigned once this information is available. -- Tristan Cacqueray OpenStack Vulnerability Management Team signature.asc Description: OpenPGP digital signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] OverflowError: cannot convert float infinity to integer
On 15/01/15 03:43, mad Engineer wrote: > Hello All, > Dashboard was working fine ,strangely after a failed > instance resize and removing that instance,(instance-resize directory > was till there) dashboard is returning http error code 500. > > error log shows: OverflowError: cannot convert float infinity to integer > > using icehouse on centos6.6. This looks like [1] or [2], which do have fixes backported to Icehouse although not released yet. You should be able to resolve things by manually fixing in the database whichever quota value accidentally went below 0 for a given "in use" resource (the CLI nova/cinder absolute-limits calls should give an idea which value is causing the issue). Cheers, Julie [1] https://bugs.launchpad.net/horizon/+bug/1370869 [2] https://bugs.launchpad.net/horizon/+bug/1386687 > [Thu Jan 15 03:41:34 2015] [error] Internal Server Error: /dashboard/project/ > [Thu Jan 15 03:41:34 2015] [error] Traceback (most recent call last): > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/core/handlers/base.py", line > 134, in get_response > [Thu Jan 15 03:41:34 2015] [error] response = response.render() > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/response.py", line > 104, in render > [Thu Jan 15 03:41:34 2015] [error] > self._set_content(self.rendered_content) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/response.py", line > 81, in rendered_content > [Thu Jan 15 03:41:34 2015] [error] content = template.render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 140, > in render > [Thu Jan 15 03:41:34 2015] [error] return self._render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 134, > in _render > [Thu Jan 15 03:41:34 2015] [error] return self.nodelist.render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 823, > in render > [Thu Jan 15 03:41:34 2015] [error] bit = self.render_node(node, context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 837, > in render_node > [Thu Jan 15 03:41:34 2015] [error] return node.render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/loader_tags.py", > line 123, in render > [Thu Jan 15 03:41:34 2015] [error] return compiled_parent._render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 134, > in _render > [Thu Jan 15 03:41:34 2015] [error] return self.nodelist.render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 823, > in render > [Thu Jan 15 03:41:34 2015] [error] bit = self.render_node(node, context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 837, > in render_node > [Thu Jan 15 03:41:34 2015] [error] return node.render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/loader_tags.py", > line 62, in render > [Thu Jan 15 03:41:34 2015] [error] result = block.nodelist.render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 823, > in render > [Thu Jan 15 03:41:34 2015] [error] bit = self.render_node(node, context) > [Thu Jan 15 03:41:34 2015] [error] return node.render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/loader_tags.py", > line 123, in render > [Thu Jan 15 03:41:34 2015] [error] return compiled_parent._render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 134, > in _render > [Thu Jan 15 03:41:34 2015] [error] return self.nodelist.render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 823, > in render > [Thu Jan 15 03:41:34 2015] [error] bit = self.render_node(node, context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 837, > in render_node > [Thu Jan 15 03:41:34 2015] [error] return node.render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/loader_tags.py", > line 62, in render > [Thu Jan 15 03:41:34 2015] [error] result = block.nodelist.render(context) > [Thu Jan 15 03:41:34 2015] [error] File > "/usr/lib/python2.6/site-packages/django/template/base.py", line 823, > in render > [Thu Jan 15 03:41:34 2015] [error] bit = self.rende
Re: [Openstack] Heat "Unknown property floating_network" Error
On Thu, Jan 15, 2015 at 12:45 AM, Steven Hardy wrote: > > This is a documentation issue - "floating_network" was only added in Juno > Heat, so you'll have to use "floating_network_id" on Icehouse. > > I'll look at posting a patch which clarifies that in our documentation, > thanks for pointing it out. > > The main difference between these properties is that floating_network can > accept a name or ID, and we'll resolve the ID lookup, whereas if you're > using Icehouse you'll always have to pass the network UUID to > floating_network_id (this should just work if you're referring to another > resource inside a template rather than passing in a parameter). > > Steve Steve, Thank you for providing some clarity on this issue. Does this indicate that 'floating_network_id' is deprecated in Juno? Additionally, if you're able, would you provide some additional context around how the HOT version scheme works? I think this might've led to some of my confusion. Regards, Richard ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Heat "Unknown property floating_network" Error
On Thu, Jan 15, 2015 at 09:39:46AM -0800, Richard Raseley wrote: > On Thu, Jan 15, 2015 at 12:45 AM, Steven Hardy wrote: > > > > This is a documentation issue - "floating_network" was only added in Juno > > Heat, so you'll have to use "floating_network_id" on Icehouse. > > > > I'll look at posting a patch which clarifies that in our documentation, > > thanks for pointing it out. > > > > The main difference between these properties is that floating_network can > > accept a name or ID, and we'll resolve the ID lookup, whereas if you're > > using Icehouse you'll always have to pass the network UUID to > > floating_network_id (this should just work if you're referring to another > > resource inside a template rather than passing in a parameter). > > > > Steve > > Steve, > > Thank you for providing some clarity on this issue. > > Does this indicate that 'floating_network_id' is deprecated in Juno? > Additionally, if you're able, would you provide some additional > context around how the HOT version scheme works? I think this might've > led to some of my confusion. Yes, as already mentioned in the documentation floating_network_id is deprecated as of Juno, as are all other *_id Neutron resource properties related to networks and subnets, ref this change: https://review.openstack.org/#/c/82853/ https://bugs.launchpad.net/heat/+bug/1286128 So template authors are encouraged to s/network_id/network and s/subnet_id/subnet when migrating to Juno and beyond (the new properties should accept both ID's and names transparently). As promised, I proposed some changes to Heat which should help clarify the version new properties were added: https://review.openstack.org/#/c/147468/ https://review.openstack.org/#/c/147434/ After they both land, you should see, for example, that floating_network is only supported since Juno. The HOT version scheme is independent of the resource interfaces at present, that is only changed when changes are made to the DSL syntax or intrinsic functions. Hope that helps, Steve ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Ceph backed Nova live-migration
On 14/01/15 23:35, Yagmur Akbulut wrote: > Thanks for the reply. We are running Icehouse. > Is there a back port for this? There is in RHOSP5 and maybe other productized versions. I don't know of a publicly available backport. Pádraig. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Fwd: How to reset neutron (to clear leftovers from incorrect configuration)
Bump Noone to comment on this approach? Am I missing something or is this the proper way to reset Neutron? Regards, Uwe Weitergeleitete Nachricht Betreff: How to reset neutron (to clear leftovers from incorrect configuration) Datum: Tue, 13 Jan 2015 15:00:01 +0100 Von: Uwe Sauter Antwort an: uwe.sauter...@gmail.com An: openstack@lists.openstack.org Hi all, I'd like to get your comments on how to correctly clean a defective neutron configuration so I can start over with a new config. I'm currently running on CentOS 7 but try to keep it as generic as possible (but the distro affects the service and package names…) Compute hosts 1) stop service: # systemctl stop neutron-openvswitch-agent.service 2) remove Openvswtch bridges: # ovs-vsctl del-br br-tun # ovs-vsctl del-br br-int 3) stop services: # systemctl stop openvswitch.service # systemctl stop openvswitch-nonetwork.service 4) remove Openvswitch persistent configuration # rm -rf /etc/openvswitch/* /etc/openvswitch/.* 5) remove Openvswitch Kernel module # rmmod openvswitch 6) optionally: reset configuration files: # rm -rf /etc/neutron/* # yum reinstall openstack-neutron openstack-neutron-ml2 openstack-neutron-openvswitch (or whatever plugins were installed additionally) # Network host 1) stop services: # systemctl stop neutron-l3-agent.service # systemctl stop neutron-dhcp-agent.service # systemctl stop neutron-metadata-agent.service # systemctl stop neutron-openvswitch-agent.service # systemctl stop neutron-ovs-cleanup.service # systemctl stop neutron-openvswitch-agent.service 2) remove Openvswtch bridges: # ovs-vsctl del-br br-tun # ovs-vsctl del-br br-int # ovs-vsctl del-br br-ex 3) stop services: # systemctl stop openvswitch.service # systemctl stop openvswitch-nonetwork.service 4) remove Openvswitch persistent configuration # rm -rf /etc/openvswitch/* /etc/openvswitch/.* 5) remove Openvswitch Kernel module # rmmod openvswitch 6) optionally: reset configuration files: # rm -rf /etc/neutron/* # yum reinstall openstack-neutron openstack-neutron-ml2 openstack-neutron-openvswitch (or whatever plugins were installed additionally) # Neutron controller host 1) stop service: # systemctl stop neutron-server.service 2) clear neutron database (on database host): # mysql -u -p mysql> drop database neutron; mysql> create database neutron; 3) optionally: reset configuration files: # rm -rf /etc/neutron/* # yum reinstall openstack-neutron openstack-neutron-ml2 (or whatever plugins were installed additionally) # When come to that point, one can begin configuring Neutron again from a clean point. Don't forget to: 1) create a symlink on each host /etc/neutron/plugin.ini -> /etc/neutron/plugins/ml2/ml2_conf.ini 2) sync the database on the controller host 3) configure Neutron 4) restart services on all hosts Do I forget any step? Is there an easier way to get back the vanilla state? Best regards, Uwe ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] How to reset neutron (to clear leftovers from incorrect configuration)
Hi Uwe, What leads you to believe it’s defective? I think with the right output and config files we can figure out what’s missing. James > On Jan 15, 2015, at 3:14 PM, Uwe Sauter wrote: > > Bump > > Noone to comment on this approach? Am I missing something or is this the > proper way to reset Neutron? > > > Regards, > >Uwe > > > Weitergeleitete Nachricht > Betreff: How to reset neutron (to clear leftovers from incorrect > configuration) > Datum: Tue, 13 Jan 2015 15:00:01 +0100 > Von: Uwe Sauter > Antwort an: uwe.sauter...@gmail.com > An: openstack@lists.openstack.org > > Hi all, > > I'd like to get your comments on how to correctly clean a defective > neutron configuration so I can start over with a new config. > > I'm currently running on CentOS 7 but try to keep it as generic as > possible (but the distro affects the service and package names…) > > > Compute hosts > 1) stop service: > # systemctl stop neutron-openvswitch-agent.service > 2) remove Openvswtch bridges: > # ovs-vsctl del-br br-tun > # ovs-vsctl del-br br-int > 3) stop services: > # systemctl stop openvswitch.service > # systemctl stop openvswitch-nonetwork.service > 4) remove Openvswitch persistent configuration > # rm -rf /etc/openvswitch/* /etc/openvswitch/.* > 5) remove Openvswitch Kernel module > # rmmod openvswitch > 6) optionally: reset configuration files: > # rm -rf /etc/neutron/* > # yum reinstall openstack-neutron openstack-neutron-ml2 > openstack-neutron-openvswitch (or whatever plugins were installed > additionally) > # > > > Network host > 1) stop services: > # systemctl stop neutron-l3-agent.service > # systemctl stop neutron-dhcp-agent.service > # systemctl stop neutron-metadata-agent.service > # systemctl stop neutron-openvswitch-agent.service > # systemctl stop neutron-ovs-cleanup.service > # systemctl stop neutron-openvswitch-agent.service > 2) remove Openvswtch bridges: > # ovs-vsctl del-br br-tun > # ovs-vsctl del-br br-int > # ovs-vsctl del-br br-ex > 3) stop services: > # systemctl stop openvswitch.service > # systemctl stop openvswitch-nonetwork.service > 4) remove Openvswitch persistent configuration > # rm -rf /etc/openvswitch/* /etc/openvswitch/.* > 5) remove Openvswitch Kernel module > # rmmod openvswitch > 6) optionally: reset configuration files: > # rm -rf /etc/neutron/* > # yum reinstall openstack-neutron openstack-neutron-ml2 > openstack-neutron-openvswitch (or whatever plugins were installed > additionally) > # > > > Neutron controller host > 1) stop service: > # systemctl stop neutron-server.service > 2) clear neutron database (on database host): > # mysql -u -p > mysql> drop database neutron; > mysql> create database neutron; > 3) optionally: reset configuration files: > # rm -rf /etc/neutron/* > # yum reinstall openstack-neutron openstack-neutron-ml2 (or whatever > plugins were installed additionally) > # > > > When come to that point, one can begin configuring Neutron again from a > clean point. Don't forget to: > > 1) create a symlink on each host > /etc/neutron/plugin.ini -> /etc/neutron/plugins/ml2/ml2_conf.ini > 2) sync the database on the controller host > 3) configure Neutron > 4) restart services on all hosts > > > Do I forget any step? Is there an easier way to get back the vanilla state? > > > Best regards, > > Uwe > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Get tenant by name
I tried this approach with the following command line:
$ keystone --debug tenant-get '{name=Jet-Home}'
It didn't work; it seems that it doesn't work because it doesn't like
the proposed syntax:
DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
https://proxy.nebula-dev:8770/v2.0/tokens
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS
connection (1): proxy.nebula-dev
DEBUG:requests.packages.urllib3.connectionpool:"POST /v2.0/tokens
HTTP/1.1" 200 2966
Looks like it generated the right call:
DEBUG:keystoneclient.session:REQ: curl -i -X GET
https://proxy.nebula-dev:35357/v2.0/tenants/{name=Jet-Home} -H
"User-Agent: python-keystoneclient" -H "X-Auth-Token: TOKEN_REDACTED"
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS
connection (1): proxy.nebula-dev
DEBUG:requests.packages.urllib3.connectionpool:"GET
/v2.0/tenants/%7Bname=Jet-Home%7D HTTP/1.1" 404 101
But it didn't like that (404 not found):
DEBUG:keystoneclient.session:RESP:
DEBUG:keystoneclient.session:Request returned failure status: 404
This is where it falls back to fetching all tenants to search within the
list client-side:
DEBUG:keystoneclient.session:REQ: curl -i -X GET
https://proxy.nebula-dev:35357/v2.0/tenants -H "User-Agent:
python-keystoneclient" -H "X-Auth-Token: TOKEN_REDACTED"
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS
connection (1): proxy.nebula-dev
DEBUG:requests.packages.urllib3.connectionpool:"GET /v2.0/tenants
HTTP/1.1" 200 963
[...]
On 1/9/2015 *李旦* lidan17 at jd.com
wrote:
Maybe you need:
curl -i -X GEThttp://IPAddr:35357/v2.0/tenants?{name=
} -H "User-Agent: python-keystoneclient"
-H "X-Auth-Token: XX"
Hope this helps.
Best Regards,
Daniel
On 1/8/2015 5:42 PM, Peter Scott wrote:
Hello. The v2.0 API documentation at
http://developer.openstack.org/api-ref-identity-v2.html says that it
is possible to look up a tenant by name. It comes right after the
"list all tenants" call and looks the same, although if I understand
it correctly it takes a request body with a 'name' parameter.
However, I can't find any Python support for that lookup nor a curl
example. Can someone supply either a curl example or a python call
that looks up a tenant by name please?
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Get tenant by name
I spoke too fast. I looked at the API again and saw that it said
name... not Name. In fact, both of these work to return a single tenant
by name:
...tenants?{name=Jet-Home}
../tenants?name=Jet-Home
So, case-sensitive. I don't think there is a way to generate that URL
through the Python binding, though. I will see if I can create a patch.
On 1/15/2015 5:27 PM, Peter Scott wrote:
I wasn't reading the debug output closely enough and didn't see before
that my keystone command generates a URL of ...tenants/{Name=Jet-Home}
instead of the suggested one of ...tenants?{Name=Jet-Home}. I also
received a suggestion in direct email to try .../tenants?Name=Jet-Home.
I resorted to curl to try both of those, and each one returns the
entire list of tenants.
I also tried putting the name in a request body (I didn't think you
could send data in a GET request, but apparently you can, and it is
expecting and parsing JSON):
curl -i -X GET 'https://proxy.nebula-dev:35357/v2.0/tenants' -d
'{"Name":"Jet-Home"}' -H "User-Agent: python-keystoneclient" -H
"Content-type: application/json" -H "X-Auth-Token: REDACTED"
and that just returns the entire list of tenants also.
(If I don't set the Content-type, I get "Expecting to find
application/json in Content-Type header".)
This isn't exactly a deal breaker, but the API doc does say that a
lookup by name should work, and I'd like to know if there's a way to
do that or whether the doc or the implementation are in error.
On 1/15/2015 2:41 PM, Peter Scott wrote:
I tried this approach with the following command line:
$ keystone --debug tenant-get '{name=Jet-Home}'
It didn't work; it seems that it doesn't work because it doesn't like
the proposed syntax:
DEBUG:keystoneclient.auth.identity.v2:Making authentication request
to https://proxy.nebula-dev:8770/v2.0/tokens
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS
connection (1): proxy.nebula-dev
DEBUG:requests.packages.urllib3.connectionpool:"POST /v2.0/tokens
HTTP/1.1" 200 2966
Looks like it generated the right call:
DEBUG:keystoneclient.session:REQ: curl -i -X GET
https://proxy.nebula-dev:35357/v2.0/tenants/{name=Jet-Home} -H
"User-Agent: python-keystoneclient" -H "X-Auth-Token: TOKEN_REDACTED"
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS
connection (1): proxy.nebula-dev
DEBUG:requests.packages.urllib3.connectionpool:"GET
/v2.0/tenants/%7Bname=Jet-Home%7D HTTP/1.1" 404 101
But it didn't like that (404 not found):
DEBUG:keystoneclient.session:RESP:
DEBUG:keystoneclient.session:Request returned failure status: 404
This is where it falls back to fetching all tenants to search within
the list client-side:
DEBUG:keystoneclient.session:REQ: curl -i -X GET
https://proxy.nebula-dev:35357/v2.0/tenants -H "User-Agent:
python-keystoneclient" -H "X-Auth-Token: TOKEN_REDACTED"
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS
connection (1): proxy.nebula-dev
DEBUG:requests.packages.urllib3.connectionpool:"GET /v2.0/tenants
HTTP/1.1" 200 963
[...]
On 1/9/2015 *李旦* lidan17 at jd.com
wrote:
Maybe you need:
curl -i -X GEThttp://IPAddr:35357/v2.0/tenants?{name=
} -H "User-Agent: python-keystoneclient"
-H "X-Auth-Token: XX"
Hope this helps.
Best Regards,
Daniel
On 1/8/2015 5:42 PM, Peter Scott wrote:
Hello. The v2.0 API documentation at
http://developer.openstack.org/api-ref-identity-v2.html says that
it is possible to look up a tenant by name. It comes right after
the "list all tenants" call and looks the same, although if I
understand it correctly it takes a request body with a 'name'
parameter.
However, I can't find any Python support for that lookup nor a curl
example. Can someone supply either a curl example or a python call
that looks up a tenant by name please?
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Get tenant by name
I wasn't reading the debug output closely enough and didn't see before
that my keystone command generates a URL of ...tenants/{Name=Jet-Home}
instead of the suggested one of ...tenants?{Name=Jet-Home}. I also
received a suggestion in direct email to try .../tenants?Name=Jet-Home.
I resorted to curl to try both of those, and each one returns the entire
list of tenants.
I also tried putting the name in a request body (I didn't think you
could send data in a GET request, but apparently you can, and it is
expecting and parsing JSON):
curl -i -X GET 'https://proxy.nebula-dev:35357/v2.0/tenants' -d
'{"Name":"Jet-Home"}' -H "User-Agent: python-keystoneclient" -H
"Content-type: application/json" -H "X-Auth-Token: REDACTED"
and that just returns the entire list of tenants also.
(If I don't set the Content-type, I get "Expecting to find
application/json in Content-Type header".)
This isn't exactly a deal breaker, but the API doc does say that a
lookup by name should work, and I'd like to know if there's a way to do
that or whether the doc or the implementation are in error.
On 1/15/2015 2:41 PM, Peter Scott wrote:
I tried this approach with the following command line:
$ keystone --debug tenant-get '{name=Jet-Home}'
It didn't work; it seems that it doesn't work because it doesn't like
the proposed syntax:
DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
https://proxy.nebula-dev:8770/v2.0/tokens
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS
connection (1): proxy.nebula-dev
DEBUG:requests.packages.urllib3.connectionpool:"POST /v2.0/tokens
HTTP/1.1" 200 2966
Looks like it generated the right call:
DEBUG:keystoneclient.session:REQ: curl -i -X GET
https://proxy.nebula-dev:35357/v2.0/tenants/{name=Jet-Home} -H
"User-Agent: python-keystoneclient" -H "X-Auth-Token: TOKEN_REDACTED"
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS
connection (1): proxy.nebula-dev
DEBUG:requests.packages.urllib3.connectionpool:"GET
/v2.0/tenants/%7Bname=Jet-Home%7D HTTP/1.1" 404 101
But it didn't like that (404 not found):
DEBUG:keystoneclient.session:RESP:
DEBUG:keystoneclient.session:Request returned failure status: 404
This is where it falls back to fetching all tenants to search within
the list client-side:
DEBUG:keystoneclient.session:REQ: curl -i -X GET
https://proxy.nebula-dev:35357/v2.0/tenants -H "User-Agent:
python-keystoneclient" -H "X-Auth-Token: TOKEN_REDACTED"
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS
connection (1): proxy.nebula-dev
DEBUG:requests.packages.urllib3.connectionpool:"GET /v2.0/tenants
HTTP/1.1" 200 963
[...]
On 1/9/2015 *李旦* lidan17 at jd.com
wrote:
Maybe you need:
curl -i -X GEThttp://IPAddr:35357/v2.0/tenants?{name=
} -H "User-Agent: python-keystoneclient"
-H "X-Auth-Token: XX"
Hope this helps.
Best Regards,
Daniel
On 1/8/2015 5:42 PM, Peter Scott wrote:
Hello. The v2.0 API documentation at
http://developer.openstack.org/api-ref-identity-v2.html says that it
is possible to look up a tenant by name. It comes right after the
"list all tenants" call and looks the same, although if I understand
it correctly it takes a request body with a 'name' parameter.
However, I can't find any Python support for that lookup nor a curl
example. Can someone supply either a curl example or a python call
that looks up a tenant by name please?
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [Heat][Keystone]Heat deals with different version of keystone API
Hi, Can the keystone token, obtained from keystone API v2.0, be used in the openstack service/endpoint which are configured to use keystone API v3? There is an OpenStack cluster, where most of services(such as Heat, Nova, Ceilometer) are configured to use keystone API v2.0 but one of the services are using keystone API v3. Now I want to launch a heat template (The Heat service are using ks API v2.0) to access the service using keystone API v3. Error occurs and it says the token is not correct. So in this case, is there any way to let heat-engine to handle this conversion or I have to change the configuration to let all services in a OpenStack cluster are using only one version of keystone API (say v2.0)? Thanks in advance, Gary ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Neutron vs. FlatDHCP -- what's the latest?
You should be able to create a router under the same admin tenant as the external network and attach it to a shared network also owned by the admin tenant. Then other tenants would just attach their VMs to the shared network. Let me know if this doesn't work. On Tue, Dec 30, 2014 at 9:06 AM, Joe Topjian wrote: > Your suggested solution uses a single router where all floating IPs will > be attached. This will work fine for a single-tenant cloud, but this was > not possible to do in a multi-tenant cloud when I tested this a few weeks > back. > > Perhaps I did not create the router correctly? Is there some type of > "shared" metadata that the router needs created with? > > And just to add input / support to this use-case, a Neutron version of > nova-network's FlatDHCP is of great interest to me as well. The main reason > is due to the requirement of each tenant router requiring a public IP > address. In order for a tenant to get a floating IP on their instance, it > costs me one floating IP for their router. I do not like this Floating IP > Tax. :) > > > On Mon, Dec 29, 2014 at 2:26 AM, Kevin Benton wrote: > >> I think the setup would be the same as I suggested because it provides >> the same isolation properties if I understand the flat-with-floating >> topology correctly. >> >> I'm not sure what topologies will be supported in the current nova net >> migration plans, but it seems like it should be possible to have a >> automated transition for this one. >> >> >> >> On Mon, Dec 22, 2014 at 8:04 PM, Andrew Bogott >> wrote: >> > Kevin -- >> > >> > Thanks for your thoughts; this seems possible, if ugly. My original >> > question remains, though: If there is meant to be an upgrade path from >> > nova-network (In L, or M, or whenever), what will my use case look like >> > after migration? Will it be this same setup that you suggest, or is a >> > proper flat-with-floating setup being added to Neutron in order to >> allow for >> > direct migrations? >> > >> > Thanks. >> > >> > -Andrew >> > >> > >> > >> > On 12/22/14 5:42 PM, Kevin Benton wrote: >> >> >> >> The shared network would have all of the VMs attached to it and would >> >> just be private address space. The shared network would be connected >> >> to a virtual router which would be connected to an external network >> >> where all of your floating IPs come from. The floating IPs from there >> >> would have the allocation, assignment, release features you are >> >> looking for. >> >> >> >> However, until the ARP poisoning protection is merged, shared networks >> >> aren't very trustworthy across multiple tenants. So you should be able >> >> to experiment with the Juno Neutron code in the topology I described >> >> above to see if it meets your needs, but I wouldn't suggest a >> >> production deployment until the L2 dataplane security features are >> >> merged (hopefully during this cycle). >> >> >> >> >> >> - >> >> | Shared Network | <--- All tenant VMs attach here >> >> - >> >> | >> >> >> >> | Router | >> >> >> >> | >> >> -- >> >> | External Network |<--- Floating IPs come from here >> >> -- >> >> >> >> On Mon, Dec 22, 2014 at 1:46 AM, Andrew Bogott >> >> wrote: >> >>> >> >>> On 12/22/14 2:08 PM, Kevin Benton wrote: >> >>> >> >>> Can't you simulate the same topology as the FlatDHCPManager + Floating >> >>> IPs >> >>> with a shared network attached to a router which is then attached to >> an >> >>> external network? >> >>> >> >>> >> >>> Mmmmaybe? Floating IP support in nova-network is pretty great >> >>> (allocation, >> >>> assignment, release, etc.) and allows us shuffle around a small >> number of >> >>> public IPs amongst a much larger number of instances. Your suggestion >> >>> doesn't address that, does it? Short of my implementing a bunch of >> >>> custom >> >>> stuff on my own? >> >>> >> >>> -A >> >>> >> >>> >> >>> >> >>> >> >>> On Sun, Dec 21, 2014 at 7:00 PM, Andrew Bogott > > >> >>> wrote: >> >> Greetings! >> >> I'm about to set up a new cloud, so for the second time this year I'm >> facing the question of Neutron vs. nova-network. In our current >> setup >> we're >> using nova.network.manager.FlatDHCPManager with floating IPs. This >> config >> has been working fine, and would probably be our first choice for the >> new >> cloud as well. >> >> At this point is there any compelling reason for us to switch to >> Neutron? >> My understanding is that the Neutron flat network model still doesn't >> support anything similar to floating IPs, so if we move to Neutron >> we'll >> need to switch to a subnet-per-tenant model. Is that still correct? >> >> I'm puzzled by the statement that " upgrades without instance >> downtime >> will be available in the Kilo release"[1
