Re: [Openstack] [Heat]Multi heat-engine?
On 03/19/2013 01:36 AM, gtt116 wrote: Hi, all Can I running more than one heat-engine for failover or expanding the scale? If I can, is the periodic watcher task will conflict with other heat-engine? Thanks in advance for the answers. We are looking to have a design session at Summit relating to horizontal scalability Heat. The Heat architecture is designed for it, however, at the present, the devs have not tested multiple engines and we believe more work is required here. Regards -steve ___ 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] [Networking/DNS] Proposal to make Moniker the default for DNS
On 03/19/2013 01:39 AM, Endre Karlson wrote: Hi, I would like to propose Moniker as the default for DNS going forwards. We where picked in a vote by several interested people to be the default DNS implementation last year out of the available projects. The current state of the project is: * Several DNSaaS is built on Moniker - HP Cloud's for one. * Support for multiple record types A, , SPF, CNAME, NS, MX, configurable TTLs. * Pluggable storage layer - currently only SQLAlchemy. * Pluggable DNS backends that can either be run in a Central process or in agents on seperate servers for redundancy - Bind9, Bind9 with MySQL, PowerDNS, DNSMasq * Pluggable notification handling - Support for Quantum and Nova via MQ notifications. * REST API using Flask and JSONSchema. * python-monikerclient for bindings / cli. Recommend applying for incubation. An example request: https://lists.launchpad.net/openstack/msg14700.html The process can be found here: https://wiki.openstack.org/wiki/Governance/Approved/Incubation Github / Code: http://github.com/stackforge/moniker Bugs / LP: http://launchpad.net/moniker IRC: #openstack-dns Endre Karlson ___ 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] orchestration engine wrt to openstack api
On 03/04/2013 08:02 AM, Nirlay Kundu wrote: Which tool would you use for configuration management geared towards Openstack api : Chef, Puppet, Saltstack ? If anybody has experience with Saltstack, please let me know the advantages , shortcomings. Nirlay, You might download heat from here: https://launchpad.net/heat/grizzly/grizzly-3 And give it a go with the documentation available here: https://wiki.openstack.org/wiki/Heat Heat provides a native openstack API for orchestration as well as an AWS CloudFormation API. Regards -steve Thanks Nirlay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [heat] Grizzly-2 development milestone available for Heat
Hi folks, The OpenStack release team has released the second milestone of the Grizzly development cycle (grizzly-2). This is a significant step in Heat's incubation, as it is our first milestone release leading to the final delivery of OpenStack 2013.1 scheduled for April 4, 2013. You can find the full list of new features and fixed bugs, as well as tarball downloads at: https://launchpad.net/heat/grizzly/grizzly-2 Features and bugs may be resolved until the next milestone, grizzly-3, which will be delivered on February 21st. Come join the growing orchestration development community by contributing to Heat and making orchestration in OpenStack world class! Regards -steve ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [heat] 10-08-2012 Heat Planning and Status meeting
= #heat Meeting = Meeting started by sdake at 21:00:38 UTC. The full logs are available at: http://heat-api.org/heat-irc-meetings/heat.2012-10-08-21.00.log.html Meeting summary --- * rollcall (sdake, 21:03:34) * v7 release (sdake, 21:04:43) * remaining for incubation (sdake, 21:08:00) * rest API in, but needs bit more work around events/resources (sdake, 21:11:05) * need to sort out a python-heatclient repo (sdake, 21:12:57) * cloudwatch security model ready by summit (sdake, 21:29:32) * LINK: https://github.com/heat-api/heat/issues/173 (sdake, 21:29:58) * v7 priorities - rest api, resource dictionary mapping, cloudwatch security, python-heatclient (sdake, 21:36:51) * bugs (sdake, 21:38:06) * LINK: https://github.com/heat-api/heat-jeos/issues/13 (sdake, 21:38:21) * LINK: https://github.com/heat-api/heat-jeos/issues/20 (sdake, 21:39:10) * LINK: https://github.com/heat-api/heat/issues/249 (sdake, 21:39:44) * LINK: https://github.com/heat-api/heat/issues/190 (sdake, 21:41:43) * release schedule (sdake, 21:43:07) * zaneb release manager for v7 on 15th (sdake, 21:49:24) * summit planning (sdake, 21:49:52) * LINK: http://wiki.openstack.org/Heat/GrizzlySummit/HeatApiDraftDiscussion (sdake, 21:50:05) * LINK: http://wiki.openstack.org/Heat/GrizzlySummit/HeatImplementingCloudWatch (sdake, 21:50:13) * LINK: http://wiki.openstack.org/Heat/GrizzlySummit/HeatRoadmapPastandFuture (sdake, 21:50:22) * open issues (sdake, 21:51:58) * LINK: https://gist.github.com/2369729 (stevebake, 21:57:18) * vote passed unanimously to migrate wiki to blueprints - migrate issues to launchpad bugs (sdake, 22:00:26) Meeting ended at 22:06:22 UTC. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [heat] 9-17-2012 Planning and Status Meeting
= #heat Meeting = Meeting started by sdake at 21:12:34 UTC. http://heat-api.org/heat-irc-meetings/heat.2012-09-10-21.12.html Meeting summary --- * rollcall (sdake, 21:14:15) * present sdake, shardy, shadower, stevebake, jpeeler (sdake, 21:15:32) * status of v6 release (sdake, 21:15:42) * slower here too (sdake, 21:16:02) * LINK: https://github.com/heat-api/heat/issues?milestone=7state=open (sdake, 21:16:33) * LINK: https://github.com/heat-api/heat/issues/240 (shadower, 21:16:55) * status of v6 release - 2 blocking bugs - automated test system failing (sdake, 21:27:10) * release notes for v6 review (sdake, 21:27:52) * LINK: http://fpaste.org/ADBn/ (jpeeler, 21:28:18) * v7 (sdake, 21:37:10) * LINK: http://fpaste.org/GdZ6/ (jpeeler, 21:39:58) * LINK: http://fpaste.org/xzeY/ (jpeeler, 21:41:41) * jpeeler's announcement release notes approved (sdake, 21:42:00) * ACTION: shardy to document using boto client on wiki https://github.com/heat-api/heat/wiki (sdake, 21:45:16) * LINK: https://github.com/heat-api/heat/wiki/Heat-CLI-Boto-migration--API-rework (shardy, 21:45:22) * major features of v7 - security improvements for cloudwatch, cloudwatch split into separate binary so it can scale at different rates then heat-engine, and os-specific orchestration API (sdake, 21:51:00) * open items (sdake, 21:51:43) * LINK: https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack (jpeeler, 21:56:22) Meeting ended at 21:59:51 UTC. Action Items * shardy to document using boto client on wiki https://github.com/heat-api/heat/wiki ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [heat] Meeting Minutes 2012/09/10
= #heat Meeting = Meeting started by sdake at 21:12:45 UTC. http://heat-api.org/heat-irc-meetings/heat.2012-09-10-21.12.html Meeting summary --- * rollcall (sdake, 21:14:29) * sdake, steveb_ slower shardy zaneb jpeeler present (sdake, 21:16:19) * heat-v6 (sdake, 21:16:33) * LINK: https://github.com/heat-api/heat/issues?milestone=7state=open (sdake, 21:17:12) * team voted to move v6 release to September 18th, 2012 (sdake, 21:23:56) * half-day incibuation miniconf at OpenStack Summit in San Diego (sdake, 21:43:44) * agenda item for summit - New Orchestration API from Zane (sdake, 21:54:19) * agenda item for summit - What CloudWatch is and how to make it a reality in OpenStack (sdake, 21:54:37) * agenda item for summit - heat roadmap feature open suggestions (sdake, 21:55:10) * agenda item for summit -overview of heat (sdake, 21:55:51) * open items (sdake, 21:56:52) Meeting ended at 22:07:24 UTC. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [heat] Heat 8-13-2012 Planning and Status Meeting
= #heat Meeting = Meeting started by asalkeld at 21:14:37 UTC. The full logs are available at heat/2012/heat.2012-08-13-21.14.log.html . The full logs are available at: http://heat-api.org/heat-irc-meetings/heat.2012-08-13-21.14.log.html All IRC meeting logs are available at: http://heat-api.org/irclogs.html Meeting summary --- * rollcall (sdake, 21:17:23) * zaneb, sdake, imain, asalkeld, shardy, funzo, jpeeler present (sdake, 21:18:30) * shadower present too (sdake, 21:19:07) * v6 additional features (sdake, 21:19:14) * shardy wrapped up openshift (sdake, 21:23:54) * ACTION: shardy working on initial cloudwatch improvements - to potentially merge into ceilometer later without much wasted effort (sdake, 21:25:38) * ACTION: zaneb help wrap up integration testing and start cracking on openstack orchestration rest api code (sdake, 21:26:11) * additional features from returning from pto devs - openstack rest orchestraition API and improved CloudWatch implementation (sdake, 21:28:10) * ACTION: slower to investigate s3 integration support with swift (sdake, 21:29:04) * 9/4 release target for v6 (sdake, 21:33:50) * zaneb to work on rest api for v6, sdake start sorting out quantum integration plans in v6, then v7 shardy,sdake,zaneb work on quantum vpc (sdake, 21:45:33) * open items (sdake, 21:45:53) * ACTION: sdake to find out how tempest expects test cases (sdake, 21:52:35) * LINK: https://github.com/openstack/tempest/ (asalkeld, 21:53:04) * unanimous vote to add tempest integration as roadmap item for future versions (sdake, 21:55:35) * as user base increases, add troubleshooting tips to troubleshooting wiki based upon user feedback (sdake, 21:58:49) Meeting ended at 22:06:14 UTC. Action Items * shardy working on initial cloudwatch improvements - to potentially merge into ceilometer later without much wasted effort * zaneb help wrap up integration testing and start cracking on openstack orchestration rest api code * slower to investigate s3 integration support with swift * sdake to find out how tempest expects test cases Action Items, by person --- * sdake * sdake to find out how tempest expects test cases * shardy * shardy working on initial cloudwatch improvements - to potentially merge into ceilometer later without much wasted effort * zaneb * zaneb help wrap up integration testing and start cracking on openstack orchestration rest api code * **UNASSIGNED** * slower to investigate s3 integration support with swift People Present (lines said) --- * sdake (134) * asalkeld (32) * zaneb (26) * shardy (24) * Slower (12) * jpeeler (7) * mheat-bot (5) * shadower (5) * russellb (2) * funzo (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ 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] VM High Availability and Floating IP
On 07/24/2012 09:52 AM, Alessandro Tagliapietra wrote: Thank you Jay, never read about that. Seems something like scalr/chef? WHich handles application and keeps a minimum number of vm running? The idea of keeping a minimum number of VMs running based upon VM load is called auto-scaling. We have added auto-scaling to our v5 release (which is targeted for July 30th). As far as puppet/chef integration goes, CloudFormation integrates well with both. For chef read: http://www.full360.com/blogs/integrating-aws-cloudformation-and-chef For puppet read: https://s3.amazonaws.com/cloudformation-examples/IntegratingAWSCloudFormationWithPuppet.pdf Note while these links talk about AWS CloudFormation, Heat is essentially an AWS CloudFormation implementation for OpenStack. If you want to get started and give heat a try on Fedora 17+ or Ubuntu Precise, our getting started guides are in our wiki: https://github.com/heat-api/heat/wiki Let me know if you have follow-up questions. Regards -steve Best Alessandro Il giorno 24/lug/2012, alle ore 14:34, Jay Pipes ha scritto: On 07/24/2012 04:29 AM, Alessandro Tagliapietra wrote: Hi guys, i've 2 missing pieces in my HA openstack install. Actually all openstack services are managed by pacemaker and i can succesfully start/stop vm etc. when the cloud controller is down (i've only 2 servers atm). 1 - how can i make a VM HA? Actually live-migration works fine, but if a host goes down, how can i restart the vm on the other host? Should i edit the 'host' column in the db and issue the restart of the vm? Any other way? Check out that HEAT API: https://github.com/heat-api/heat/wiki/ 2 - i've the servers hosted at Hetzner, for floating ip we've bought failover ip which are assigned to each host and can be changed via the api. So i have to make sure that if vm is on host1, floating ip associated to the vm is routed to host1. My idea was to run a job that checks the floating ip already associated to any vm, then queries the vm info, checks on which host it's running and if it's different from the other check, calls the hetzner api to switch the ip to the other server. Any other idea? See above :) Best, -jay Thanks in advance Best Regards -- Alessandro Tagliapietra | VISup srl piazza 4 novembre 7 20124 Milano http://www.visup.it ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] nova-network and corosync
On 07/18/2012 03:50 AM, Alessandro Tagliapietra wrote: Hello, i've 2 machines, running ubuntu 12.04, i've installed corosync + pacemaker and it was working fine. Corosync is using eth1 with 10.8.0.1 and 10.8.0.2 as ip of the hosts, i've got keystone, glance, nova api-cert-scheduler, mysql, rabbitmq working in HA with pacemaker. The problem comes after installing nova-network and nova-compute, i've used this nova.conf: http://pastie.org/private/ddwva8kvaypqrxk7rifvba and after nova-compute started and hosts rebooted i can't get to work corosync, the problem seems that when hosts send packets in eth1 to multicast address, the source ip is the public one, not the 10.8.0.x one. After disabling nova-network on boot everything works. I've also tried to create a virtual eth2 device and set flat_interface to eth2, but it seems that still nova-network break the configuration as corosync still uses public ip for private lan. Any idea? Corosync goes to great pains to route packets across the interface identified in the corosync.conf file. If you are using a subnet definition ie: bindnetaddr: 10.8.0.0, it may be that the interface's netmask is causing a rebind to the new interface when nova network starts. One way to force binding to a specific interface when your network is not configured in a typical fashion is to identify the bindnetaddr exactly: ie: bindnetaddr: 10.8.0.1 Regards -steve Best Regards -- Alessandro Tagliapietra | VISup srl piazza 4 novembre 7 20124 Milano http://www.visup.it ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] HA inside VMs (via Corosync/Pacemaker)
On 06/30/2012 06:32 AM, Christian Parpart wrote: On Sat, Jun 30, 2012 at 1:51 PM, Narayan Desai narayan.de...@gmail.com mailto:narayan.de...@gmail.com wrote: On Sat, Jun 30, 2012 at 3:06 AM, Christian Parpart tra...@gmail.com mailto:tra...@gmail.com wrote: Hm, Pacemaker/Corosync *inside* the VM will add the Service-IP to the local ethernet interface, and thus, the outside OpenStack components do not know about. Using a dedicated floating IP pool for service IPs might feel like a great solution, but OpenStack is not the one to manage who gets what IP - but Corosync/Pacemaker inside the KVM instances. :-) Anyone an idea how to solve this? It sounds like you want to add explicit support to pacemaker to deal with openstack fixed addresses. Then you could run with rfc1918 floating addresses, and then have pacemaker/corosync reassign the (external) fixed address when consensus changes. Think of the openstack fixed address control plane in a similar way to ifconfig. You should even be able to script it up yourself; you'd need to add your openstack creds to the HA images though. Hey, that's a really great idea, and IMHO apparently the only way to not interfere with OpenStack internals too much. So I need to create a new resource agent that represents a floating IP. If I succeed, I'll share that script then. :) Cheers, Christian Parpart. Another option is to give Heat's High Availability a spin. Heat is made specifically for OpenStack cloud environments (vs corosync/pacemaker being specifically made for bare metal Linux environments). See http://www.heat-api.org Heat originates from the same authors as Corosync and much of the cluster stack internals on Linux - so the high availability developer experience that went into creating the software is equivalent. For more details on Heat's HA see: https://github.com/heat-api/heat/wiki/Using-HA An example VM image template that describes HA: https://github.com/heat-api/heat/blob/master/templates/WordPress_Single_Instance_With_HA.template ___ 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] Floating IPs don't get dissociated after delete
On 05/09/2012 07:20 AM, Bilel Msekni wrote: Hi , I am having this problem just like many others. Each time I delete a VM, the floating IP doesn't get automatically dissociated, has anyone encountred this problem and solved it ? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Bilel, We had this problem in openstack during our floating ip implementation of heat (http://www.heat-api.org). We solved it by using the floating ip.delete api in nova. See: https://github.com/heat-api/heat/blob/master/heat/engine/eip.py line 118 The program flow on delete is: delete an instance wait for instance to disappear delete floating ip Regards -steve ___ 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] Instances can't access eachother via external (floating) ips?
On 04/25/2012 01:03 PM, Calvin Walton wrote: On Mon, 2012-04-23 at 06:45 -0700, Mike Scherbakov wrote: Hi Calvin, Sorry I didn't respond earlier, the email temporarily got lost :) show us iptables -nL -t nat | grep NAT on the node with nova-network. (192.168.0.101 is the nova-network node's external address) DNAT all -- 0.0.0.0/0192.168.0.33to:192.168.22.35 DNAT all -- 0.0.0.0/0192.168.0.88 to:192.168.22.41 ACCEPT all -- 192.168.22.32/27 192.168.22.32/27 ! ctstate DNAT DNAT tcp -- 0.0.0.0/0169.254.169.254 tcp dpt:80 to:192.168.0.101:8775 DNAT all -- 0.0.0.0/0192.168.0.33 to:192.168.22.35 DNAT all -- 0.0.0.0/0192.168.0.88 to:192.168.22.41 SNAT all -- 192.168.22.350.0.0.0/0to:192.168.0.33 SNAT all -- 192.168.22.410.0.0.0/0to:192.168.0.88 SNAT all -- 192.168.22.32/27 0.0.0.0/0to:192.168.0.101 Note that the nova-network is actually colocated on a machine that also runs nova-compute; this is a small 2-node lab deployment. Could it be that your fixed_range flag in nova.conf covers both subnets, like 192.168.0.0/16 ? My fixed_range is very small, and doesn't overlap: --fixed_range=192.168.22.32/27 Second reason - I presume that the traffic from VM will go via your router if you access another VM via floating IP, so router should know the route to 192.168.0.x (static/ospf?) 192.168.0.x is the office network, and communication between other machines on that network and the router on that network all work fine. In the course of trying some other things out, I found that when I enabled ipv4 forwarding on the nova-network box: echo 1 /proc/sys/net/ipv4/ip_forward Then the virtual machines /were/ able to communicate with each-other via their floating IP addresses. I'm still not sure about what's going on, but it's good enough for our lab use now. In lab environments where openstack network isn't routed, you will need some special magic. Linux iptables doesn't allow a nat through a nat. Read more details here: https://github.com/heat-api/heat/wiki/Configuring-Floating-IPs Regards, On Fri, Apr 20, 2012 at 7:03 AM, Calvin Walton calvin.wal...@kepstin.ca wrote: Hi, I have instances running in Openstack using FlatDHCP networking mode. Each one has an IP address in the internal subnet (192.168.22.x) and a floating IP from the external subnet (192.168.0.x). I've found that from one instance, I cannot connect to another instance (or, in fact, even the same instance) via the external floating address (I have some monitoring tools that attempt to do this to verify that a server is running). Connections from external computers work fine. My best guess is that there is an issue with the NAT on my nova-network node not allowing loopback connections. Is this intentional, or a bug? Is there a workaround available? For reference, I'm currently using OpenStack from the 'latest-milestone-test' OpenStack PPA on Ubuntu 12.04 Precise. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Heat API v2 released!
Hi, Heat is a AWS CloudForm API implementation for OpenStack. The purpose of the software is to orchestrate resources (including virtual machines, networks, storage) into a running cloud application. The software converts an AWS template into native OpenStack API calls and provides a REST API to access the template (called a stack). Our development community has been busy over the last 3 weeks working on our second release. New in this release is: + composite instance support + floating IP support + security group support + volume support + improved keystone authentication + sqlalchemy database support + amqp engine support + describe API implementation + events_list API implementation + improved delete API implementation + better JEOS security + cfn tools implementation + Improved template library examples We have also started working on a roadmap. If your interested in seeing our roadmap work, check out: https://github.com/heat-api/heat/wiki To get started with the code check out: https://github.com/heat-api/heat/wiki/Getting-Started-with-Heat-v2-M1 And download the tag from here: https://github.com/heat-api/heat/tarball/v2-M1.release If you want to contribute to the software or are having trouble getting started, join us on #heat on freenode irc or our mailing list at http://ists.heat-api.org/mailman/listinfo Regards -steve ___ 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] Metadata and File Injection (code summit session?)
On 04/10/2012 12:36 PM, Andrew Bogott wrote: What I crave is a communication channel between nova and running instances. There was discussion at some point about extending the metadata api to have this ability. Having a solid config drive standard seems like a good idea, but it won't get me run-time interaction, will it? -Andrew +1 Having the ability to read config data from a runtime changeable metadata server (rather then a config file on an injected disk) serves a use case I am interested in. The only problem is horizontal scalability of the metadata server in this model which may not be a problem with some tinkering. Regards -steve On 4/10/12 11:40 AM, Eric Windisch wrote: I maintain my stance from pre-Diablo, that the configuration drive should be exported as a virtual cdrom device with an ISO9660 filesystem. We can generate the filesystem without root access and the filesystem is well-supported. Additionally, it lacks the patent-related issues associated with the other many-platform filesystems (i.e. FAT). Also, doing the above happens to make the configuration-drive surprisingly similar to the optional sub-feature of OVF. I'm not sure what priority OVF is for Nova (it is a low priority for me), but it might be worth considering, especially since Glance seems to advertise some OVF support. -- Eric Windisch On Tuesday, April 10, 2012 at 11:52 AM, Scott Moser wrote: On Tue, 10 Apr 2012, Andrew Bogott wrote: I'm reviving this ancient thread to ask: Will there be a code summit session about this? And/or are there plans to start developing a standard set of guest agents for Folsom? http://summit.openstack.org/sessions/view/100 ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack 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] Announcing project Heat
On 04/10/2012 10:19 AM, Justin Santa Barbara wrote: Congratulations on your project! Just to clarify, PlatformLayer can run anything as a service, not just databases. I added support for running memcache as a service last night, and Zookeeper clusters on Sunday... I think RedDwarf is also moving away from just supporting DBs. A crowded space indeed! :-) While a bit crowded, the heat project intends to deliver AWS CloudFormations APIs (and perhaps Tosca or other relevant standards down the road) rather then reinvent devops toolchains which are already done well with puppet/chef/etc. Don't know of any project handling the AWS CloudFormations API objective. Regards -steve Justin On Tue, Apr 10, 2012 at 5:41 AM, Angus Salkeld asalk...@redhat.com mailto:asalk...@redhat.com wrote: Hi I'd like to announce a new project that we have been working on, we have named it Heat (heat raises the clouds:). Our goal is to make it possible to manage multiple instance cloud applications with one template/specification file. Initially we want to implement as much as we can of the AWS CloudFormation API and later look at other API like TOSCA. We are attempting to write this in the style of an openstack project so as many people as possible can help out (come join in!). I know this is a busy topic area with several other interesting projects like Burrow, Donabe, Kanyun, Dough, Reddwarf and PlatformLayer. My hope is there we can form an exciting community at this layer and integrate where it makes sense. For instance many of the above projects implement (or could) some of the AWS resource types [1]. Some things that could be done together: - monitoring (Kanyun) and using the results to provide auto scaling. - AWS::SQS::Queue (Burrow) - AWS::RDS::DBInstance (Reddwarf/PlatformLayer) Unfortunately I won't be at the summit but Mark McLoughlin will give a lightening talk about it. Our project pages: http://heat-api.org/ http://wiki.openstack.org/Heat https://github.com/heat-api/heat Drop in at #heat on freenode or email our mailing list (http://lists.heat-api.org/mailman/listinfo). Regards Angus Salkeld [1] http://docs.amazonwebservices.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto: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] Metadata and File Injection (code summit session?)
On 04/10/2012 03:04 PM, Justin Santa Barbara wrote: Having the ability to read config data from a runtime changeable metadata server (rather then a config file on an injected disk) serves a use case I am interested in. The only problem is horizontal scalability of the metadata server in this model which may not be a problem with some tinkering. Can you please share that use case? I'm especially interested in finding use cases that would not better be better served by e.g. SSH or Zookeeper or Corosync.. Sure The exact use case is to support updating configurations of running systems without installing a specific SSH key or requiring SSH at all. Here is how it would work: developer wants to tell the vm about 3 pieces of updated information 1) developer uses metadata set api to set key/value pairs for 3 pieces of information 2) VM can then read these metadata blobs at its leisure There are a few alternatives for runtime configurable data that are simple: 1) use ssh - this is a good model, but has a few constraints. First a key has to be loaded into the VM that the orchestration system knows about. Second, ssh has to be used over the network, which creates some problems for some security people for pragmatic reasons (how do we get SSH over VPNs), and less rationale reasoning (ie: ssh is evil, etc). or 2) each service ends up implementing its own dynamic metadata server You mentioned zookeeper or corosync. those are big deps to pull in simply to get runtime configurable metadata. If they have other uses, that may make sense but simply extending the metadata server seems fairly simple. Option 2 would work but why have 10 of something when a common component would do the job. Cheers -steve ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack Foundation] Orchestration with Openstack
On 03/26/2012 03:58 AM, Andiabes wrote: (switching to the openstack list, the foundation list is meant for the organization of the openstack foundation) There are some efforts around using Chef from opscode, and tools built around it to do what I think you describe - look in the mailing list archive ( which is also a good way to identify the right list to use) On Mar 26, 2012, at 4:26 AM, Rahul Bhardwaj bhardwaj.rahu...@gmail.com wrote: I am new to this list so not sure about the relevance of question, forum or discusstion topic. I apologize if there is mismatch anywhere above. I was wondering about the possible ways of getting VM provisioning activity defined as a workflow and than managing it using the orchestrator. I have tried mCollective and celery but none worked. I was thinking, will Puppet+mCollective do the trick or maybe one of the opensource tools such as orchestra or archipel can be used to automate the workflow. Looking for some suggestions. -Rahul Rahul, A couple of folks are on implementing AWS CloudFormations. This system takes a template and turns it into a running set of VMs. It may not meet your requirement of working since we just started development a few weeks ago. If you want to have a look: https://github.com/heat-api Note our diagrams are a bit out of date - might check my github account for those. Regards -steve ___ Foundation mailing list foundat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation ___ 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
