Re: [openstack-dev] Reg : Security groups implementation using openflows in quantum ovs plugin
And what do you think about the performance issue I talked ? Do you have any thought to improve wildcarding to use megaflow feature ? Édouard. On Fri, Nov 29, 2013 at 1:11 PM, Zang MingJie zealot0...@gmail.com wrote: On Fri, Nov 29, 2013 at 2:25 PM, Jian Wen jian@canonical.com wrote: I don't think we can implement a stateful firewall[1] now. I don't think we need a stateful firewall, a stateless one should work well. If the stateful conntrack is completed in the future, we can also take benefit from it. Once connection tracking capability[2] is added to the Linux OVS, we could start to implement the ovs-firewall-driver blueprint. [1] http://en.wikipedia.org/wiki/Stateful_firewall [2] http://wiki.xenproject.org/wiki/Xen_Development_Projects#Add_connection_tracking_capability_to_the_Linux_OVS On Tue, Nov 26, 2013 at 2:23 AM, Mike Wilson geekinu...@gmail.com wrote: Adding Jun to this thread since gmail is failing him. On Tue, Nov 19, 2013 at 10:44 AM, Amir Sadoughi amir.sadou...@rackspace.com wrote: Yes, my work has been on ML2 with neutron-openvswitch-agent. I’m interested to see what Jun Park has. I might have something ready before he is available again, but would like to collaborate regardless. Amir On Nov 19, 2013, at 3:31 AM, Kanthi P pavuluri.kan...@gmail.com wrote: Hi All, Thanks for the response! Amir,Mike: Is your implementation being done according to ML2 plugin Regards, Kanthi On Tue, Nov 19, 2013 at 1:43 AM, Mike Wilson geekinu...@gmail.com wrote: Hi Kanthi, Just to reiterate what Kyle said, we do have an internal implementation using flows that looks very similar to security groups. Jun Park was the guy that wrote this and is looking to get it upstreamed. I think he'll be back in the office late next week. I'll point him to this thread when he's back. -Mike On Mon, Nov 18, 2013 at 3:39 PM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Nov 18, 2013, at 4:26 PM, Kanthi P pavuluri.kan...@gmail.com wrote: Hi All, We are planning to implement quantum security groups using openflows for ovs plugin instead of iptables which is the case now. Doing so we can avoid the extra linux bridge which is connected between the vnet device and the ovs bridge, which is given as a work around since ovs bridge is not compatible with iptables. We are planning to create a blueprint and work on it. Could you please share your views on this Hi Kanthi: Overall, this idea is interesting and removing those extra bridges would certainly be nice. Some people at Bluehost gave a talk at the Summit [1] in which they explained they have done something similar, you may want to reach out to them since they have code for this internally already. The OVS plugin is in feature freeze during Icehouse, and will be deprecated in favor of ML2 [2] at the end of Icehouse. I would advise you to retarget your work at ML2 when running with the OVS agent instead. The Neutron team will not accept new features into the OVS plugin anymore. Thanks, Kyle [1] http://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/towards-truly-open-and-commoditized-software-defined-networks-in-openstack [2] https://wiki.openstack.org/wiki/Neutron/ML2 Thanks, Kanthi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cheers, Jian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Working with Vagrant and packstack
On Friday, November 29, 2013 2:16:23 AM, Peeyush Gupta wrote: Hi all, I have been trying to set up an openstack environment using vagrant and packstack. I provisioned a Fedora-19 VM through vagrant and used a shell script to take care of installation and other things. The first thing that shell script does is yum install -y openstack-packstack and then packstack --allinone. Now, the issue is that the second command requires me to enter the root's password explicitly. I mean it doesn't matter if I am running this as root or using sudo, I have to enter the password explicitly everytime. I tried to pass the password to the VM through pipes and other methods, but nothing works. Did anyone face the same problem? Is there any way around this? Or does it mean that I can't use puppet/packstack with vagrant? Thanks, ~Peeyush Gupta ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev This sounds like a support question so it should be posted to the general mailing list: https://wiki.openstack.org/wiki/Mailing_Lists#General_List The openstack-dev list is for development discussion topics. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Working with Vagrant and packstack
Agreed with Matt, openstack-dev channel designed for developers discusions. Please find a better place for asking such questions (forums, blogs, etc.) 2013/11/30 Matt Riedemann mrie...@linux.vnet.ibm.com On Friday, November 29, 2013 2:16:23 AM, Peeyush Gupta wrote: Hi all, I have been trying to set up an openstack environment using vagrant and packstack. I provisioned a Fedora-19 VM through vagrant and used a shell script to take care of installation and other things. The first thing that shell script does is yum install -y openstack-packstack and then packstack --allinone. Now, the issue is that the second command requires me to enter the root's password explicitly. I mean it doesn't matter if I am running this as root or using sudo, I have to enter the password explicitly everytime. I tried to pass the password to the VM through pipes and other methods, but nothing works. Did anyone face the same problem? Is there any way around this? Or does it mean that I can't use puppet/packstack with vagrant? Thanks, ~Peeyush Gupta ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev This sounds like a support question so it should be posted to the general mailing list: https://wiki.openstack.org/wiki/Mailing_Lists#General_List The openstack-dev list is for development discussion topics. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator
On 11/29/2013 03:58 PM, Doug Hellmann wrote: On Fri, Nov 29, 2013 at 2:14 PM, Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com wrote: So, as I mention in the branch, what about deployments that haven't transitioned to the library but would like to cherry pick this feature? after it starts moving into a library can leave a very big gap when the functionality isn't available to users. Are those deployments tracking trunk or a stable branch? Because IIUC, we don't add features like this to stable branches for the main components, either, and if they are tracking trunk then they will get the new feature when it ships in a project that uses it. Are you suggesting something in between? Tracking trunk. If the messaging branch has already landed in Nova, then this is a moot discussion. Otherwise we'll still need it in incubator. That said, consider if messaging wasn't in nova trunk. According to this policy the new functionality would have to wait until it was. And, as we've seen with messaging, that was a very long time. That doesn't seem reasonable. Doug -S From: Eric Windisch [e...@cloudscaling.com mailto:e...@cloudscaling.com] Sent: Friday, November 29, 2013 2:47 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [oslo] maintenance policy for code graduating from the incubator Based on that, I would like to say that we do not add new features to incubated code after it starts moving into a library, and only provide stable-like bug fix support until integrated projects are moved over to the graduated library (although even that is up for discussion). After all integrated projects that use the code are using the library instead of the incubator, we can delete the module(s) from the incubator. +1 Although never formalized, this is how I had expected we would handle the graduation process. It is also how we have been responding to patches and blueprints offerings improvements and feature requests for oslo.messaging. -- Regards, Eric Windisch ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] why are we backporting low priority v3 api fixes to v2?
On Sun, Dec 1, 2013 at 8:02 AM, Matt Riedemann mrie...@linux.vnet.ibm.comwrote: I've seen a few bugs/reviews like this [1] lately which are essentially backporting fixes from the nova openstack v3 API to the v2 API. While this is goodness for the v2 API, I'm not sure why we're spending time on low priority bug fixes like this for the v2 API when v3 is the future. Shouldn't only high impact / high probability fixes get backported to the nova v2 API now? I think most people are still using v2 so they are probably happy to get the fixes, but it kind of seems to prolong the inevitable. Am I missing something? The V2 API is going to be with us for quite a while even if the as planned V3 API becomes official with the icehouse release. At the moment the V2 API is still even open for new features - this will probably change at the end of I-2. I agree those bugs are quite low priority fixes and the V3 work is a lot more important, but I don't think we should blocking them yet. We should perhaps reconsider the acceptance of very low priority fixes like you reference towards or at the end of Icehouse. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Stop logging non-exceptional conditions as ERROR
On Nov 28, 2013, at 1:08 AM, Salvatore Orlando sorla...@nicira.com wrote: Thanks Maru, This is something my team had on the backlog for a while. I will push some patches to contribute towards this effort in the next few days. Let me know if you're already thinking of targeting the completion of this job for a specific deadline. I'm thinking this could be a task for those not involved in fixing race conditions, and be done in parallel. I guess that would be for icehouse-1 then? My hope would be that the early signs of race conditions would then be caught earlier. m. Salvatore On 27 November 2013 17:50, Maru Newby ma...@redhat.com wrote: Just a heads up, the console output for neutron gate jobs is about to get a lot noisier. Any log output that contains 'ERROR' is going to be dumped into the console output so that we can identify and eliminate unnecessary error logging. Once we've cleaned things up, the presence of unexpected (non-whitelisted) error output can be used to fail jobs, as per the following Tempest blueprint: https://blueprints.launchpad.net/tempest/+spec/fail-gate-on-log-errors I've filed a related Neutron blueprint for eliminating the unnecessary error logging: https://blueprints.launchpad.net/neutron/+spec/log-only-exceptional-conditions-as-error I'm looking for volunteers to help with this effort, please reply in this thread if you're willing to assist. Thanks, Maru ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Summit session wrapup
I think we may all be approaching the planning of this project in the wrong way, because of confusions such as: Well, I think there is one small misunderstanding. I've never said that manual way should be primary workflow for us. I agree that we should lean toward as much automation and smartness as possible. But in the same time, I am adding that we need manual fallback for user to change that smart decision. Primary way would be to let TripleO decide, where the stuff go. I think we agree here. That's a pretty fundamental requirement that both sides seem to agree upon - but that agreement got lost in the discussions of what feature should come in which release, etc. That seems backwards to me. I think it's far more important that we list out requirements and create a design document that people agree upon first. Otherwise, we run the risk of focusing on feature X for release 1 without ensuring that our architecture supports feature Y for release 2. To make this example more specific: it seems clear that everyone agrees that the current Tuskar design (where nodes must be assigned to racks, which are then used as the primary means of manipulation) is not quite correct. Instead, we'd like to introduce a philosophy where we assume that users don't want to deal with homogeneous nodes individually, instead letting TripleO make decisions for them. When we have a bunch of heterogeneous nodes, we want to be able to break them up into several homogeneous groups, and assign different capabilities to each. But again, within each individual homogeneous group, we don't want users dealing with each individual nodes; instead, we want TripleO to take care of business. The point of disagreement here - which actually seems quite minor to me - is how far we want to go in defining heterogeneity. Are existing node attributes such as cpu and memory enough? Or do we need to go further? To take examples from this thread, some additional possibilities include: rack, network connectivity, etc. Presumably, such attributes will be user defined and managed within TripleO itself. If that understanding is correct, it seems to me that the requirements are broadly in agreement, and that TripleO defined node attributes is a feature that can easily be slotted into this sort of architecture. Whether it needs to come first. . . should be a different discussion (my gut feel is that it shouldn't come first, as it depends on everything else working, but maybe I'm wrong). In any case, if we can a) detail requirements without talking about releases and b) create a design architecture, I think that it'll be far easier to come up with a set of milestones that make developmental sense. Folk that want to manually install openstack on a couple of machines can already do so : we don't change the game for them by replacing a manual system with a manual system. My vision is that we should deliver something significantly better! We should! And we can. But I think we shouldn't deliver something, what will discourage people from using TripleO. Especially at the beginning - see user, we are doing first steps here, the distribution is not perfect and what you wanted, but you can do the change you need. You don't have to go away and come back in 6 months when we try to be smarter and address your case. Regarding this - I think we may want to clarify what the purpose of our releases are at the moment. Personally, I don't think our current planning is about several individual product releases that we expect to be production-ready and usable by the world; I think it's about milestone releases which build towards a more complete product. From that perspective, if I were a prospective user, I would be less concerned with each release containing exactly what I need. Instead, what I would want most out of the project is: a) frequent stable releases (so I can be comfortable with the pace of development and the quality of code) b) design documentation and wireframes (so I can be comfortable that the architecture will support features I need) c) a roadmap (so I have an idea when my requirements will be met) Mainn ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
Excerpts from Adam Young's message of 2013-11-25 20:25:50 -0800: Back in the Day, Barbican was just one Service of Cloud Keep. While I would say that KDS belongs in the Cloud Keep, it is not the same as, and should not be deployed with Barbican. Is it possible to keep them as separate services? I think that is the right way to go. Barbican is for the end users of Cloud, but KDS is not. Does this make sense? They're doing the same fundamental thing for two different sets of users with two overlapping use cases. Why would we implement two KDS services for this? I also don't like that the discussions suggested that because it would be hard to get Barbican incubated/integrated it should not be used. That is just crazy talk. TripleO merged with Tuskar because Tuskar is part of deployment. Seems to me that pulling Barbican into the identity _program_, but still as its own project/repo/etc. would solve that problem. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][hadoop][template] Does anyone has a hadoop template
Excerpts from Jay Lau's message of 2013-11-28 16:48:41 -0800: Hi, I'm now trying to deploy a hadoop cluster with heat, just wondering if someone who has a heat template which can help me do the work. Hi Jay, this is off topic for the openstack-dev mailing list. Please re-post your question on the general OpenStack user discussion list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
