Re: [Openstack] Provider networks and manual ip management
On 02/08/2013 10:14 AM, tr...@cs.drexel.edu wrote:
Anyone?
I haven't tried this myself, but, before booting the instance, you
should be able create the port, passing the desired IP on the subnet as
fixed_ips. Then pass this port's ID to nova when you boot the instance.
You may also want to specify an empty allocation_pools value when
creating the subnet.
-Bob
Thanks,
-Trevor
Again, is there a better place to ask these types of questions?
I am trying to get a provider network working where I have full control of
the ip allocations. What I need is to be able to have 2 (or more public ip
addresses, or really to our private network). I know this can't be done
with floating ips, so that is why I am looking to patch it into my network
and just manually configure the ips. (probably also having a flat vm
network as well).
I've got a provider network configured as so, with no dhcp on the subnet:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| f1c2fb46-72a3-410c-b06a-518c56659d62 |
| name | provider |
| provider:network_type | flat |
| provider:physical_network | prinet |
| provider:segmentation_id | |
| router:external | True |
| shared| True |
| status| ACTIVE |
| subnets | c68bb08b-483f-49a5-be08-b690e84c4f17 |
| tenant_id | 35cd7af3118248bcb0ada0080afa3403 |
+---+--+
+--+--+
| Field| Value
|
+--+--+
| allocation_pools | {start: 192.168.224.2, end: 192.168.224.254}
|
| cidr | 192.168.224.0/24
|
| dns_nameservers |
|
| enable_dhcp | False
|
| gateway_ip | 192.168.224.1
|
| host_routes |
|
| id | c68bb08b-483f-49a5-be08-b690e84c4f17
|
| ip_version | 4
|
| name |
|
| network_id | f1c2fb46-72a3-410c-b06a-518c56659d62
|
| tenant_id| 35cd7af3118248bcb0ada0080afa3403
|
+--+--+
nova is assigning an ip to the port regardless of there being no dhcp and
therefore the port does not allow me to configure it. Using a different ip
results in the iptables rules rejecting the packets.
Anyone know how to fix this or get around this? Please?
-Trevor
___
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://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How to commucation vms in multi nodes using quantum?
On 10/24/2012 12:42 PM, Dan Wendlandt wrote: On Wed, Oct 24, 2012 at 3:22 AM, Gary Kotton gkot...@redhat.com wrote: Hi, In addition to Dan's comments you can also take a look at the following link http://wiki.openstack.org/ConfigureOpenvswitch. Is there any content on that wiki page that is not yet in the quantum admin guide: http://docs.openstack.org/trunk/openstack-network/admin/content/? If so, we should file a bug to make sure it ends up in the admin guide and that the wiki page is deleted so there is exactly one place where we direct people and we avoid stale content. Bob is probably best to answer that question. I've already filed a docs bug to update the admin guide with the current configuration details for linuxbridge and openvswitch, and its assigned to me. I hope to get to this in the next few days. I'll remove the wiki page, which is also out-if-date, when its complete. -Bob Dan Thanks Gary On 10/24/2012 08:21 AM, livemoon wrote: Thanks Dan On Wed, Oct 24, 2012 at 2:15 PM, Dan Wendlandt d...@nicira.com wrote: On Tue, Oct 23, 2012 at 10:56 PM, livemoon mwjpi...@gmail.com wrote: Dan: Thank you for your help. If the server have three nics, which one will be used as port of br-int. I must know how br-int work between two machines, and then I can make the physical interface which br-int use to one switch If you are using tunneling, the traffic will exit out the NIC based on your physical server's routing table and the destination IP of the tunnel. For example, if your physical server is tunneling a packet to a VM on a physical server with IP W.X.Y.Z, the packet will leave whatever NIC has the route to reach W.X.Y.Z . Dan On Wed, Oct 24, 2012 at 11:52 AM, Dan Wendlandt d...@nicira.com wrote: all you need to do is create a bridge named br-int, which is what the linux devices representing the vm nics will be plugged into. since you are using tunneling, there is no need to create a br-ethX and add a physical interface to it. dan p.s. btw, your config looks like its using database polling, which is not preferred. I'd suggest you use the default config, which uses RPC communication between agents and the main quantum-server process On Tue, Oct 23, 2012 at 8:44 PM, livemoon mwjpi...@gmail.com wrote: I know in one node,vm can work well. I want to know in multi nodes, do I need to create a br-ethX, and port the physical interface to it? how to do that in configuration? On Wed, Oct 24, 2012 at 11:36 AM, 刘家军 iam...@gmail.com wrote: you just need to create one or more networks and specify which network to use when booting vm. 2012/10/24 livemoon mwjpi...@gmail.com Hi, I use quantum as network. A question is if there are multi nodes, how to config to make vms communicate with each other in the same subnet. I use openvswitch as my plugin. And my setting is blow: [DATABASE] sql_connection = mysql://quantum:openstack@172.16.1.1:3306/quantum reconnect_interval = 2 [OVS] tenant_network_type = gre tunnel_id_ranges = 1:1000 integration_bridge = br-int tunnel_bridge = br-tun local_ip = 172.16.1.2 enable_tunneling = True [AGENT] polling_interval = 2 root_helper = sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf -- 非淡薄无以明志，非宁静无以致远 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- 刘家军@ljjjustin -- 非淡薄无以明志，非宁静无以致远 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ -- 非淡薄无以明志，非宁静无以致远 -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ -- Blog Site: livemoon.org Twitter: mwjpiero 非淡薄无以明志，非宁静无以致远 ___ 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://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum] Removing quantum-rootwrap
On 08/09/2012 10:32 AM, Thierry Carrez wrote: j...@redhat.com wrote: * Switch to rootwrap_config and deprecate root_helper This would fully align quantum-rootwrap with nova-rootwrap. However I'm not sure it's reasonable to deprecate root_helper=sudo in Folsom, given how little tested quantum-rootwrap seems to be on Folsom. Maybe just introducing rootwrap_config but leaving the deprecation message out ? You can have a look at: https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66 Ok. I did talk through this issue with Bob yesterday, but I'd be lying if I said I understood it all yet. Let me ask this: Since, as you say, there's not a lot of evidence of traffic through quantum-rootwrap, is there an obvious downside to deprecating root_helper=sudo at this stage? I'm not advocating either way, just trying to get up to speed on all the parts of the issue. Well, since there is not a lot of evidence of traffic through the rootwrap, that means almost everyone is using root_helper=sudo. Marking it deprecated, and recommending that everyone switches to the (untested yet) rootwrap doesn't sound that much like a great idea. I think we should deprecate root_helper=sudo when we are confident that most people are using rootwrap and are satisfied with it. By almost everyone and most people, do you mean users of devstack? I'd hate to think people are trying to deploy the quantum Folsom master branch with all the change that's been going on. We should immediately change devstack to stop running the quantum agents as root, so at least the root_helper=sudo functionality is really being used. It looks like devstack does configure nova with the new rootwrap/rootwrap_config and does not run any of its services as root. Doing the same for quantum would seem get some mileage on it. What exactly is involved in deprecating root_helper=sudo? Is this something we could chose whether or not to do at the last minute after implementing the new rootwrap and changing devstack to use it? Thanks, -Bob My goal is by end of today , or tomorrow morning latest, to have at least a reasonably complete understanding of the changes necessary to get the quantum-rootwrap facility up to parity with nova/cinder. If I get to that deadline and I'm not there, I'll probably punt, as it becomes too much of a hail-mary to get the stuff stabilized and reviewed etc by tues. That sounds reasonable. ___ 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] [Quantum] Removing quantum-rootwrap
On 08/08/2012 09:31 AM, Thierry Carrez wrote: Hi everyone, Quantum currently contains bin/quantum-rootwrap, a copy of nova-rootwrap supposed to control its privilege escalation to run commands as root. However quantum-rootwrap is currently non-functional, missing a lot of filter definitions that are necessary for it to work correctly. Is missing definitions the only issue? Those may need updating for F-3, but this can certainly be done. Quantum is generally run with root_helper=sudo and a wildcard sudoers file. What is your basis for this statement? The packaging of Essex Quantum for Fedora and RHEL/EPEL do configure root_helper to use quantum-rootwrap. If another distribution doesn't do this, I would consider that a distribution bug, not an upstream problem. That means Quantum is not ready to deprecate in Folsom (and remove in Grizzly) its ability to run with root_helper=sudo, like Nova and Cinder do. What's involved in deprecating this ability in Folsom? Is it that difficult? If Nova and Cinder are doing it, why shouldn't Quantum? I discussed this with Dan, and it appears that the sanest approach would be to remove quantum-rootwrap from Quantum and only support root_helper=sudo (the only option that works). I suspect nobody is actually using quantum-rootwrap right now anyway, given how broken it seems to be. For the first official release of Quantum as an OpenStack core project, I would prefer not to ship half-working options :) The quantum-rootwrap configuration in Essex is being used by anyone who uses the official Fedora or EPEL RPMs. It may not provide fine-grained validation of command parameters, but I haven't heard complaints that its broken. Isn't it better than nothing? Quantum would then wait for rootwrap to move to openstack-common (should be done in Grizzly) to reconsider using it. Let me know if any of you see issues with that approach. (posted to the general list to get the widest feedback). I do have an issue with Folsom dropping a capability that is being used in Essex. If the existing rootwrap really does more harm than good, this might be justified, but I don't think you can argue nobody has used it. -Bob ___ 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] [Netstack] question on get_network_details api call
On 06/02/2012 01:56 PM, Dan Wendlandt wrote: Hi Irena, Bob, Salvatore, Just catching up the thread, and looping the netstack and openstack lists in as well, as this info is general useful in my opinion. Our model with Quantum, like Nova, is that it is definitely ok to extend the content of a core object with additional attributes. These attributes should be formatted properly as extended attribute, so that the key of the attribute is extension-alias:attribute-name This is done pretty commonly within Nova. Two simple examples are: - nova/api/openstack/compute/contrib/scheduler_hints.py - nova/api/openstack/compute/contrib/extended_status.py I do not believe you need to (or should) modify the view-builder code for the core object when you want to add an extended attribute to it. Thanks Dan! I've now had some success implementing an extension that creates a RequestExtension that adds extended attributes to the response for a core resource. At least with JSON - I have not been able to figure out how to do this for XML, if that is even possible in quantum. Instead, the extension framework has you write a wsgi controller specific to the extension that is inserted as its own stage into the wsgi request and response processing pipeline. Thus, when the request is passed in, your code gets a chance to parse the data, and the the response is passed back, your code gets a chance to add data to it. The above description sounds more like a ResourceExtension than a RequestExtension. A ResourceExtension introduces a new Controller, whereas a RequestExtension just adds a handler function called by the core's RequestExtensionController. All examples and descriptions I've seen use ResourceExtension to introduce a new type of resource. Are you suggesting this mechanism can also be used to extend an existing core resource? Would this have any advantage over using a RequestExtension? I still don't see any way a ResourceExtension could add extended attributes into an XML response. Using the Nova code as example is probably the best bet if you can find a good example within quantum. Quantum's extension framework (and several other openstack projects) all use essentially the same model. The nova and quantum code seem to have diverged significantly. The nova examples use a nova.api.openstack.wsgi.extends decorator on methods of an extension-implemented Controller to do request extensions, but quantum doesn't have this decorator. Also, nova uses XML templates that are extensible, whereas the _serialization_metadata in quantum core resources does not seem to be extensible. At this point, quantum's RequestExtension mechanism seems able to do the job for the provider-networks BP, assuming that a JSON-only solution is acceptable. If both JSON and XML support are needed, then, unless I am missing something, creating a new (sub-)resource using a ResourceExtension (similar to the portstats extension) seems like the only straightforward option. -Bob Dan On Sat, Jun 2, 2012 at 8:43 AM, Robert Kukura rkuk...@redhat.com mailto:rkuk...@redhat.com wrote: On 06/02/2012 05:02 AM, Irena Berezovsky wrote: Hi, Bob, Dan, I ran into following wiki page: http://wiki.openstack.org/QuantumAPIExtensionsaction=AttachFiledo=viewtarget=quantum_api_extension.pdf http://wiki.openstack.org/QuantumAPIExtensionsaction=AttachFiledo=viewtarget=quantum_api_extension.pdf 'port profile' is exactly what I was looking for to expose in the plugin. I would like to add the port profile retrieval capability and contribute the implementation. Can you please advise if there is any disagreement on getting it into core API? Shall I do it via extension? Bob, seems that you are dealing with similar issues. What do you suggest? Thanks a lot, Irena Irena, I'm not sure there is any consensus around using a network profile for this. I did see that document as well as archived discussion about defining port profile and network profile as extensible collections of attributes. But the existing port profile extension looks to be Cisco-specific, and seems to serve a somewhat different purpose. My current thinking is that we'd be better off long term following the lead of Nova and other projects in supporting extension data within the existing resources instead of requiring introduction of a new resource just to hold plugin-specific attributes. But, in the short term, it might make the most sense for each extension just to provide its own resource extension with its attributes. That's what I'm tentatively planning to do for the provider-network blueprint, but would reconsider if there was consensus that either the extension data support or a more general network profile should be added now. -Bob
Re: [Openstack] [Netstack] About python versions that we are planning to support
[I'm moving this thread to the openstack list because it potentially impacts openstack-common.] On 05/07/2012 11:53 PM, Maru Newby wrote: Hi, Python 2.4 compatibility is required, but only for agent code. Agent code needs to be deployable on Xen dom0, which uses CentoOS 5.5 and only supports 2.4 out of the box. Maru, I'm very concerned about the potential of this XenServer/XCP requirement to interfere with making the various Quantum agents first-class OpenStack services by utilizing current and future openstack-common facilities for configuration, logging, DB, RPC, etc.. Are there any other possible ways forward here? How is the nova compute service currently handled for XenServer? Could a fully supported version of python be parallel-installed on dom0? Could the actual quantum agent run somewhere else and remotely execute commands on dom0? Or does the python 2.4 compatibility requirement need to be applied to openstack-common? Thanks, -Bob Both quantum and nova have agent code that needs to be deployed to dom0, but up until now both projects have relied on savvy reviewers and bug reports to ensure compatibility. I'm working on it, though. I'll be adding a tox build to quantum that will run agent tests - and agent tests only - under 2.4, and then openstack-ci can add a jenkins job to run that build on CentOS and gate merges. The relevant bug: https://bugs.launchpad.net/quantum/+bug/995278 Thanks, Maru On 2012-05-07, at 6:54 PM, Yong Sheng Gong wrote: Hi, I see some ones are trying to support python2.4. But our tox.ini under quantum is only supporting test py26 and py27. So my question is if we are trying to support py24. In addition I remember that we will support py30. As far as I know, py2.4 does not support many new syntaxes introduced by py2.5+. Other projects such as nova, horizon are also adopting some of these new syntaxes. Moreover some third party components such as Django 1.4 required by horizon are only tested under py2.6 and py2.7. So if py2.4 is out of our scope, we should stop that trying. If we need py2.4, we have to make all of us know it and keep our code 2.4 compatible. Thanks Yong Sheng Gong -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net mailto:netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack 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] [Netstack] Essex-3 Milestone of Quantum Available
On 02/02/2012 11:45 AM, Dan Wendlandt wrote: 2012/2/2 Doudedoudou...@gmail.com: Nice job netstackers. I've got a remark. I downloaded the Quantum archive from Quantum project Launchpad page and I untared it but I cannot find any OVS agent in the plugin directory. Does it mean it's packaged alone ? If yes, where I can find it ? Hi Doude, thanks for mentioning this. We switched over to using the standard openstack project tarball generation mechanism for E-3, but our team still ran tests still from git, and missed several issues like you one you mention. If possible, its probably best to just use the E-3 tarball from github itself: https://github.com/openstack/quantum/zipball/essex-3, which contains all of the correct files (I believe). Does that work for you? It should have all of the files you need. If needed, we could issue a Essex-3.1 drop with a fixed tarball. Dan and Doude, Bug https://bugs.launchpad.net/quantum/+bug/925074 covers the missing agent as well as missing LICENSE and plugin README files. From my point of view, issuing an E3.1 just for these is not warranted but I'd like to see them included in an E3.1 issued for other purposes, or else in E4. -Bob Dan Regards, Doude. On Fri, Jan 27, 2012 at 1:59 PM, Shake Chenshake.c...@gmail.com wrote: Hi Now the Qautum E3 whether work with Horizon E3? whether I can manage the Qauntum in Horizon Dashboard? On Fri, Jan 27, 2012 at 7:57 PM, Leandro Reoxleandro.r...@gmail.com wrote: Excellent job guys ! Well definitely try it next week, the last release worked out pretty good so far for us. Keep up the good work! Cheers Lean On Thu, Jan 26, 2012 at 8:36 PM, Dan Wendlandtd...@nicira.com wrote: Congrats to the Quantum team! The latest + greatest version of Quantum was release this morning, see: https://launchpad.net/quantum/essex/essex-3 I delayed the announce in order to complete updating the documentation, due to the fact that install procedures changed significantly with this release. See PDF on downloads page. Changes since Essex-2 include: - client code in separate repo to simplify development dependencies on other projects. - integration with Nova Floating IPs. - API filters for efficient queries and improved API error codes (API v1.1 only) - fixes to python setup tools scripts to make life easier for distros packagers. - port packet statistics extension If you have an OpenStack distro and are looking to package Quantum for Essex, the packaging should now be in its final form. Let us know how we can help. E-3 was also the first release for which Quantum was part of the standard OpenStack build process, thanks to the CI team for all the help! Since Quantum is still in incubation, E-4 is not a feature frozen milestone, though we will shutting the door to major merges at least a week before the official milestone branch point to avoid last-minute churn. Thanks to all who contributed to E-3. Looking forward to a great E-4 milestone with lots of early merge proposals :) Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ 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 -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.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: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack 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
