Re: [Openstack-operators] Migration Openstack Instances and cloud-init
Hi Hamza, thank you for your answere. So I have to comment out the modules i don't want to run when I understand this right? Why are the changes made to the instance when I start a snapshot of the instance and not every time when I start the instance itself? What event triggers the cloud-init to make this changes? What would happen when I remove the cloud-init package, will the instance still be working and what disadventages would I have then? Thank you and kind regards, Michael > Achi Hamza hat am 2. Juli 2016 um 14:30 geschrieben: > > Hi Michael, > > You can change this behavior in the /etc/cloud/cloud.cfg config file. > > Regards, > Hamza > > On 1 July 2016 at 07:02, Michael Stang mailto:michael.st...@dhbw-mannheim.de > wrote: >> >Hi all, > > > >I tried to copy instances (based on the ubuntu cloud image) from our > > production cloud to our test cloud according to this description > > > > > > > > http://docs.openstack.org/user-guide/cli_use_snapshots_to_migrate_instances.html > > > >but when I start the instance on the test cloud the root password ist > > resetet and it seems that the cloud-init is invoked and change the instance > > like it is the first start. Is there a way to prevent this behaviour so the > > instance stays unchanged when I start it on the test cloud? > > > >Thanks and kind regards, > >Michael > > > >___ > >OpenStack-operators mailing list > >OpenStack-operators@lists.openstack.org > > mailto:OpenStack-operators@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > Viele Grüße Michael Stang Laboringenieur, Dipl. Inf. (FH) Duale Hochschule Baden-Württemberg Mannheim Baden-Wuerttemberg Cooperative State University Mannheim ZeMath Zentrum für mathematisch-naturwissenschaftliches Basiswissen Fachbereich Informatik, Fakultät Technik Coblitzallee 1-9 68163 Mannheim Tel.: +49 (0)621 4105 - 1367 michael.st...@dhbw-mannheim.de http://www.dhbw-mannheim.de___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] Fail build request if we can't inject files?
On Sun, Jul 03, 2016 at 10:08:04AM -0500, Matt Riedemann wrote: > I want to use the gate-tempest-dsvm-neutron-full-ssh in nova since it runs > ssh validation + neutron + config drive + metadata service, which will test > the virtual device tagging 2.32 microversion API (added last week). > > The job has a file injection test that fails consistently which is keeping > it from being voting. > > After debugging, the problem is the files to inject are silently ignored > because n-cpu is configured with libvirt.inject_partition=-2 by default. > That disables file injection: > > https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030 > > We don't even log a warning if the user requested files to inject and we > can't honor it. If I were a user and tried to inject files when creating a > server but they didn't show up in the guest, I'd open a support ticket > against my cloud provider. So I don't think a warning (that only the admin > sees) is sufficient here. This isn't something that's discoverable from the > API either, it's really host configuration / capability (something we still > need to tackle). Won't the user provided files also get made available by the config drive / metadata service ? I think that's the primary reason for file injection not being a fatal problem. Oh that and the fact that we've wanted to kill it for at least 3 years now :-) Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [nova] Fail build request if we can't inject files?
Hi all, > Won't the user provided files also get made available by the config drive / > metadata service ? I believe, they should. Not sure it's the same problem, so just FYI: we recently encountered an issue with VFAT formatted config drives when nova-compute is deployed on CentOS or RHEL: https://bugs.launchpad.net/cirros/+bug/1598783 https://bugs.launchpad.net/mos/+bug/1587960 Thanks, Roman ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] Fail build request if we can't inject files?
On 7/4/2016 3:40 AM, Daniel P. Berrange wrote: Won't the user provided files also get made available by the config drive / metadata service ? I think that's the primary reason for file injection not being a fatal problem. Oh that and the fact that we've wanted to kill it for at least 3 years now :-) Regards, Daniel Ugh, good point, except force_config_drive defaults to False and running the metadata service is optional. In the case of this failing in the tempest-dsvm-neutron-full-ssh job, the instance is not created with a config drive, but the metadata service is running. Tempest doesn't check for the files there though because it's configured to expect file injection to work, so it ssh's into the guest and looks for the files. I have several changes up related to this: https://review.openstack.org/#/q/topic:bug/1598581 One is making Tempest disable file injection tests by default since Nova disables file injection by default (at least for the libvirt driver). Another is changing devstack to actually configure nova/tempest for file injection which is what the job should have been doing anyway. My nova fix is not going to fly because of config drive (which I could check from the virt driver) and the metadata service (which I can't from the virt driver). So I guess the best we can do is log something... -- Thanks, Matt Riedemann ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [gnocchi] profiling and benchmarking 2.1.x
hi folks, i didn't get as far as i'd hope so i've decided to release what i have currently and create another deck for more 'future enhancements' benchmarking. the following deck aims to show how performance changes as you scale out Ceph and some configuration options that can help stabilise Gnocchi+Ceph performance: http://www.slideshare.net/GordonChung/gnocchi-profiling-v2. this is by no means a large scale architecture -- the tests are run against tens of thousands metrics currently -- but it's a start until we get more data. i'm hoping to test against a larger dataset going forward. also, will be testing some enhancements we've been discussing for Gnocchi 3.x hope it helps. cheers, On 25/06/2016 8:50 AM, Curtis wrote: > On Fri, Jun 24, 2016 at 2:09 PM, gordon chung wrote: >> hi, >> >> i realised i didn't post this beyond IRC, so here are some initial >> numbers for some performance/benchmarking i did on Gnocchi. >> >> http://www.slideshare.net/GordonChung/gnocchi-profiling-21x >> >> as a headsup, the data above is using Ceph and with pretty much a >> default configuration. i'm currently doing more tests to see how it >> works if you actually start turning some knobs on Ceph (spoiler: it gets >> better). > > Thanks Gordon. I will definitely take a look through your slides. > Looking forward to what test results you get when you start turning > some knobs. > > Thanks, > Curtis. > >> >> cheers, >> >> -- >> gord >> ___ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > -- gord ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Quota exceeded for resources: ['security_group'].
hi everyone,
when i create cluster:
openstack dataprocessing cluster create --json my_cluster_create_vmdk.json
with??
sudo vim my_worker_template_create_vmdk.json
{
"plugin_name": "vanilla-vmdk",
"hadoop_version": "2.7.1",
"node_processes": [
"nodemanager",
"datanode"
],
"name": "vanilla-vmdk-worker",
"floating_ip_pool": "public",
"flavor_id": "2",
"auto_security_group": true
}
sudo vim my_master_template_create_vmdk.json
{
"plugin_name": "vanilla",
"hadoop_version": "2.7.1",
"node_processes": [
"namenode",
"resourcemanager"
],
"name": "vanilla-vmdk-master",
"floating_ip_pool": "public",
"flavor_id": "2",
"auto_security_group": true
}
it is error in sahara.log:
2016-07-05 11:37:08.427 45905 DEBUG heatclient.common.http
[req-83467fbd-ca47-42eb-9988-5b138df783c9 7fff70fbbf83441a9b3c4d91a5613825
6cb156a82d0f486a9f50132be9438eb6 - - -] [instance: none, cluster:
0271f779-0900-456b-a34f-a951f77e3114] curl -g -i -X POST -H 'Accept:
application/json' -H 'User-Agent: python-heatclient' -H 'Content-Type:
application/json' -H 'X-Auth-User: sahara' -H 'X-Auth-Token:
{SHA1}9ffea1e4748e333888f830a439074ebfa6c0513d' -d '{"files":
{"file://master.yaml": "description: 'Data Processing Cluster by Sahara\n\n
Sahara cluster name: my-cluster-vmdk-2\n\n Sahara engine: heat.3.0\n\n Node
group master'\nheat_template_version: '2013-05-23'\noutputs:\n instance:\n
value:\n name:\nget_attr: [inst, name]\n physical_id:
{get_resource: inst}\nparameters:\n instance_index: {type:
string}\nresources:\n floating_ip:\nproperties: {pool: public}\ntype:
OS::Nova::FloatingIP\n floating_ip_assoc:\nproperties:\n floating_ip:
{get_resource: floating_ip}\n server_id: {get_resource: inst}\ntype:
OS::Nova::FloatingIPAssociation\n inst:\nproperties:\n admin_user:
sahara\n flavor: '2'\n image: 3355bf5d-798f-4f50-b83c-daa417fe4189\n
key_name: my_stack\n name:\nlist_join:\n- '-'\n
- - my-cluster-vmdk-2\n - master\n - {get_param:
instance_index}\n security_groups:\n - {get_resource:
my-cluster-vmdk-2-master-ef810b61}\n user_data:\nstr_replace:\n
params:\nwc_notify:\n get_attr:
[master-wc-handle, curl_cli]\n template: \"#!/bin/bash\\necho
\\\"ssh-rsa
B3NzaC1yc2EDAQABAAABAQC/DWL+Mq3JV3LU6PvFowPIJSeu2BTCTNi1gUScGd7f15ykQzisczg0upM5Xd12uVqIGgPmC7grB2LTxL2T7Kqe9GOyqZskgff18YjCBCWRpsdWqmnQVQGpGvfYHPgvWxUPc+3Cu60JBWe775w5AFrBbZCRHE/dgrvhgXxJUUnkmxrTgf4oEc+sEq8o0s7s5ro4wOrT6Fqeo5QkDYMkKkGqBL41NGQrRQnuY8HwT64u9ZY6aoqHYkRDVwJManpemauwpuRywooP0fiQPy5lxNZYCko6KEUpzm7zlP4NTirEEeZxKgFaF0WE70BbJQVi5r3IsQTd0IdIW05I3TvOw6J5\\\n
\\ Generated-by-Sahara\\n\\\" >>
/home/sahara//.ssh/authorized_keys\\n\\n# ==\\\n\\ COMMENT OUT
Defaults requiretty in /etc/sudoers \\nsed '/^Defaults\\\n
\\requiretty*/ s/^/#/' -i /etc/sudoers\\n\\n\\n\\nwhile true; do\\n
wc_notify\\\n\\ --insecure --data-binary '{\\\"status\\\":
\\\"SUCCESS\\\"}'\\nif [ $? -eq\\\n\\ 0 ]; then\\n
break\\nfi\\nsleep 10\\ndone\\n\"\ntype: OS::Nova::Server\n
master-wc-handle: {type: 'OS::Heat::WaitConditionHandle'}\n
master-wc-waiter:\ndepends_on: inst\nproperties:\n handle:
{get_resource: master-wc-handle}\n timeout: 3600\ntype:
OS::Heat::WaitCondition\n my-cluster-vmdk-2-master-ef810b61:\n
properties:\n GroupDescription: 'Data Processing Cluster by Sahara\n\n
Sahara cluster name: my-cluster-vmdk-2\n\nSahara engine:
heat.3.0\n\nAuto security group for Sahara Node Group: master'\n
SecurityGroupIngress:\n - {CidrIp: 0.0.0.0/0, FromPort: '8088',
IpProtocol: tcp, ToPort: '8088'}\n - {CidrIp: '::/0', FromPort: '8088',
IpProtocol: tcp, ToPort: '8088'}\n - {CidrIp: 0.0.0.0/0, FromPort: '8032',
IpProtocol: tcp, ToPort: '8032'}\n - {CidrIp: '::/0', FromPort: '8032',
IpProtocol: tcp, ToPort: '8032'}\n - {CidrIp: 0.0.0.0/0, FromPort:
'50070', IpProtocol: tcp, ToPort: '50070'}\n - {CidrIp: '::/0', FromPort:
'50070', IpProtocol: tcp, ToPort: '50070'}\n - {CidrIp: 0.0.0.0/0,
FromPort: '9000', IpProtocol: tcp, ToPort: '9000'}\n - {CidrIp: '::/0',
FromPort: '9000', IpProtocol: tcp, ToPort: '9000'}\n - {CidrIp: 0.0.0.0/0,
FromPort: '22', IpProtocol: tcp, ToPort: '22'}\n - {CidrIp: '::/0',
FromPort: '22', IpProtocol: tcp, ToPort: '22'}\ntype:
AWS::EC2::SecurityGroup\n", "file://worker.yaml": "description: 'Data
Processing Cluster by Sahara\n\n Sahara cluster name: my-cluster-vmdk-2\n\n
Sahara engine: heat.3.0\n\n Node group worker'\nheat_template_version:
'2013-05-2
Re: [Openstack-operators] Quota exceeded for resources: ['security_group'].
Hello, Le 05/07/2016 06:02, 云淡风轻 a écrit : when i create cluster: openstack dataprocessing cluster create --json my_cluster_create_vmdk.json [...] How to deal it ,thanks ! Look at the actual quotas: $ nova quota-show | grep security_group | security_groups | 10| | security_group_rules| 20| Then grow them a bit: $ nova quota-update --security-groups 11 --security-group-rules 21 There's the equivalent unified client (openstack) commands, should be easy to find Hope this helps -- Vincent Legoll EGI FedCloud task force Cloud Computing at IdGC France Grilles / CNRS / IPHC ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
