Re: [Openstack] [HEAT] orchestration on multiple external Cloud providers
On 07/11/2013 10:04 PM, Geoffroy wrote: I am trying to use Heat as an provisioning tool on multiple Cloud providers, lets say HpCloud and Rackspace. I got local keystone, heat-api and heat-engine servers. My scenario is: if i submit a template with 2 compute instances, i want them to be distributed on each providers. It's a little difficult, because heat-engine reuses my local keystone to retrieve the endpoint and credentials, which are different for each external providers. My guess was to use the Environment to store every external credentials in the parameters, and precise in the resource_registry a binding for every instances: parameters: HpCloudUserName: foo HpCloudPassword: foo HpCloudAuthUrl: http://foo.org RackspaceUserName: bar RackspacePassword: bar RackspaceAuthUrl: http://bar.org resource_registry: resources: my_instance_1: AWS::EC2::Instance : HpCloud::Nova::Compute my_instance_2: AWS::EC2::Instance : Rackspace::Compute::Server Then, i code some new python plugins, that will handle this 2 new type, take the corresponding credentials in the environment, and call the novaclient with the correct arguments. But my problem is that this solution seems overkill, as i will have to add a new python class for every type i want to use, multiply by the number of externals providers. Even if i can factorize the code, in the end i just want to customize the credentials and auth endpoint. Do you known if there is a better way to achieve this goal, or simply if Heat shouldn't be use for this ?. There are a few interim steps required before we can handle your scenario of multiple clouds in a single template. The first steps are to change API middleware behaviour to not assume heat is installed in a single integrated openstack: https://blueprints.launchpad.net/heat/+spec/heat-standalone https://blueprints.launchpad.net/heat/+spec/heat-multicloud When they are ready, the HOT template concepts of Environments and Providers should allow you to implement your HpCloud::Nova::Compute and Rackspace::Compute::Server as nested stacks so you won't need to code these in python. ___ 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] heat engine: list index out of range
Hi Pekka
I've raised https://bugs.launchpad.net/heat/+bug/1192371 to track this.
Could you attempt to replicate the issue with current heat git master
and post your results to the bug?
cheers
On 06/18/2013 11:02 PM, Pekka Rinne wrote:
hello world
I've got a template which gives list index out of range occasionally
from heat (grizzly). Any ideas why? sometimes it works ok. Some kind
of race situation? I'm just trying to learn quantum usage here..
2013-06-18 18:52:02.585 27948 ERROR heat.engine.resource [-] create
Instance inst1
2013-06-18 18:52:02.585 27948 TRACE heat.engine.resource Traceback
(most recent call last):
2013-06-18 18:52:02.585 27948 TRACE heat.engine.resource File
/usr/local/lib/python2.7/dist-packages/heat-2013.1.1.a1.g6ed78c2-py2.7.egg/heat/engine/resource.py,
line 321, in create
2013-06-18 18:52:02.585 27948 TRACE heat.engine.resource while not
self.check_active():
2013-06-18 18:52:02.585 27948 TRACE heat.engine.resource File
/usr/local/lib/python2.7/dist-packages/heat-2013.1.1.a1.g6ed78c2-py2.7.egg/heat/engine/resources/instance.py,
line 325, in check_active
2013-06-18 18:52:02.585 27948 TRACE heat.engine.resource
self._set_ipaddress(server.networks)
2013-06-18 18:52:02.585 27948 TRACE heat.engine.resource File
/usr/local/lib/python2.7/dist-packages/heat-2013.1.1.a1.g6ed78c2-py2.7.egg/heat/engine/resources/instance.py,
line 125, in _set_ipaddress
2013-06-18 18:52:02.585 27948 TRACE heat.engine.resource
self.ipaddress = networks[n][0]
2013-06-18 18:52:02.585 27948 TRACE heat.engine.resource IndexError:
list index out of range
{
AWSTemplateFormatVersion : 2010-09-09,
Description : tbd,
Parameters : {
KeyName : {
Description : Keydescription,
Type : String
},
InstanceType : {
Description : Instancetype,
Type : String,
Default : m1.small,
AllowedValues : [ m1.small ],
ConstraintDescription : must be a valid EC2 instance type.
},
MyDistribution: {
Default: MyDistro,
Description : Distribution of mine,
Type: String,
AllowedValues : [ MyDistro ]
}
},
Mappings : {
AWSInstanceType2Arch : {
m1.small: { Arch : 64 }
},
DistroArch2AMI: {
MyDistro : { 64 : ubuntu1304-amd64 }
}
},
Resources : {
network1: {
Type: OS::Quantum::Net
},
network2: {
Type: OS::Quantum::Net
},
mgmt-subnet: {
Type: OS::Quantum::Subnet,
Properties: {
network_id: { Ref : network1 },
ip_version: 4,
cidr: 30.0.1.0/24 http://30.0.1.0/24,
gateway_ip: 30.0.1.1,
allocation_pools: [{start: 30.0.1.2, end: 30.0.1.20}]
}
},
traffic-subnet: {
Type: OS::Quantum::Subnet,
Properties: {
network_id: { Ref : network2 },
ip_version: 4,
cidr: 40.0.1.0/24 http://40.0.1.0/24,
gateway_ip: 40.0.1.1,
allocation_pools: [{start: 40.0.1.2, end: 40.0.1.20}]
}
},
network1port1: {
Type: OS::Quantum::Port,
Properties: {
network_id: { Ref : network1 }
}
},
network1port2: {
Type: OS::Quantum::Port,
Properties: {
network_id: { Ref : network1 }
}
},
network2port1: {
Type: OS::Quantum::Port,
Properties: {
network_id: { Ref : network2 }
}
},
network2port2: {
Type: OS::Quantum::Port,
Properties: {
network_id: { Ref : network2 }
}
},
inst1: {
Type: AWS::EC2::Instance,
Metadata : {
AWS::CloudFormation::Init : {
}
},
Properties: {
ImageId : { Fn::FindInMap : [ DistroArch2AMI, { Ref :
MyDistribution },
{ Fn::FindInMap : [
AWSInstanceType2Arch, { Ref : InstanceType }, Arch ] } ] },
InstanceType : { Ref : InstanceType },
KeyName: { Ref : KeyName },
NetworkInterfaces : [
{ NetworkInterfaceId : { Ref : network1port1 },
DeviceIndex : 0 },
{ NetworkInterfaceId : { Ref : network2port1 },
DeviceIndex : 1 }
]
}
},
inst2: {
Type: AWS::EC2::Instance,
Metadata : {
AWS::CloudFormation::Init : {
}
},
Properties: {
ImageId : { Fn::FindInMap : [ DistroArch2AMI, { Ref :
MyDistribution },
{ Fn::FindInMap : [
AWSInstanceType2Arch, { Ref : InstanceType }, Arch ] } ] },
InstanceType : { Ref : InstanceType },
KeyName: { Ref : KeyName },
NetworkInterfaces : [
{ NetworkInterfaceId : { Ref : network1port2 },
DeviceIndex : 0 },
{ NetworkInterfaceId : { Ref : network2port2 },
DeviceIndex : 1 }
]
}
}
}
}
br,
Pekka
___
Mailing list:
[Openstack] Fwd: [openstack-dev] [Heat] Running latest Heat against older OpenStacks
Reposting here since this is mostly user related. Original Message Subject:[openstack-dev] [Heat] Running latest Heat against older OpenStacks Date: Wed, 22 May 2013 14:46:19 +1200 From: Steve Baker sba...@redhat.com Reply-To: OpenStack Development Mailing List openstack-...@lists.openstack.org To: openstack-...@lists.openstack.org At the Design Summit a number of people mentioned that they would like to run the latest release of Heat against their own installation of an older OpenStack release. As a project we're not against this in principle, however we don't currently have the resources to develop or test against anything other than latest OpenStack (unless by coincidence of the provided dev environment). It would be very useful to us for people to describe their use cases for running Heat against older OpenStack installations - feel free to contribute them to this thread. We're about to have the beginnings of some Tempest integration tests[1]. I'd like to suggest that these be used as a coordination point for testing latest Heat against private installations. For those running Heat against older OpenStack installations the following would be done: - Run the heat tempest tests against your own Heat/OpenStack environment - Participate in finding and fixing regressions that appear in your own environment (bug reports good, failing tempest tests better, fixes best) There are a couple of caveats worth mentioning: - the transition from our own CloudWatch-lite alarming to ceilometer might be messy - there might be a limit to how much we can mitigate the pain - it seems reasonable for latest heat to depend on the latest released client libs. Any regressions involving recent client libs running on older APIs probably need to be taken to those client projects. In the medium to long term we have some roadmap items which have implications here, including: - a local installation of Heat configured to point at a public OpenStack cloud - auth and other quirks of each cloud need to be handled - a single installation of Heat which can deploy to multiple clouds (private and public) - Heat DSL concepts [2] of Providers and Environments should allow Heat to change any aspect of its behavior to support older installations. [1] https://review.openstack.org/#/q/topic:bp/add-basic-heat-tests,n,z [2] https://wiki.openstack.org/wiki/Heat/DSL ___ 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] Heat templates and Quantum resources
Hi Simon
There is an existing Launchpad bug for this issue:
https://bugs.launchpad.net/heat/+bug/1096013
I've added your email to the comments. I'll most likely be working on
this area next so I'll let you know when there is a change in the
current behavior.
cheers
On 02/05/2013 10:40 PM, Simon Pasquier wrote:
Hi all,
I have some questions regarding the integration of Quantum in Heat:
- I haven't found a way to attach an instance resource to a Quantum
port that already exists. Is it possible?
- When I create a Quantum port in my template and binds the instance
to that port, why does Heat still create an additional port to the
tenant-owned network?
I have created a very simple template to test:
{
AWSTemplateFormatVersion : 2010-09-09,
Description : Test creation of Quantum resources with a very
simple instance,
Parameters : {
KeyName : {
Description : Name of an existing EC2 KeyPair to enable SSH
access to the instances,
Type : String
},
NetworkUuid : {
Description : Network UUID,
Type : String
},
SubnetUuid : {
Description : Network UUID,
Type : String
}
},
Resources : {
QuantumPort: {
Type: OS::Quantum::Port,
Properties: {
network_id: { Ref : NetworkUuid },
device_id: { Ref: CirrosInstance },
fixed_ips: [{
subnet_id: { Ref : SubnetUuid },
ip_address: 10.0.0.100
}]
}
},
DefaultSecurityGroup : {
Type : AWS::EC2::SecurityGroup,
Properties : {
GroupDescription : Enable ICMP plus SSH access,
SecurityGroupIngress : [
{IpProtocol : icmp, FromPort : -1, ToPort : -1,
CidrIp : 0.0.0.0/0 http://0.0.0.0/0},
{IpProtocol : tcp, FromPort : 22, ToPort : 22,
CidrIp : 0.0.0.0/0 http://0.0.0.0/0}
]
}
},
CirrosInstance: {
Type: AWS::EC2::Instance,
Properties: {
ImageId : cirros-0.3.0-x86_64-uec,
InstanceType : m1.nano,
KeyName: { Ref : KeyName },
SecurityGroups : [ {Ref : DefaultSecurityGroup} ]
}
}
},
Outputs : {
InstanceIPAddress : {
Value : { Fn::GetAtt : [CirrosInstance, PrivateIp] },
Description: Private IP address of the instance
}
}
}
For my tests, I use devstack and the Open vSwitch plugin. After the
stack is created, the instance is up and running but it is connected
to 2 ports:
$ heat stack-show cirros
+--+-+
| Property | Value
|
+--+-+
| capabilities | []
|
| creation_time| 2013-02-05T09:11:39Z
|
| description | Test creation of Quantum resources with a
very simple |
| | instance
|
| disable_rollback | True
|
| id | 8c161ed2-691e-42e8-a872-e90f26a83ac5
|
| links|
http://192.168.1.94:8004/v1/bc7d29521a444d59b1d68f1e0a81ce90/stacks/cirros/8c161ed2-691e-42e8-a872-e90f26a83ac5
|
| notification_topics | []
|
| outputs | [
|
| | {
|
| | output_value: 10.0.0.3,
|
| | description: Private IP address of the
instance,|
| | output_key: InstanceIPAddress
|
| | }
|
| | ]
Re: [Openstack] Will Heat Work Without systemd (i.e. will it work with init)?
On 12/05/2012 08:55 AM, Rickard, Ronald wrote:
I am attempting to install/configure Heat on RHEL 6.3. This server
already has other OpenStack (Essex release) products installed: nova,
glance, keystone, etc. I built the RPMs for Heat (v7) and Heat JEOS
(v7) by commenting out the requirements on systemd-units and the
systemd unit files in the heat.spec because RHEL 6.3 uses init instead
of systemd. I am thinking I can replace these systemd unit files with
init.d scripts to startup Heat. I installed the RPMs and am at the
step in the process where I am creating a JEOS with heat_jeos:
heat-jeos --y create F17-x86_64-cfntools --register-with-glance
It takes almost 10 minutes and I see activity in the /var/lib/oz/isos
and /var/lib/oz/isocontent directory, but eventually, I see the
following error:
Traceback (most recent call last):
File /usr/bin/heat-jeos, line 375, in module
main()
File /usr/bin/heat-jeos, line 363, in main
result = cmd(opts, args)
File /usr/bin/heat-jeos, line 139, in command_create
build_jeos(get_oz_guest(final_tdl))
File /usr/lib/python2.6/site-packages/heat_jeos/utils.py, line 132,
in build_jeos
guest.customize(libvirt_xml)
File /usr/lib/python2.6/site-packages/oz/RedHat.py, line 1166, in
customize
return self._internal_customize(libvirt_xml, no)
File /usr/lib/python2.6/site-packages/oz/RedHat.py, line 1150, in
_internal_customize
self.do_customize(guestaddr)
File /usr/lib/python2.6/site-packages/oz/RedHat.py, line 1104, in
do_customize
self.guest_execute_command(guestaddr, content)
File /usr/lib/python2.6/site-packages/oz/RedHat.py, line 474, in
guest_execute_command
command, timeout, tunnels)
File /usr/lib/python2.6/site-packages/oz/ozutil.py, line 362, in
ssh_execute_command
return subprocess_check_output(cmd)
File /usr/lib/python2.6/site-packages/oz/ozutil.py, line 329, in
subprocess_check_output
raise SubprocessException('%s' failed(%d): %s % (cmd, retcode,
stderr), retcode)
oz.ozutil.SubprocessException: 'ssh -i /etc/oz/id_rsa-icicle-gen -F
/dev/null -o ServerAliveInterval=30 -o StrictHostKeyChecking=no -o
ConnectTimeout=10 -o UserKnownHostsFile=/dev/null -o
PasswordAuthentication=no root@W.X.Y.Z yum -y update fedora-release
yum -y install yum-plugin-fastestmirror cloud-init python-psutil
python-boto
yum -y update
sed --in-place -e s/Type=oneshot/Type=oneshot\nTimeoutSec=0/
/lib/systemd/system/cloud-final.service' failed(2): Warning:
Permanently added 'W.X.Y.Z' (RSA) to the list of known hosts.
Error: Cannot retrieve metalink for repository: fedora. Please verify
its path and try again
Error: Cannot retrieve metalink for repository: fedora. Please verify
its path and try again
Error: Cannot retrieve metalink for repository: fedora. Please verify
its path and try again
sed: can't read /lib/systemd/system/cloud-final.service: No such file
or directory
We haven't tested image creation on RHEL 6.3. Most likely we'll focus on
RHEL 6.4 (when it is released) as our highest priority RHEL target.
Patches for any distro are welcome though.
You don't actually need to build your own images if the pre-built ones
meet your needs:
https://github.com/heat-api/prebuilt-jeos-images/downloads
Hopefully this can get you to the next phase of your evaluation. Let us
know if you have any more issues.
cheers
___
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] Heat's Getting started on Fedora 16+ Guide?
On 12/04/2012 08:26 AM, Rickard, Ronald wrote: Sometime over the weekend, the page for Heat's Getting start on Fedora 16+ guide disappeared. Will this page be returning? Our git repo was moved to the main OpenStack account over the weekend. The guide you want is now here: https://github.com/openstack/heat/blob/master/docs/GettingStarted.rst#readme I've just gone through our wiki pages and updated the URLs to any git content so hopefully the links are fixed now. cheers ___ 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] Will Heat Work Without systemd (i.e. will it work with init)?
On 12/04/2012 08:44 AM, Rickard, Ronald wrote: It appears Heat is being developed for OSes that support systemd. Will Heat also work on systems that use init? It is not our intention to only support systemd based distros. It would be most helpful if you could describe the details of your issues in our Launchpad: https://bugs.launchpad.net/heat or post them to this list. cheers ___ 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] Anyone using instance metadata?
On Thu, Jul 5, 2012 at 1:11 AM, Day, Phil philip@hp.com wrote: I'm getting lost in the naming of things here, it seems like we're saying: user-data is per instance data defined by the system and make accessible by the metadata service and meta-data is per instance data defined by the user via the API and injected into the instance or made available by the config drive Something in those definitions of meta-data and user-data just seems confusing to me ;-) Actually its worse than that, instance metadata is currently the label for two completely unrelated things in OpenStack, and knowing which one is being referred to seems to depend entirely on the context :) user-data is a chunk of data that can be set when an instance is not running and is accessible from within the instance when it is running. It could be used to store configuration, a script, or anything the tenant wants. In Nova, instance meta-data is a collection of key/value pairs associated to an instance. They can be read and written to at any time during the instance lifetime, from inside and outside the instance using the nova compute API (and eventually EC2 API, Horizon, etc). A snapshot of the instance meta-data at instance startup is made available by the config drive (but maybe it shouldn't?). Amazon calls this feature Tags; EC2 can associate tags to a number of resource types including instances. http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_API Here is where it gets confusing, the Metadata service gives a running instance a convenient way of fetching the user-data, plus other meta data about the current running instance. People often also refer to this as instance meta-data, but you cannot query the instance associated key/value pairs via the metadata service. http://docs.openstack.org/essex/openstack-compute/admin/content/metadata-service.html To fix this semantic clash I would advocate adopting Amazon's Tags terminology but I won't be pushing this too hard since I'm new here ;) cheers ___ 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] Anyone using instance metadata?
Hi Vish On Wed, Jul 4, 2012 at 6:28 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: Metadata is supposed to be user tags that are associated with a guest that are available via the api. We discussed displaying these tags inside the guest as well. I've just been looking into what is already in place to implement the CreateTags, DeleteTags, DescribeTags API and I also came across the *_instance_metadata compute API. http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_API The tags API can add tags to a number of resource types, but currently there only seems to be a metadata tables for instances and volumes. Would there be interest in me working on a change to implement CreateTags, DeleteTags, DescribeTags for instances and volumes? Later changes could add new metadata tables for the other taggable resource types. cheers ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
