[Openstack-operators] [openstack-dev] [openstack-operators] [qa] [berlin] QA Team & related sessions at berlin summit

2018-11-08 Thread Ghanshyam Mann
Hello everyone,

Along with project updates & onboarding sessions, QA team will host QA feedback 
sessions in berlin summit.  Feel free to catch us next week for any QA related 
questions or if you need help to contribute in QA (we are really looking 
forward to onbaord new contributor in QA). 

Below are the QA related sessions, feel free to append the list if i missed 
anything. I am working on onboarding/forum sessions etherpad and will send the 
link tomorrow. 

Tuesday:
  1. OpenStack QA - Project Update.   [1]
  2. OpenStack QA - Project Onboarding.   [2]
  3. OpenStack Patrole – Foolproofing your OpenStack Deployment [3]

Wednesday:
  4. Forum: Users / Operators adoption of QA tools / plugins.  [4]

Thursday:
  5. Using Rally/Tempest for change validation (OPS session) [5]

[1] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22763/openstack-qa-project-update
 
[2] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22762/openstack-qa-project-onboarding
[3] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22148/openstack-patrole-foolproofing-your-openstack-deployment
[4] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22788/users-operators-adoption-of-qa-tools-plugins
 
[5] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22837/using-rallytempest-for-change-validation-ops-session
 

-gmann


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


[Openstack-operators] [puppet] openstack providers - endpoint not configurable

2018-11-08 Thread Justin Cattle
Hi,


I've been recently working on separating management and client traffic onto
different endpoints.  We have different endpoint URLs configured for
"public", "admin" and "internal".

For openstack itself, this is working well.  However, puppet providers
don't seem to cater for this.

Particularly, right now, I'm looking at the neutron providers, but they may
be mostly the same.  It always uses the public endpoint, and doesn't seem
configurable [ unless I'm missing something ].
All the client config for auth etc is sourced from neutron.conf, and I
can't see a way of specifying endpoint type via that mechanism.

I can change the provider like this, and it all works:

diff --git a/lib/puppet/provider/neutron.rb b/lib/puppet/provider/neutron.rb
index a55fa0b..786e64d 100644
--- a/lib/puppet/provider/neutron.rb
+++ b/lib/puppet/provider/neutron.rb
@@ -75,14 +75,16 @@ correctly configured.")
 :OS_AUTH_URL=> q['identity_uri'],
 :OS_USERNAME=> q['admin_user'],
 :OS_TENANT_NAME => q['admin_tenant_name'],
-:OS_PASSWORD=> q['admin_password']
+:OS_PASSWORD=> q['admin_password'],
+:OS_ENDPOINT_TYPE => 'internal',
   }
 else
   authenv = {
 :OS_AUTH_URL=> q['auth_url'],
 :OS_USERNAME=> q['username'],
 :OS_TENANT_NAME => q['tenant_name'],
-:OS_PASSWORD=> q['password']
+:OS_PASSWORD=> q['password'],
+:OS_ENDPOINT_TYPE => 'internal',
   }
 end
 if q.key?('nova_region_name')


Notice, I'm adding OS_ENDPOINT_TYPE to control the endpoint that selected
from the catalogue.

I want to keep the "public" endpoints for external clients only on the
external network, the "internal" endpoints for inter service API comms on
the management network, and the "admin" endpoints for admin operations on
the management network.

In particular, I want to be able to stop advertising the public endpoints
during maintenance windows, and still be able to run puppet!


Can anyone think of a way of overcoming this?

If it's not possible through config, is there some way I can drop in my own
provider version with the same name safely ?

Anything else I'm missing?

Thanks!



Cheers,
Just

-- 


Notice:  This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group. 

 

If you are not the intended recipient, please notify us 
immediately and delete all copies of this message. Please note that it is 
your responsibility to scan this message for viruses. 

 

Fetch and Sizzle 
are trading names of Speciality Stores Limited and Fabled is a trading name 
of Marie Claire Beauty Limited, both members of the Ocado Group.

 


References to the “Ocado Group” are to Ocado Group plc (registered in 
England and Wales with number 7098618) and its subsidiary undertakings (as 
that expression is defined in the Companies Act 2006) from time to time.  
The registered office of Ocado Group plc is Buildings One & Two, Trident 
Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
___
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] about resize the instance

2018-11-08 Thread Rambo
When I resize the instance, the compute node report that "libvirtError: 
internal error: qemu unexpectedly closed the monitor: 
2018-11-08T09:42:04.695681Z qemu-kvm: cannot set up guest memory 'pc.ram': 
Cannot allocate memory".Has anyone seen this situation?And the 
ram_allocation_ratio is set 3 in nova.conf.The total memory is 125G.When I use 
the "nova hypervisor-show server" command to show the compute node's 
free_ram_mb is -45G.If it is the result of excessive use of memory?
Can you give me some suggestions about this?Thank you very much.
-- Original --
From:  "Rambo";
Date:  Thu, Nov 8, 2018 05:45 PM
To:  "OpenStack Developmen"; 

Subject:  [openstack-dev]  [nova] about resize the instance

 
Hi,all

When we resize/migrate instance, if error occurs on source compute 
node, the instance state can rollback to active currently.But if error occurs 
in "finish_resize" function on destination compute node, the instance state 
would not rollback to active. Is there a bug, or if anyone plans to change 
this?Can you tell me more about this ?Thank you very much.




















Best Regards
Rambo___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators