[Openstack-operators] [publiccloud-wg] Reminder meeting PublicCloudWorkingGroup

[Tobias Rydberg]

Hi everyone,

Don't forget todays meeting for the PublicCloudWorkingGroup.
1400 UTC in IRC channel #openstack-meeting-3

Etherpad: https://etherpad.openstack.org/p/publiccloud-wg

Goals: https://etherpad.openstack.org/p/SYDNEY_GOALS_publiccloud-wg

Talk to you this afternoon!

Tobias
tob...@citynetwork.se


smime.p7s
Description: S/MIME Cryptographic Signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [FEMDC] IRC Meeting tomorrow 15:00 UTC

[lebre . adrien]

Dear all, 

A gentle reminder for our meeting tomorrow. 
As usual, the agenda is available at: 
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 
860)
Please feel free to add items.

Best,
Adrien
PS: note that due to the vacation period, I don't know how many persons will be 
present. 

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

Re: [Openstack-operators] [openstack-dev] [masakari][nova] Allow evacuation of instances in resized state

[Kekane, Abhishek]

Hi operators,

I want to know how evacuation of resized instances is handled in real 
environment.
For example if the vm is in resized state and if the compute host on which the 
vm is resized goes down, then how will operator evacuate the vm.

One possible way is to reset that vm state to error and then evacuate it to new 
compute host.
Please refer below scenario for reference:

Scenario:
=

Pre-conditions:

1. Config option allow_resize_to_same_host is False.
2. Instance path is not mounted on shared storage.
3. Three compute nodes: "compute node A", "compute node B" and "compute node C"

Steps:

1. Boot an instance on "compute node A".
2. User tries to resize the newly created instance and nova-scheduler selects 
"compute node B" as a destination node for resize.
   In this case nova creates a instance directory on destination "compute node 
B" and mark the instance directory which is present on the source "compute node 
A" as "*_resize".

Note that the resize operation is yet not confirmed and "compute node B" goes 
down.

3. Reset instance state to ERROR as nova allows evacuation only if instance 
state is 'ACTIVE', 'STOPPED' or 'ERROR'.
4. Evacuate the instance to "compute node C" using target_host option.
   As a result, instance files which were on "compute node B" will be cleaned 
up after compute service on it is up again, but instance files which were on 
"compute node A" marked as "*_resize" will never be cleaned up. As of now there 
is no periodic task in nova to perform cleanup of these kinds of scenarios.


Questions:
1. is this the only possible way of evacuating the resized instances in real 
world scenario?
2. If yes is there any way to cleanup unused (*_resize) instance files from the 
source compute node other than cleaning up it manually?
3. Should we add support of evacuating of resized instances in nova?

Please let me know your opinions about the same.


Thank you,

Abhishek Kekane



-Original Message-
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] 
Sent: Thursday, June 29, 2017 5:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in 
resized state

Hi Chris,

IMO we cannot perform auto-confirm as confirming or reverting is user's choice, 
whereas reverting is not possible as the node where the instance is resized is 
down.
As suggested by you allowing this in nova require additional work. It is 
possible if we take power-state into consideration for evacuation operation, 
i.e. while evacuation if instance vmstate is resized and power-state is shutoff 
then we can stop that instance after evacuation.

Thank you,

Abhishek Kekane 

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com]
Sent: Wednesday, June 28, 2017 8:54 PM
To: openstack-...@lists.openstack.org
Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in 
resized state

On 06/28/2017 05:50 AM, Kekane, Abhishek wrote:

> In masakari, we are setting an instance to an error state if the 
> vmstate is resized before evacuating it to a new host.

Arguably the instance should be set to an error state as soon as you notice 
that the compute node is down.

> Once an instance (which was in
> resized state) is evacuated then it becomes active on the new host. 
> The main problem with this implementation from user’s point of view is 
> the instance goes into active state after evacuation, it should be in 
> stopped state if the prior action on the instance before resizing was 
> stop. In masakari, It’s possible to set the vm state to stopped state 
> after evacuation but for a short period the instance will go into the active 
> state which is unacceptable.

That's a valid point, I think.

> *Proposing changes to Nova:*
>
> In the current nova code, if the instance is in stopped state before 
> evacuation, then it remains in the stopped state after evacuation is 
> complete. On the similar lines, we are proposing nova should allow 
> instance to be evacuated in resized state and after evacuation the 
> instance should remain in stopped state if the prior action on the instance 
> is stopped before resizing.

The current nova code looks at the vm_state to decide whether or not it's 
allowable to evacuate, and while "stopped" is a valid state to evacuate from 
"resized" is not.  In your scenario it's both "stopped" *and* "resized" 
simultaneously, but there's no way to represent that in the vmstate so I think 
we'd have to check the power state, which would mean extending the
check_instance_state() routine since it doesn't currently handle the power 
state.

The trickier question is how to handle the "resized" state...after evacuating 
an instance in the "resized" state should you be able to revert the resize?  If 
so, how would that work in the case where the instance was resized on the same 
host originally and that host is no 

Re: [Openstack-operators] pip problems with openstack-ansible deployment

[Markus Zoeller]

On 17.02.2017 16:13, Danil Zhigalin (Europe) wrote:
> Hi Kris,
> 
> In fact the question has been resolved already. 

FWIW, here's the question Danil posted at stackoverflow:
https://stackoverflow.com/questions/42286765/using-repo-other-then-pypi-with-pip
I added my 2cents because my symptoms are the very same.

-- 
Regards, Markus Zoeller (markus_z)

I added tag [ansible-opensta] to the original subject probably that’s
why you didn’t notice that discussion went into another branch. The
problem was caused by not working autoindex in repo directory exposed by
nginx server.
> 
> Best regards,
> Danil
> 
> 
> 
> Danil Zhigalin
> Technical Consultant
> Dimension Data Germany
> Tel: +49 211 1717 1260
> Mob: +49 174 151 8457
> danil.zhiga...@dimensiondata.com
> Dimension Data Germany AG & Co. KG, Derendorfer Allee 26, 40476, Düsseldorf, 
> North Rhine-Westphalia, Germany.
> For more information, please go to 
> www.dimensiondata.com
> [http://de.blog.dimensiondata.com/] 
> [https://www.facebook.com/Dimension-Data-Germany-921346461234757/] 
>   
> [https://www.linkedin.com/company/dimension-data] 
>   
> [https://twitter.com/DimensionDataDe]   
> [cid:image0c58df.PNG@f567f430.4aa02643] 
> 
> [cid:image395d21.JPG@5de7cc63.488860aa]
> 
> Dimension Data Germany AG & Co.KG, Horexstraße 7, 61352 Bad Homburg
> Sitz: Bad Homburg, Amtsgericht Bad Homburg, HRA 3207
> Pers. Haftende Ges : Dimension Data Verwaltungs AG, Sitz Bad Homburg.
> Amtsgericht Bad Homburg, HRB 6172
> Vorstand: Roberto Del Corno
> Vors. des Aufsichtsrats: Andrew Coulsen
> 
> From: Kris G. Lindgren [mailto:klindg...@godaddy.com]
> Sent: 17 February 2017 15:37
> To: Danil Zhigalin (Europe) 
> Cc: openstack-operators@lists.openstack.org
> Subject: Re: [Openstack-operators] pip problems with openstack-ansible 
> deployment
> 
> 
> I don't run OSAD, however did you confirm that on your repo server that you 
> can actually download the files via a curl/wget call, locally and remotely?  
> I see you show the files exist, but don't see anything confirming that the 
> web server is actually serving them.  I have seen things under apache, at 
> least, that prevent the web server from sending the correct info.  Default 
> config files forcing a specific index page, selinux permissions preventing 
> directories from being shown.
> 
> On Feb 17, 2017, at 1:34 AM, Danil Zhigalin (Europe) 
> > 
> wrote:
> 
> 
> I noticed one error in my previous explanation. I am running Ubuntu 14.04 
> LTS, not 16.04.
> 
> 
> 
> Danil Zhigalin
> Technical Consultant
> Tel: +49 211 1717 1260
> Mob: +49 174 151 8457
> danil.zhiga...@dimensiondata.com
> 
> Derendorfer Allee 26, Düsseldorf, North Rhine-Westphalia, 40476, Germany.
> 
> For more information, please go to 
> www.dimensiondata.com
> 
> Dimension Data Germany AG & Co.KG, Horexstraße 7, 61352 Bad Homburg
> Sitz: Bad Homburg, Amtsgericht Bad Homburg, HRA 3207
> Pers. Haftende Ges : Dimension Data Verwaltungs AG, Sitz Bad Homburg.
> Amtsgericht Bad Homburg, HRB 6172
> Vorstand: Roberto Del Corno
> Vors. des Aufsichtsrats: Andrew Coulsen.
> 
> 
> -Original Message-
> From: Danil Zhigalin (Europe)
> Sent: 17 February 2017 09:15
> To: 
> 'openstack-operators@lists.openstack.org'
>  
> >
> Subject: pip problems with openstack-ansible deployment
> 
> Hello everyone,
> 
> Context:
> openstact-ansible: stable/newton
> OS: ubuntu 16.04 LTS
> 
> I am having trouble completing my deployment due to pip errors.
> 
> I have a 2 node setup and one separate deployment node. One of the nodes I am 
> using to host all controller, network and storage functions and another as a 
> compute. Repo container with the server is also hosted on the controller 
> node. I already ran into similar problems as Achi Hamza who already reported 
> pip issue on the Thu Nov 17 08:34:14 UTC 2016 in this mailing list.
> 
> This is how my openstack_user_config.yml file looks like (as in Hamza's case 
> internal and external addresses are the same):
> 
> global_overrides:
> internal_lb_vip_address: 172.21.51.152
> external_lb_vip_address: 172.21.51.152 <...>
> 
> The recommendation that he got from another users were to set:
> 
> openstack_service_publicuri_proto: http
> openstack_external_ssl: false
> haproxy_ssl: false
> 
> in /etc/openstack_deploy/user_vriables.yml
> 
> These recommendations helped in my case as well and I was able to advance 
> further until I faced another 

[Openstack-operators] [scientific] NEW TIME: Scientific WG IRC Meeting Wednesday 1100 UTC

[Stig Telfer]

Hi All - 

We have a Scientific WG meeting on Wednesday at 1100 UTC in #openstack-meeting. 
 This is our NEW TIME - two hours later than usual.

This week we’d like to discuss plans for SuperComputing as the BoF submission 
deadline is approaching.  Also, a catch up on scientific application catalogues 
and Blair’s experiences with transparent huge pages issues under load.

The meeting agenda is available here:

https://wiki.openstack.org/wiki/Scientific_working_group#IRC_Meeting_July_5th_2017
 


Details for our IRC meetings are available here:

http://eavesdrop.openstack.org/#Scientific_Working_Group 


Everyone is welcome.

Cheers,
Stig


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

[Openstack-operators] [openstack-ansible] restrictive umask / file permissions in target hosts

[Markus Zoeller]

How do you deal with hosts which have a restrictive umask of 077
*before* openstack-ansible starts the setup? Do you start with the
default umask of 022 and opt-in later to that security hardening[1]?

What's the development policy of openstack-ansible regarding setting
file or directory permissions in tasks?

* is a umask value of 022 assumed for tasks to work?
* should tasks always explicitly set the file/dir mode?
* other options I'm not aware of?

Background
--
The (internal) folks who gave me the target hosts for openstack-ansible
set the umask to 077 *before* I started the installation and I wasn't
aware of that setting. So I spent some time figuring out why the nginx
server in the repo container can't serve files like the requirements
file "requirements_absolute_requirements.txt"[2] because of file
permissions like this:

-rw--- 1 root root [...] requirements_absolute_requirements.txt

This also affects the nginx config files (which, for example, set the
'autoindex' behavior, which is needed to serve the python wheels):

cd /etc/nginx/sites-available/
ll openstack-slushee.vhost
-rw--- 1 root root [...] openstack-slushee.vhost

Not sure if that was also the root cause of [3].

References
--
[1]
https://github.com/openstack/openstack-ansible-security/blob/40c744c86dd7e5e53e88a5ddd7389333a26f92d2/defaults/main.yml#L340-L363
[2]
https://github.com/openstack/openstack-ansible-repo_build/blob/fe3ae20f74a912925d5c78040984957a6d55f9de/tasks/repo_post_build.yml#L43-L46
[3]
https://stackoverflow.com/questions/42286765/using-repo-other-then-pypi-with-pip

-- 
Regards, Markus Zoeller (markus_z)


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