Re: [openstack-dev] [Neutron][L3] FFE request: L3 HA VRRP
+1 - Original Message - +1 On Fri, Mar 7, 2014 at 2:42 AM, Édouard Thuleau thul...@gmail.com wrote: +1 I though it must merge as experimental for IceHouse, to let the community tries it and stabilizes it during the Juno release. And for the Juno release, we will be able to announce it as stable. Furthermore, the next work, will be to distribute the l3 stuff at the edge (compute) (called DVR) but this VRRP work will still needed for that [1]. So if we merge L3 HA VRRP as experimental in I to be stable in J, will could also propose an experimental DVR solution for J and a stable for K. [1] https://docs.google.com/drawings/d/1GGwbLa72n8c2T3SBApKK7uJ6WLTSRa7erTI_3QNj5Bg/edit Regards, Édouard. On Thu, Mar 6, 2014 at 4:27 PM, Sylvain Afchain sylvain.afch...@enovance.com wrote: Hi all, I would like to request a FFE for the following patches of the L3 HA VRRP BP : https://blueprints.launchpad.net/neutron/+spec/l3-high-availability https://review.openstack.org/#/c/64553/ https://review.openstack.org/#/c/66347/ https://review.openstack.org/#/c/68142/ https://review.openstack.org/#/c/70700/ These should be low risk since HA is not enabled by default. The server side code has been developed as an extension which minimizes risk. The agent side code introduces a bit more changes but only to filter whether to apply the new HA behavior. I think it's a good idea to have this feature in Icehouse, perhaps even marked as experimental, especially considering the demand for HA in real world deployments. Here is a doc to test it : https://docs.google.com/document/d/1P2OnlKAGMeSZTbGENNAKOse6B2TRXJ8keUMVvtUCUSM/edit#heading=h.xjip6aepu7ug -Sylvain ___ 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] [sahara] Prefix for -dev mailing list [savanna]
Hey folks, please, note, that we should prepend mail subject with [sahara] and append [savanna] to the end for transition period. Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [sahara] Sahara (ex. Savanna) project renaming process [savanna]
Matt, thanks for moving etherpad notes to the blueprints. I've added some notes and details to them and add some assignments to the blueprints where we have no choice. https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci - Sergey Kolekonov https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-guestagent - Dmitry Mescheryakov Thanks. On Sat, Mar 8, 2014 at 5:08 PM, Matthew Farrellee m...@redhat.com wrote: On 03/07/2014 04:50 PM, Sergey Lukjanov wrote: Hey folks, we're now starting working on the project renaming. You can find details in the etherpad [0]. We'll move all work items to the blueprints, one blueprint per sub-project to well track progress and work items. The general blueprint is [1], it'll depend on all other blueprints and it's currently consists of general renaming tasks. Current plan is to assign each subproject blueprint to volunteer. Please, contact me and Matthew Farrellee if you'd like to take the renaming bp. Please, share your ideas/suggestions in ML or etherpad. [0] https://etherpad.openstack.org/p/savanna-renaming-process [1] https://blueprints.launchpad.net/openstack?searchtext=savanna-renaming Thanks. P.S. Please, prepend email topics with [sahara] and append [savanna] to the end of topic (like in this email) for the transition period. savann^wsahara team, i've separated out most of the activities that can happen in parallel, aligned them on repository boundaries, and filed blueprints for the efforts. now we need community members to take ownership (be the assignee) of the blueprints. taking ownership means you'll be responsible for the renaming in the repository, coordinating with other owners and getting feedback from the community about important questions (such as compatibility requirements). to take ownership, just go to the blueprint and assign it to yourself. if there is already an assignee, reach out to that person and offer them assistance. blueprints up for grabs - what: savanna^wsahara ci blueprint: https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci comments: this should be taken by someone already familiar with the ci. i'd nominate skolekonov what: saraha puppet modules blueprint: https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-puppet comments: this should be taken by someone who can validate the changes. i'd nominate sbadia or dizz what: sahara extras blueprint: https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-extra comments: this could be taken by anyone what: sahara dib image elements blueprint: https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-image-elements comments: this could be taken by anyone what: sahara python client blueprint: https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-client comments: this should be done by someone w/ experience in the client. i'd nominate tmckay what: sahara horizon plugin blueprint: https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-dashboard comments: this will require experience and care. i'd nominate croberts what: sahara guestagent blueprint: https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-guestagent comments: i'd nominate dmitrymex what: sahara section of openstack wiki blueprint: https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-wiki comments: this could be taken by anyone what: sahara service blueprint: https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-service comments: this requires experience, care and is a lot of work. i'd nominate alazarev aignatov to tag team it ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [sahara] Sahara (ex. Savanna) project renaming process [savanna]
Hey Swapnil, thanks for the note. This name was checked by the OpenStack Foundation lawyers, so, I think that they decided that there's no potential issues with this company. FYI we're renaming Savanna because they find http://thetus.com/savanna that's Hadoop-backed analytics on cloud (the same area as our project). I'll ask lawyers about this to be sure. Thanks. On Sun, Mar 9, 2014 at 4:16 AM, Swapnil Kulkarni swapnilkulkarni2...@gmail.com wrote: Hey guys, Sahara is a known corporate group in India, wanted to bring it up before renaming starts. [1] https://www.google.co.in/search?q=sahara+group [2] http://www.sahara.in/ [3] http://www.sahara-group.com/ Best Regards, Swapnil Kulkarni irc : coolsvap On Sat, Mar 8, 2014 at 3:20 AM, Sergey Lukjanov slukja...@mirantis.com wrote: Hey folks, we're now starting working on the project renaming. You can find details in the etherpad [0]. We'll move all work items to the blueprints, one blueprint per sub-project to well track progress and work items. The general blueprint is [1], it'll depend on all other blueprints and it's currently consists of general renaming tasks. Current plan is to assign each subproject blueprint to volunteer. Please, contact me and Matthew Farrellee if you'd like to take the renaming bp. Please, share your ideas/suggestions in ML or etherpad. [0] https://etherpad.openstack.org/p/savanna-renaming-process [1] https://blueprints.launchpad.net/openstack?searchtext=savanna-renaming Thanks. P.S. Please, prepend email topics with [sahara] and append [savanna] to the end of topic (like in this email) for the transition period. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ 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 -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [GSoC 2014] Proposal Template
Hi dims/Masaru, Thanks for the detailed explanation.I have added the link to a project idea page. Thanks, --sai krishna. On Fri, Mar 7, 2014 at 7:43 PM, Masaru Nomura massa.nom...@gmail.comwrote: Sai, There may be more than one person on a topic, so it would make sense to have additional questions per person. Yes, link to project idea is definitely needed. -- dims On Thu, Mar 6, 2014 at 11:41 AM, saikrishna sripada krishna1256 at gmail.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev wrote: *Hi Masaru,* *I tried creating the project template following your suggestions.Thats* *really helpful. Only one suggestion:* *Under the project description, We can give the link to actual project idea.* *The remaining details like these can be removed here since this can be* *redundant.* *What is the goal?* *How will you achieve your goal?* *What would be your milestone?* *At which time will you complete a sub-task of your project?* *These details we will be filling any way in the Project template link just* *which will be just below in the page. Please confirm.* *Thanks,* *--sai krishna.* Hi Sai, dims Thank you for your replies! *Under the project description, We can give the link to actual project idea.* *The remaining details like these can be removed here since this can be* *redundant.* I could've got you wrong but I guess you mean 4 exapmles are trivial, right? Firstly, the point I wanted to make in the section is to give some examples to students who haven't had experience of GSoC or other sorts of projects. I'd say these help them understand what they have to provide. Secondly, in addition to what dims mentioned, some students would like to propose their own project. If this is the case, it makes sense as they may not have a link to a project idea page (though I'm quite sure these people know exactly what to do). Yes, link to project idea is definitely needed. So, can we add one thing to Project Description? e.g. Link to a project idea page (if any) I have no objection to this as it can help reviewers access to the page easily. Thanks, Masaru ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] FFE request: L3 HA VRRP
+1 I see it as one of the main current gaps and I believe that this is something that can promote Neutron as stable and production ready. Based on Édouard's comment below, having this enabled in Icehouse as experimental makes a lot of sense to me. - Original Message - +1 - Original Message - +1 On Fri, Mar 7, 2014 at 2:42 AM, Édouard Thuleau thul...@gmail.com wrote: +1 I though it must merge as experimental for IceHouse, to let the community tries it and stabilizes it during the Juno release. And for the Juno release, we will be able to announce it as stable. Furthermore, the next work, will be to distribute the l3 stuff at the edge (compute) (called DVR) but this VRRP work will still needed for that [1]. So if we merge L3 HA VRRP as experimental in I to be stable in J, will could also propose an experimental DVR solution for J and a stable for K. [1] https://docs.google.com/drawings/d/1GGwbLa72n8c2T3SBApKK7uJ6WLTSRa7erTI_3QNj5Bg/edit Regards, Édouard. On Thu, Mar 6, 2014 at 4:27 PM, Sylvain Afchain sylvain.afch...@enovance.com wrote: Hi all, I would like to request a FFE for the following patches of the L3 HA VRRP BP : https://blueprints.launchpad.net/neutron/+spec/l3-high-availability https://review.openstack.org/#/c/64553/ https://review.openstack.org/#/c/66347/ https://review.openstack.org/#/c/68142/ https://review.openstack.org/#/c/70700/ These should be low risk since HA is not enabled by default. The server side code has been developed as an extension which minimizes risk. The agent side code introduces a bit more changes but only to filter whether to apply the new HA behavior. I think it's a good idea to have this feature in Icehouse, perhaps even marked as experimental, especially considering the demand for HA in real world deployments. Here is a doc to test it : https://docs.google.com/document/d/1P2OnlKAGMeSZTbGENNAKOse6B2TRXJ8keUMVvtUCUSM/edit#heading=h.xjip6aepu7ug -Sylvain ___ 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
Re: [openstack-dev] [nova] a question about instance snapshot
Hi, Jeremy, the discussion at here http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html Thanks Alex On 2014年03月07日 10:29, Liuji (Jeremy) wrote: Hi, all Current openstack seems not support to snapshot instance with memory and dev states. I searched the blueprint and found two relational blueprint like below. But these blueprint failed to get in the branch. [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots [2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms In the blueprint[1], there is a comment, We discussed this pretty extensively on the mailing list and in a design summit session. The consensus is that this is not a feature we would like to have in nova. --russellb But I can't find the discuss mail about it. I hope to know why we think so ? Without memory snapshot, we can't to provide the feature for user to revert a instance to a checkpoint. Anyone who knows the history can help me or give me a hint how to find the discuss mail? I am a newbie for openstack and I apologize if I am missing something very obvious. Thanks, Jeremy Liu ___ 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] [Ironic] [Nova] Status of the nova ironic driver and CI
With the feature freeze in effect and our driver blocked from the Nova tree for this release cycle, last week we moved our driver into the Ironic tree in this patch set: https://review.openstack.org/#/c/78002/ This allows Nova to load the ironic virt driver by importing the ironic.nova.virt.ironic.IronicDriver class. We plan to resubmit this driver to Nova when Juno opens, and remove it from the Ironic code base once it is accepted. Why did we do this? Most importantly, it allows us to continue working on CI testing during feature freeze and without any cross-project dependencies. No Nova changes are required, and -- for the moment -- we trust ourselves enough to land code in this driver without integration tests. We also made a lot of progress on the devstack patch: https://review.openstack.org/#/c/70348/ This patch configures Nova to use the ironic virt driver, sets up the prerequisite environment, and performs integration tests (eg, with nova, glance, keystone, and neutron) and functional tests of the PXE deploy driver in a mocked bare metal environment. This is now the only change required to perform these tests. If the infra team is amenable to adding an experimental check test to Ironic's pipeline during feature-freeze, I will propose one, and we can start identifying the set of tempest tests which make sense in a mocked bare metal environment. If not, we can wait until Juno opens to propose this. Thanks to agordeev, adam_g, and shrews for their hard work on adding devstack support for Ironic! We're almost there :) Cheers, Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] A ramdisk agent
For those looking at Pecan/WSME'fying the agent, some scaffolding was recently added to Pecan which may interest you. https://review.openstack.org/#/c/78682/ -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OSSG][OSSN] DoS style attack on noVNC server can lead to service interruption or disruption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 DoS style attack on noVNC server can lead to service interruption or disruption - --- ### Summary ### There is currently no limit to the number of noVNC or SPICE console sessions that can be established by a single user. The console host has limited resources and an attacker launching many sessions may be able to exhaust the available resources, resulting in a Denial of Service (DoS) condition. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-secur...@lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHJz3AAoJEJa+6E7Ri+EVdHUH/10DusIv3xhL9rsnxhP5vbKW tucqnh4MxaVX7ZfyKhD1aEme1IXtupbfGxOqF1Xa35PXPv/pHTDjhs3HEcnB3MVf PzAx8o3fywIxqVsTcdrweLOhZ2EirhG56WudiLOL+J5zVjfU5Cz4sZgIf3DvqRpk hpy0fWGMRExir8PgPpByTSJxuqQx1gsYeUqnvV8VknmoR1SW5Dk2RLP3cy+4aMNA qTYXug3Le71Ra4ligp/6BzA/L7+zaVBM2OFOIU2RXCt29S5zmCTI6EuPiQXPstwK /qEIPnNXwA4vY6r6iObDBa+K5CBEqMkI4rJTl1kSxksYx+g8UD6EQhlIgb51d2U= =XyEq -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] GSOC 2014 proposal
Dear All, I am a student in Columbia University (Yan Cui), and want to join the openstack GSOC 2014. After scanned the idea list posted online, I think I am interested in the idea titled implement a scalable scheduler. Currently, I wonder to know, before submitting an application on GSOC home page, do I need to submit some documents in the community (to review?) Best Wishes! -- Think big; Dream impossible; Make it happen. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][db] Thoughts on making instances.uuid non-nullable?
On 12/16/2013 11:01 AM, Shawn Hartsock wrote: +1 on a migration to make uuid a non-nullable column. I advocated a few patches back in Havana that make assumptions based on the UUID being present and unique per instance. If it gets nulled the VMware drivers will have have breakage and I have no idea how to avoid that reasonably without the UUID. On Mon, Dec 16, 2013 at 11:59 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 12/16/2013 11:45 AM, Matt Riedemann wrote: 1. Add a migration to change instances.uuid to non-nullable. Besides the obvious con of having yet another migration script, this seems the most straight-forward. The instance object class already defines the uuid field as non-nullable, so it's constrained at the objects layer, just not in the DB model. Plus I don't think we'd ever have a case where instance.uuid is null, right? Seems like a lot of things would break down if that happened. With this option I can build on top of it for the DB2 migration support to add the same FKs as the other engines. Yeah, having instance.uuid nullable doesn't seem valuable to me, so this seems OK. -- Russell Bryant ___ 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 -- # Shawn.Hartsock - twitter: @hartsock - plus.google.com/+ShawnHartsock http://plus.google.com/+ShawnHartsock ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I've been working on this more and am running up against some issues, part of this has to do with my lack of sqlalchemy know-how and inexperience with writing DB migrations, so dumping some info/problems here to see where people would like me to take this. My original thinking for doing a migration was to delete the instances records where uuid == None and then move those to shadow_instances, then make instances.uuid.nullable=False. Some of the problems with this approach are: 1. There are at least 5 other tables related to instances that need to be handled for a delete: InstanceFault, InstanceMetadata, InstanceSystemMetadata, InstanceInfoCache and SecurityGroupInstanceAssociation. Also, these tables don't define their instance_uuid column the same way, some have it nullable=False and others don't. 2. I'm not sure if I can use a session in the migration to make it a transaction. 3. This would make the instances and shadow_instances tables have different schemas, i.e. instances.uuid would be nullable=False in instances but nullable=True in shadow_instances. Maybe this doesn't matter. The whole reason behind using shadow_instances (or any backup table I guess) was so I could restore the records on DB downgrade. So the more I think about this, I'm getting to the point of asking: 1. Do we even care about instances where uuid is None? I'd have to think those wouldn't be working well in the current code with how everything relies on uuid for foreign keys and tracking relationships to volumes, images and networks across services. If the answer is 'no' then the migration is pretty simple, just delete the records where uuid is None and be done with it. You couldn't downgrade to get them back, but in this case we're asserting that we don't want them back. 2. Have an alternative schema in the DB2 case. This would be handled in the 216_havana migration when the instances table is defined and created, we'd just make the uuid column non-nullable in the DB2 case and leave it nullable for all other engines. Anyone moving to DB2 would have to install from scratch anyway since there is no tooling to migrate a MySQL DB to DB2, for example. As it stands, the 216_havana migration in my patch [1] already has a different schema for DB2 because of the foreign keys it can't create due to this problem. Anyway, looking for some thoughts on how to best handle this, or if anyone has other ideas or good reasons why either approach couldn't be used. [1] https://review.openstack.org/#/c/69047/ -- 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] MuranoPL questions?
I'd be very interested in knowing the resource controls u plan to add. Memory, CPU... I'm still trying to figure out where something like https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.demoApp.DemoInstance/manifest.yaml would be beneficial, why not just spend effort sand boxing lua, python... Instead of spending effort on creating a new language and then having to sandbox it as well... Especially if u picked languages that are made to be sandboxed from the start (not python)... Who is going to train people on muranoPL, write language books and tutorials when the same amount of work has already been done for 10+ years for other languages I fail to see where muranoPL is a DSL when it contains a full language already with functions, objects, namespaces, conditionals... (what is the domain of it?), maybe I'm just confused though (quite possible, haha). Does this not seem awkward to anyone else?? Sent from my really tiny device... On Mar 8, 2014, at 10:44 PM, Stan Lagun sla...@mirantis.commailto:sla...@mirantis.com wrote: First of all MuranoPL is not a host but hosted language. It never intended to replace Python and if Python can do the job it is probably better than MuranoPL for that job. The problem with Python is that you cannot have Python code as a part of your DSL if you need to evaluate that DSL on server-side. Using Python's eval() is not secure. And you don't have enough control on what evaled code is allowed to do. MuranoPL on the contrary are fully sandboxed. You have absolute control over what functions/methods/APIs are exposed to DSL and DSL code can do nothing except for what it allowed to do. Besides you typically do want your DSL to be domain-specific so general-purpose language like Python can be suboptimal. I don't say MuranoPL is good for all projects. It has many Murano-specific things after all. In most cases you don't need all those OOP features that MuranoPL has. But the code organization, how it uses YAML, block structures and especially YAQL expressions can be of a great value to many projects For examples of MuranoPL classes you can browse https://github.com/istalker2/MuranoDsl/tree/master/meta folder. This is my private repository that I was using to develop PoC for MuranoPL engine. We are on the way to create production-quality implementation with unit-tests etc. in regular Murano repositories on stackforge On Sun, Mar 9, 2014 at 7:33 AM, Joshua Harlow harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote: To continue from other thread Personally I believe that YAQL-based DSLs similar (but probably simlet than) MuranoPL can be of a great value for many OpenStack projects that have DSLs of different kind. Murano for App Catatalog, Mistral for workflows, Heat for HOT templates, Ceilometer for alarms counter aggregation rules, Nova for customizable resource scheduling and probably many more. Isn't python a better host language for said DSLs than muranoPL? I am still pretty weary of a DSL that starts to grow so many features to encompass other DSLs since then it's not really a DSL but a non-DSL, and we already have one that everyone is familiar with (python). Are there any good examples if muranoPL that I can look at that take advantage of muranoPL classes, functions, namespaces which can be compared to there python equivalents. Has such an analysis/evaluation been done? Sent from my really tiny device... ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours Stanislav (Stan) Lagun Senior Developer Mirantis 35b/3, Vorontsovskaya St. Moscow, Russia Skype: stanlagun www.mirantis.comhttp://www.mirantis.com/ sla...@mirantis.commailto:sla...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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][db] Thoughts on making instances.uuid non-nullable?
Hi Matt, interesting questions/points. Some comments inline. On Sun, 2014-03-09 at 15:20 -0500, Matt Riedemann wrote: snip I've been working on this more and am running up against some issues, part of this has to do with my lack of sqlalchemy know-how and inexperience with writing DB migrations, so dumping some info/problems here to see where people would like me to take this. My original thinking for doing a migration was to delete the instances records where uuid == None and then move those to shadow_instances, then make instances.uuid.nullable=False. Some of the problems with this approach are: 1. There are at least 5 other tables related to instances that need to be handled for a delete: InstanceFault, InstanceMetadata, InstanceSystemMetadata, InstanceInfoCache and SecurityGroupInstanceAssociation. Also, these tables don't define their instance_uuid column the same way, some have it nullable=False and others don't. All tables should define the instance uuid column in the same way, and making that consistent should best be done as part of the same migration. The reasoning, of course, is that these columns represent identical data (primary to child key relations), and therefore the schema of all the columns should be identical. 2. I'm not sure if I can use a session in the migration to make it a transaction. You can use a transaction around all statements, including DDL, in PostgreSQL. In MySQL, you can use a transaction only around DML statements, but any DDL statement will cause a flush of all transactions before the DDL statement begins. I'd recommend doing all of the necessary moves of records (between the shadow tables and regular tables) within a single transaction so that at least there is some level of data consistency ensured for those operations. But, unfortunately, the DDL schema changes will not occur within a transaction unless you are using PostgreSQL and Alembic migrations. 3. This would make the instances and shadow_instances tables have different schemas, i.e. instances.uuid would be nullable=False in instances but nullable=True in shadow_instances. Maybe this doesn't matter. No, I don't think this matters much, to be honest. I'm not entirely sure what the long-term purpose of the shadow tables are in Nova -- perhaps someone could clue me in to whether the plan is to keep them around? The whole reason behind using shadow_instances (or any backup table I guess) was so I could restore the records on DB downgrade. So the more I think about this, I'm getting to the point of asking: 1. Do we even care about instances where uuid is None? I'd have to think those wouldn't be working well in the current code with how everything relies on uuid for foreign keys and tracking relationships to volumes, images and networks across services. Agreed. I don't personally think instance records with no UUID are useful in Nova any more. If the answer is 'no' then the migration is pretty simple, just delete the records where uuid is None and be done with it. You couldn't downgrade to get them back, but in this case we're asserting that we don't want them back. This is exactly what I would recommend. 2. Have an alternative schema in the DB2 case. This would be handled in the 216_havana migration when the instances table is defined and created, we'd just make the uuid column non-nullable in the DB2 case and leave it nullable for all other engines. Anyone moving to DB2 would have to install from scratch anyway since there is no tooling to migrate a MySQL DB to DB2, for example. As it stands, the 216_havana migration in my patch [1] already has a different schema for DB2 because of the foreign keys it can't create due to this problem. Nah, I don't think we want to keep a special schema just for DB2. That's technical debt that I don't think it worthwhile to keep around... Best, -jay Anyway, looking for some thoughts on how to best handle this, or if anyone has other ideas or good reasons why either approach couldn't be used. [1] https://review.openstack.org/#/c/69047/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] A ramdisk agent
FYI, the API scaffolding isn’t actually released yet, though I’m planning on making a pecan release with this in the next week or two. --- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com On Mar 9, 2014, at 12:10 PM, Devananda van der Veen devananda@gmail.com wrote: For those looking at Pecan/WSME'fying the agent, some scaffolding was recently added to Pecan which may interest you. https://review.openstack.org/#/c/78682/ -Deva ___ 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] stored userdata
On 08/03/14 03:14, Stephen Gran wrote: On 07/03/14 05:05, Hiroyuki Eguchi wrote: I'm envisioning a stored userdata feature. https://blueprints.launchpad.net/nova/+spec/stored-userdata Currently, OpenStack allow user to execute script or send configuration file when creating a instance by using --user-data /path/to/filename option. But,In order to use this option, All users must input userdata every time. So we need to store the userdata in database so that users can manage userdata more easily. I'm planning to develop these Nova-APIs. - nova userdata-create - nova userdata-update - nova userdata-delete - nova userdata-show - nova userdata-list Users can specify a userdata_name managed by Nova DB or /path/to/filename in --user-data option. - nova boot --user-data userdata_name or /path/to/filename ... If you have any comments or suggestion, please let me know. And please let me know if there's any discussion about this. In general, I think userdata should be WORM. It certainly is in every other cloud setup I am familiar with. This is the information fed to the instance when it boots the first time - having userdata change over time means you lose access to the original when you want to go back and retrieve it. I think this would be a regression, and be unexpected behavior. Cheers, I have an abandoned changeset which allowed for userdata to be updated post-boot: https://blueprints.launchpad.net/nova/+spec/update-userdata Heat orchestrated servers need to poll for configuration metadata changes. My intention was to push this data to userdata, so the server could poll for changes by doing a simple unauthenticated curl call to the nova metadata service. I'm not currently pursuing this approach but I wouldn't object to someone else taking it over. cheers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominating Radomir Dopieralski to Horizon Core
Belated +1. Thanks Radomir. It's great to see all the new contributors in this cycle. On 6 March 2014 09:36, Lyle, David david.l...@hp.com wrote: I'd like to nominate Radomir Dopieralski to Horizon Core. I find his reviews very insightful and more importantly have come to rely on their quality. He has contributed to several areas in Horizon and he understands the code base well. Radomir is also very active in tuskar-ui both contributing and reviewing. David ___ 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] [Gantt] [GSoC] Clarifications about Gantt opportunities for GSoC
Hi, I previously already sent an email but I'm recreating it in its own thread. I just discovered that Gantt has been proposed as part of the ideas for GSoC [1] While I truly understand the mutual opportunities for both students and Openstack, I'm thinking that Gantt is too young and yet to be stabiliized before being ready for accepting applicants. During the last weekly meetings we had, a strategy for deploying Gantt on its roots has been defined and corresponding as follows : 1. split out the dependencies from Nova by not proxying VM creation thru the scheduler, but rather let the conductor place a call to the scheduler and then spawn the VMs 2. provide a scheduler library for resource tracking 3. forklift Nova scheduler code into Gantt As Nova is currently under Feature Freeze until Juno summit, and as most of the design discussions will happen at the Summit, Gantt will not be targeted to be delivered early in June, and will probably not be ready until July/August. Regarding the GSoC timeline (coding beginning on mid-May with a mid-time evaluation on end-june) [2], I consider Gantt as not matching with the necessary requirements. Following that, I ask GSoC proposed mentors to think about it and reconsider Gantt as not an idea proposal for GSoC. That said, Nova scheduler improvements (scalable scheduler, or others) can be considered as good proposals but that's Nova, not Gantt responsability. Feel free to comment, Thanks, -Sylvain [1] https://wiki.openstack.org/wiki/GSoC2014#Common_Scheduler_.28Gantt.29 [2] http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page#2._What_is_the_program_timeline ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6][Security Group] BP: Support ICMP type filter by security group
Thanks all for your comments! Do you guys think we can have a summit session to discuss the next steps? I can prepare a spec if needed. Thanks, Xuhan — Xu Han Peng (xuhanp) On Sat, Mar 8, 2014 at 3:19 AM, Akihiro Motoki amot...@gmail.com wrote: Hi Robert, Thanks for the clarification. I understand the motivation. I think the problem can be split into two categories: (a) user configurable rules vs infra enforced rule, and (b) DHCP/RA service exists inside or outside of Neutron Regarding (a), I believe DHCP or RA related rules is better to be handled by the infra side because it is required to ensure DHCP/RA works well. I don't think it is a good idea to delegate users to configure rule to allow them. It works as long as DHCP/RA service works inside OpenStack. This is the main motivation of my previous question. On the other hand, there is no way to cooperate with DHCP/RA services outside of OpenStack at now. This blocks the usecase in your mind. It is true that the current Neutron cannot works with dhcp server outside of neutron. I agree that adding a security group rule to allow RA is reasonable as a workaround. However, for a long time solution, it is better to explore a way to configure infra-required rules. Thanks, Akihiro On Sat, Mar 8, 2014 at 12:50 AM, Robert Li (baoli) ba...@cisco.com wrote: Hi Akihiro, In the case of IPv6 RA, its source IP is a Link Local Address from the router's RA advertising interface. This LLA address is automatically generated and not saved in the neutron port DB. We are exploring the idea of retrieving this LLA if a native openstack RA service is running on the subnet. Would SG be needed with a provider net in which the RA service is running external to openstack? In the case of IPv4 DHCP, the dhcp port is created by the dhcp service, and the dhcp server ip address is retrieved from this dhcp port. If the dhcp server is running outside of openstack, and if we'd only allow dhcp packets from this server, how is it done now? thanks, Robert On 3/7/14 12:00 AM, Akihiro Motoki amot...@gmail.com wrote: I wonder why RA needs to be exposed by security group API. Does a user need to configure security group to allow IPv6 RA? or should it be allowed in infra side? In the current implementation DHCP packets are allowed by provider rule (which is hardcoded in neutron code now). I think the role of IPv6 RA is similar to DHCP in IPv4. If so, we don't need to expose RA in security group API. Am I missing something? Thanks, Akihiro On Mon, Mar 3, 2014 at 10:39 PM, Xuhan Peng pengxu...@gmail.com wrote: I created a new blueprint [1] which is triggered by the requirement to allow IPv6 Router Advertisement security group rule on compute node in my on-going code review [2]. Currently, only security group rule direction, protocol, ethertype and port range are supported by neutron security group rule data structure. To allow Router Advertisement coming from network node or provider network to VM on compute node, we need to specify ICMP type to only allow RA from known hosts (network node dnsmasq binded IP or known provider gateway). To implement this and make the implementation extensible, maybe we can add an additional table name SecurityGroupRuleData with Key, Value and ID in it. For ICMP type RA filter, we can add key=icmp-type value=134, and security group rule to the table. When other ICMP type filters are needed, similar records can be stored. This table can also be used for other firewall rule key values. API change is also needed. Please let me know your comments about this blueprint. [1] https://blueprints.launchpad.net/neutron/+spec/security-group-icmp-type-f ilter [2] https://review.openstack.org/#/c/72252/ Thank you! Xuhan Peng ___ 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
Re: [openstack-dev] [nova][db] Thoughts on making instances.uuid non-nullable?
2014-03-10 4:47 GMT+08:00 Jay Pipes jaypi...@gmail.com: 3. This would make the instances and shadow_instances tables have different schemas, i.e. instances.uuid would be nullable=False in instances but nullable=True in shadow_instances. Maybe this doesn't matter. No, I don't think this matters much, to be honest. I'm not entirely sure what the long-term purpose of the shadow tables are in Nova -- perhaps someone could clue me in to whether the plan is to keep them around? As I know the tables shadow_* are used by command ' nova-manage db archive_deleted_rows' , which moves records with deleted=True to table shadow_* . That means these tables are used by other process, So, I think we need other tables to store the old records in your migration . -- ChangBo Guo(gcb) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][db] Thoughts on making instances.uuid non-nullable?
On Mon, 2014-03-10 at 10:05 +0800, ChangBo Guo wrote: 2014-03-10 4:47 GMT+08:00 Jay Pipes jaypi...@gmail.com: 3. This would make the instances and shadow_instances tables have different schemas, i.e. instances.uuid would be nullable=False in instances but nullable=True in shadow_instances. Maybe this doesn't matter. No, I don't think this matters much, to be honest. I'm not entirely sure what the long-term purpose of the shadow tables are in Nova -- perhaps someone could clue me in to whether the plan is to keep them around? As I know the tables shadow_* are used by command ' nova-manage db archive_deleted_rows' , which moves records with deleted=True to table shadow_* . That means these tables are used by other process, So, I think we need other tables to store the old records in your migration. Yeah, that's what I understood the shadow tables were used for, I just didn't know what the long-term future of these tables was... curious if there's been any discussion about that. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] development workflows
Mathew, Thats really cool. I've been using vagrant for a while and Ed created this repo and it works pretty well. We've been using it for about 6 months or longer. Its nice if you want to be able to test something locally. https://github.com/ed-/trove-vagrant-vmware I've been exploring using a pure remote VM to run things like what your document describes. I like the idea of using a post hook. Thanks, Craig On Thu, Mar 6, 2014 at 11:00 AM, Lowery, Mathew mlow...@ebay.com wrote: So I submitted this dochttp://docs-draft.openstack.org/29/70629/3/check/gate-trove-docs/34ceff7/doc/build/html/dev/install_alt.html (in this patch set https://review.openstack.org/#/c/70629/) and Dan Nguyen (thanks Dan) stated that there were some folks using Vagrant. (My workflow uses git push with a git hook to copy files and trigger restarts.) Can anyone point me to any doc regarding Trove using Vagrant? Assuming my doc is desirable in some form, where is the best place to put it? Thanks. ___ 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] a question about instance snapshot
-Original Message- From: Alex Xu [mailto:x...@linux.vnet.ibm.com] Sent: Sunday, March 09, 2014 10:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] a question about instance snapshot Hi, Jeremy, the discussion at here http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html I have a great interest in the topic too. I read the link you provided, and there is a little confusion for me. I agree with the security consideration in the discussion and memory snapshot can't be used for the cloning instance easily. But I think it's safe for the using for Instance revert. And revert the instance to a checkpoint is valuable for the user. Why we didn't use it for instance revert in the first step? Best regards to you. Ricky Thanks Alex On 2014年03月07日 10:29, Liuji (Jeremy) wrote: Hi, all Current openstack seems not support to snapshot instance with memory and dev states. I searched the blueprint and found two relational blueprint like below. But these blueprint failed to get in the branch. [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots [2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms In the blueprint[1], there is a comment, We discussed this pretty extensively on the mailing list and in a design summit session. The consensus is that this is not a feature we would like to have in nova. --russellb But I can't find the discuss mail about it. I hope to know why we think so ? Without memory snapshot, we can't to provide the feature for user to revert a instance to a checkpoint. Anyone who knows the history can help me or give me a hint how to find the discuss mail? I am a newbie for openstack and I apologize if I am missing something very obvious. Thanks, Jeremy Liu ___ 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
