Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Chris]

Hello Tzach,

Agree for a graceful shutdown there should be some steps ahead. Im 
actually asking the question because the hardware we use has a high 
failure rate on RAID controllers. The physical machine reacts with a 
reboot, so its not controlable from our side. We dont want to delete the 
instances at all, its just about the Instance shutdown/process kill.


Got a good answer already:
If you are using CentOS  / Red Hat you can modify this file:
/etc/sysconfig/libvirt-guests
libvirt-guests:#ON_SHUTDOWN=suspend


Thanks for your answer!

Cheers Chris


On 2017-11-02 15:54, Tzach Shefi wrote:

Hi, 

A better Q would be why do you shutdown a compute node to begin with?
I mean if you need you should do so in an orderly fashion basically
excavate instances

or shut instances down manually, put the compute node in maintenance
mode. 
On rebooting compute node remove it from maintenance mode, turn on
instances or migrate them back to this compute node should you need. 
Od delete them if you wish. 

There is this nova option:
resume_guests_state_on_host_boot=true

But it doesn't delete or shutdown instances but rather turns them on
automatically once compute host resumes. 
which might also work for you, probably not just mentioning it any
way.  

I don't know of an option to stop/delete instance on compute node
shutdown. 

Another option check maybe you could shelve suspended instance and
then later delete them. 

Shelving stops the instance and takes a snapshot of it. Then depending
on the value of the shelved_offload_time config option, the instance
is deleted from the hypervisor (0), never deleted (-1), or deleted
after some period of time (> 0). Note that it's just destroying the
backing instance on the hypervisor, the actual instance in the nova
database is not deleted. Then you can later unshelve the instance:

This might help, but do not if you mess with kvm without updating Nova
you might be left haning else where :)
https://ask.fedoraproject.org/en/question/8796/make-libvirt-to-shutdown-my-guests-not-suspend/
[2]

 

On Thu, Nov 2, 2017 at 9:03 AM, Chris  wrote:


Hello,

When we shut down a compute node the instances running on it get
suspended. This generates some difficulties with some applications
like RabbitMQ dont like to be suspended. Is there a way to change
this behavior so that the running instances gets killed or shutdown
instead?

Thanks in advance.

Cheers,
Chris

___
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
Post to     : openstack@lists.openstack.org
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]


--

Tzach Shefi

Senior Quality Engineer, RHCSA

Red Hat

 tsh...@redaht.com    M: +972-54-4701080 [3]     IM: tshefi

 [4]



Links:
--
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[2]
https://ask.fedoraproject.org/en/question/8796/make-libvirt-to-shutdown-my-guests-not-suspend/
[3] tel:+972-54-4701080
[4] https://red.ht/sig


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Chris]

Hello Remo,

Exactly what I was looking for! If I could give you a rating it would be 
the highest :)


Cheers,
Chris

On 2017-11-03 1:27, Remo Mattei wrote:

sorry forgot to paste the file location
/etc/sysconfig/libvirt-guests




On 11/2/17 11:21 AM, Remo Mattei wrote:

If you are using CentOS  / Red Hat you can modify this file:

libvirt-guests:#ON_SHUTDOWN=suspend



# action taken on host shutdown
# - suspend   all running guests are suspended using virsh managedsave
# - shutdown  all running guests are asked to shutdown. Please be
careful with
# this settings since there is no way to distinguish 
between a
# guest which is stuck or ignores shutdown requests and a 
guest

# which just needs a long time to shutdown. When setting
# ON_SHUTDOWN=shutdown, you must also set SHUTDOWN_TIMEOUT 
to a

# value suitable for your guests.
#ON_SHUTDOWN=suspend



Hope this help.

Remo

On 11/2/17 11:08 AM, Chris Friesen wrote:

On 11/02/2017 01:03 AM, Chris wrote:

Hello,

When we shut down a compute node the instances running on it get
suspended. This
generates some difficulties with some applications like RabbitMQ 
dont

like to be
suspended. Is there a way to change this behavior so that the 
running

instances
gets killed or shutdown instead?
This may be done by the libvirtd shutdown scripts rather than 
anything

in nova.

As others have said, you should probably either shut down the VMs in
an orderly fashion or else cold/live migrate the instances off the
compute node before rebooting it.

Chris

___
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Post to : openstack@lists.openstack.org
Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



___
Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Post to : openstack@lists.openstack.org
Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Van Leeuwen, Robert]

>There is this nova option:
>resume_guests_state_on_host_boot=true
>
>But it doesn't delete or shutdown instances but rather turns them on 
>automatically once compute host resumes.
>which might also work for you, probably not just mentioning it any way.

Note that you might want to check some things after a reboot before booting up 
all your instances.
The easiest way would be to set this value to true but to not start the 
nova-compute service on boot.
Now you can check whatever you need and start nova-compute when you know the 
server is in a good state.
Nova will now start the instances that where running when your compute node was 
shutdown.
The nice thing about this is that any instances that where shutdown/suspended 
by users will keep in a shutdown state.
If you do not do this you would need to create a custom script that saves which 
instances where running before the shutdown and then use that list to start 
only the correct instances.

Another thing to consider is if you want to auto-start instances after a 
compute node did an unexpected reboot.
IMHO I would rather have a dead instance then an instance running on flaky 
hard/software but it might depend a bit on your use case.

>I don't know of an option to stop/delete instance on compute node shutdown.
As mentioned by some other people this is actually a libvirt setting not a nova 
setting.


Cheers,
Robert van Leeuwen
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] help - Fuel Community 11 - PXE

[Remo Mattei]

you could upgrade to Tripleo :)

Ciao,


On 11/2/17 11:18 AM, Ken Houle wrote:
>
> Evgeniy L.
>
>  
>
> Thank you for the information. I have rebuilt the Fuel Community 11
> server and left everything default with the exception of setting the
> PXE support to eth1. I am seeing the same issue.
>
> The Silicon Mechanics server with a Supermicro system board as been
> configured in every possible boot configuration that I can think of;
> and I’m still seeing the “PXE-E7B” error.
>
>  
>
>  
>
> I’m about to consign this server to another use.
>
>  
>
>  
>
>  
>
> Regards,
>
>  
>
> /Ken Houle/
> 469-634-4171 :
> kho...@developingsolutions.com
>
>  
>
> *From:* Evgeniy L [mailto:e...@mirantis.com]
> *Sent:* Tuesday, October 31, 2017 9:58 AM
> *To:* Ken Houle 
> *Cc:* Openstack 
> *Subject:* Re: [Openstack] help - Fuel Community 11 - PXE
>
>  
>
> I'm not sure if these options should be set, because they are required
> only if PXE server is on different host from DHCP server, which is not
> the case for Fuel.
>
>  
>
> On Thu, Oct 26, 2017 at 8:25 AM, Ken Houle
>  > wrote:
>
> Evgeniy L:
>
>  
>
> Thank you for the information. I have a few, possible silly/noob,
> question. After your email I reviewed the tcpdump again and
> identified that the “dhcp offer” does not contain options 66 and 67.
>
> You can see from the excerpt of a bootp capture the highlighted
> portions contain the IP address offered, next server, and boot file.
>
>  
>
> However, in the options section there is not an option 66, tftp
> server name, and option 67, bootfile name.
>
>  
>
> SO here is the question, taking cobbler into account which file
> should I be editing to attempt to add these options? Is the
> “/etc/cobbler/dhcp.template” file the correct file; thought
> “template” seems to  indicate that it is not?
>
> If not, again silly/noob, which file should I be editing.
>
>  
>
> Any assistance would be appreciated.
>
>  
>
>  
>
> Frame 4138: 342 bytes on wire (2736 bits), 342 bytes captured
> (2736 bits)
>
> Ethernet II, Src: Dell_b9:6a:02 (d4:ae:52:b9:6a:02), Dst:
> Broadcast (ff:ff:ff:ff:ff:ff)
>
> Internet Protocol Version 4, Src: 10.10.30.10, Dst: 255.255.255.255
>
> User Datagram Protocol, Src Port: 67, Dst Port: 68
>
> Bootstrap Protocol (Offer)
>
>     Message type: Boot Reply (2)
>
>     Hardware type: Ethernet (0x01)
>
>     Hardware address length: 6
>
>     Hops: 0
>
>     Transaction ID: 0x906a77f9
>
>     Seconds elapsed: 18
>
>     Bootp flags: 0x8000, Broadcast flag (Broadcast)
>
>     1...    = Broadcast flag: Broadcast
>
>     .000    = Reserved flags: 0x
>
>     Client IP address: 0.0.0.0
>
>     Your (client) IP address: 10.10.30.21
>
>     Next server IP address: 10.10.30.10
>
>     Relay agent IP address: 0.0.0.0
>
>     Client MAC address: SuperMic_6a:77:f9 (00:25:90:6a:77:f9)
>
>     Client hardware address padding: 
>
>     Server host name: boothost
>
>     Boot file name: pxelinux.0
>
>     Magic cookie: DHCP
>
>     Option: (53) DHCP Message Type (Offer)
>
>     Option: (54) DHCP Server Identifier
>
>     Option: (51) IP Address Lease Time
>
>     Option: (58) Renewal Time Value
>
>     Option: (59) Rebinding Time Value
>
>     Option: (1) Subnet Mask
>
>     Option: (28) Broadcast Address
>
>     Option: (15) Domain Name
>
>     Option: (6) Domain Name Server
>
>     Option: (3) Router
>
>     Option: (255) End
>
>     Padding: 00
>
>  
>
> Regards,
>
>  
>
> /Ken Houle/
> 469-634-4171 : kho...@developingsolutions.com
> 
>
>  
>
> *From:* Evgeniy L [mailto:e...@mirantis.com ]
> *Sent:* Wednesday, October 25, 2017 11:45 AM
> *To:* Ken Houle  >
> *Cc:* Openstack  >
> *Subject:* Re: [Openstack] help - Fuel Community 11 - PXE
>
>  
>
> Hi Ken,
>
>  
>
> Fuel uses Cobbler which uses DNSMasq to provide DHCP and PXE boot,
> if the issue is hardware specific, you can try to search if
> anybody else had such problems with DNSMasq PXE boot and similar
> hardware.
>
>  
>
> Thanks,
>
>  
>
> On Wed, Oct 25, 2017 at 7:12 AM, Ken Houle
>  > wrote:
>
> All:
>
>  
>
> First off not sure I am in the right place so if I am not
> please be kind and point me in the correct direction. I am
> attempting to build an Openstack system with Fuel Community 11
> with a mix servers from different manufacturers. I have
> successfully inst

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Remo Mattei]

sorry forgot to paste the file location
/etc/sysconfig/libvirt-guests




On 11/2/17 11:21 AM, Remo Mattei wrote:
> If you are using CentOS  / Red Hat you can modify this file:
>
> libvirt-guests:#ON_SHUTDOWN=suspend
>
>
>
> # action taken on host shutdown
> # - suspend   all running guests are suspended using virsh managedsave
> # - shutdown  all running guests are asked to shutdown. Please be
> careful with
> # this settings since there is no way to distinguish between a
> # guest which is stuck or ignores shutdown requests and a guest
> # which just needs a long time to shutdown. When setting
> # ON_SHUTDOWN=shutdown, you must also set SHUTDOWN_TIMEOUT to a
> # value suitable for your guests.
> #ON_SHUTDOWN=suspend
>
>
>
> Hope this help.
>
> Remo
>
> On 11/2/17 11:08 AM, Chris Friesen wrote:
>> On 11/02/2017 01:03 AM, Chris wrote:
>>> Hello,
>>>
>>> When we shut down a compute node the instances running on it get
>>> suspended. This
>>> generates some difficulties with some applications like RabbitMQ dont
>>> like to be
>>> suspended. Is there a way to change this behavior so that the running
>>> instances
>>> gets killed or shutdown instead?
>> This may be done by the libvirtd shutdown scripts rather than anything
>> in nova.
>>
>> As others have said, you should probably either shut down the VMs in
>> an orderly fashion or else cold/live migrate the instances off the
>> compute node before rebooting it.
>>
>> Chris
>>
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Remo Mattei]

If you are using CentOS  / Red Hat you can modify this file:

libvirt-guests:#ON_SHUTDOWN=suspend



# action taken on host shutdown
# - suspend   all running guests are suspended using virsh managedsave
# - shutdown  all running guests are asked to shutdown. Please be
careful with
# this settings since there is no way to distinguish between a
# guest which is stuck or ignores shutdown requests and a guest
# which just needs a long time to shutdown. When setting
# ON_SHUTDOWN=shutdown, you must also set SHUTDOWN_TIMEOUT to a
# value suitable for your guests.
#ON_SHUTDOWN=suspend



Hope this help.

Remo

On 11/2/17 11:08 AM, Chris Friesen wrote:
> On 11/02/2017 01:03 AM, Chris wrote:
>> Hello,
>>
>> When we shut down a compute node the instances running on it get
>> suspended. This
>> generates some difficulties with some applications like RabbitMQ dont
>> like to be
>> suspended. Is there a way to change this behavior so that the running
>> instances
>> gets killed or shutdown instead?
>
> This may be done by the libvirtd shutdown scripts rather than anything
> in nova.
>
> As others have said, you should probably either shut down the VMs in
> an orderly fashion or else cold/live migrate the instances off the
> compute node before rebooting it.
>
> Chris
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] help - Fuel Community 11 - PXE

[Ken Houle]

Evgeniy L.

 

Thank you for the information. I have rebuilt the Fuel Community 11 server and 
left everything default with the exception of setting the PXE support to eth1. 
I am seeing the same issue.

The Silicon Mechanics server with a Supermicro system board as been configured 
in every possible boot configuration that I can think of; and I’m still seeing 
the “PXE-E7B” error.

 

 

I’m about to consign this server to another use.

 

 

 

Regards, 

 

Ken Houle
469-634-4171 :   
kho...@developingsolutions.com

 

From: Evgeniy L [mailto:e...@mirantis.com] 
Sent: Tuesday, October 31, 2017 9:58 AM
To: Ken Houle 
Cc: Openstack 
Subject: Re: [Openstack] help - Fuel Community 11 - PXE

 

I'm not sure if these options should be set, because they are required only if 
PXE server is on different host from DHCP server, which is not the case for 
Fuel.

 

On Thu, Oct 26, 2017 at 8:25 AM, Ken Houle mailto:kho...@developingsolutions.com> > wrote:

Evgeniy L:

 

Thank you for the information. I have a few, possible silly/noob, question. 
After your email I reviewed the tcpdump again and identified that the “dhcp 
offer” does not contain options 66 and 67.

You can see from the excerpt of a bootp capture the highlighted portions 
contain the IP address offered, next server, and boot file.

 

However, in the options section there is not an option 66, tftp server name, 
and option 67, bootfile name.

 

SO here is the question, taking cobbler into account which file should I be 
editing to attempt to add these options? Is the “/etc/cobbler/dhcp.template” 
file the correct file; thought “template” seems to  indicate that it is not?

If not, again silly/noob, which file should I be editing.

 

Any assistance would be appreciated.

 

 

Frame 4138: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits)

Ethernet II, Src: Dell_b9:6a:02 (d4:ae:52:b9:6a:02), Dst: Broadcast 
(ff:ff:ff:ff:ff:ff)

Internet Protocol Version 4, Src: 10.10.30.10, Dst: 255.255.255.255

User Datagram Protocol, Src Port: 67, Dst Port: 68

Bootstrap Protocol (Offer)

Message type: Boot Reply (2)

Hardware type: Ethernet (0x01)

Hardware address length: 6

Hops: 0

Transaction ID: 0x906a77f9

Seconds elapsed: 18

Bootp flags: 0x8000, Broadcast flag (Broadcast)

1...    = Broadcast flag: Broadcast

.000    = Reserved flags: 0x

Client IP address: 0.0.0.0

Your (client) IP address: 10.10.30.21

Next server IP address: 10.10.30.10

Relay agent IP address: 0.0.0.0

Client MAC address: SuperMic_6a:77:f9 (00:25:90:6a:77:f9)

Client hardware address padding: 

Server host name: boothost

Boot file name: pxelinux.0

Magic cookie: DHCP

Option: (53) DHCP Message Type (Offer)

Option: (54) DHCP Server Identifier

Option: (51) IP Address Lease Time

Option: (58) Renewal Time Value

Option: (59) Rebinding Time Value

Option: (1) Subnet Mask

Option: (28) Broadcast Address

Option: (15) Domain Name

Option: (6) Domain Name Server

Option: (3) Router

Option: (255) End

Padding: 00

 

Regards, 

 

Ken Houle
469-634-4171 :   
kho...@developingsolutions.com

 

From: Evgeniy L [mailto:e...@mirantis.com  ] 
Sent: Wednesday, October 25, 2017 11:45 AM
To: Ken Houle mailto:kho...@developingsolutions.com> >
Cc: Openstack mailto:openstack@lists.openstack.org> >
Subject: Re: [Openstack] help - Fuel Community 11 - PXE

 

Hi Ken,

 

Fuel uses Cobbler which uses DNSMasq to provide DHCP and PXE boot, if the issue 
is hardware specific, you can try to search if anybody else had such problems 
with DNSMasq PXE boot and similar hardware.

 

Thanks,

 

On Wed, Oct 25, 2017 at 7:12 AM, Ken Houle mailto:kho...@developingsolutions.com> > wrote:

All:

 

First off not sure I am in the right place so if I am not please be kind and 
point me in the correct direction. I am attempting to build an Openstack system 
with Fuel Community 11 with a mix servers from different manufacturers. I have 
successfully installed Fuel Community 11 on the master node and am attempting 
to add nodes to the Openstack environment. The “Dell” servers pxe boot fine, 
see the master node and can be added to the system. However, I have an older 
“Silicon Mechanics” server that will not pxe boot.

 

I have upgraded the AMI BIOS on the “Supermicro” system board to the latest 
release as well as the IPMI firmware. I have attempted to use both legacy and 
UEFI boot from the BIOS and I always see the same error. Please note that the 
Intel PXE release is 1.5.13.

 

“PXE-E7B: Missing MTFTP server IP address. This message is displayed when the 
ROM did not receive any PXE discovery tags or proxyDHCP offers and the DHCP 
SIADDR field is set to 0.0.0.0.”

 

I have take a tcpdump and see the dhcp discover and the dhcp o

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Chris Friesen]

On 11/02/2017 01:03 AM, Chris wrote:

Hello,

When we shut down a compute node the instances running on it get suspended. This
generates some difficulties with some applications like RabbitMQ dont like to be
suspended. Is there a way to change this behavior so that the running instances
gets killed or shutdown instead?


This may be done by the libvirtd shutdown scripts rather than anything in nova.

As others have said, you should probably either shut down the VMs in an orderly 
fashion or else cold/live migrate the instances off the compute node before 
rebooting it.


Chris

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Devstack with OpenStack's local repo

[Sean Dague]

On 11/02/2017 04:32 AM, Ramu, MohanX wrote:

Hi All,

Whenever I run devstack set up scripts it always download the latest 
minor version of OpenStack.


I want to control that by connecting my local OpenStack repo is it 
possible?


Please let me know.

Thanks & regards,

Mohan Ramu


It is, we document it a bit here (though patches are welcome if you have 
ideas on making it more clear) - 
https://docs.openstack.org/devstack/latest/development.html#testing-a-patch-series


-Sean

--
Sean Dague
http://dague.net

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Devstack with OpenStack's local repo

[Dean Troyer]

On Thu, Nov 2, 2017 at 6:32 AM, Ramu, MohanX  wrote:
> I want to control that by connecting my local OpenStack repo is it possible?

In stackrc you will find a number of environment variable pairs of the
form XXX_REPO and XXX_BRANCH.  Those can be used to get very specific
about the repo and branch to check out for each project and many
sub-projects and libraries.  Also, the GIT_BASE variable may be
sufficient to point at your own collection of repos.

dt

-- 

Dean Troyer
dtro...@gmail.com

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Devstack with OpenStack's local repo

[Ramu, MohanX]

Hi All,

Whenever I run devstack set up scripts it always download the latest minor 
version of OpenStack.

I want to control that by connecting my local OpenStack repo is it possible?

Please let me know.

Thanks & regards,

Mohan Ramu

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Fuel-9.2 - Broken deployment on one node stops all other nodes too

[Raja T Nair]

Hi Evgeniy,

apt-cache policy fuel-ha-utils says that the package is not to be found.

Now I re-installed fuel on another node(as there was a lot of issues faced
on the old one), and created local repo using these commands:

fuel-mirror create -P ubuntu -G ubuntu
fuel-mirror apply -G ubuntu -I /usr/share/fuel-mirror/ubuntu.yaml --replace
--default
fuel-mirror apply -G mos -I /usr/share/fuel-mirror/ubuntu.yaml --default

my /usr/share/fuel-mirror directory looks like this:

[root@fuel92 nginx]# ll /usr/share/fuel-mirror/
total 12
-rwxr-xr-x. 1 root root 1344 May 24 07:47 centos.yaml
-rwxr-xr-x. 1 root root 4288 May 24 07:47 ubuntu.yaml
[root@fuel92 nginx]#

While doing the ``connectivity check'', it failed with following error
lines:
Verification failed.
Repo availability verification failed on following nodes Fuel master node,
Untitled (0b:34), Untitled (71:28), Untitled (2b:52), Untitled (ae:40),
Untitled (a8:73).
Following repos are not available -
http://172.22.66.11:8080/mirrors/mos-repos/ubuntu/9.0,
http://172.22.66.11:8080/mirrors/mos-repos/ubuntu/9.2.

nginx logs say this:
2017/11/02 10:22:47 [error] 1188#1188: *12256 open()
"/var/www/nailgun/mirrors/mos-repos/ubuntu/9.0" failed (2: No such file or
directory), client
: 172.22.66.24, server: localhost, request: "GET
/mirrors/mos-repos/ubuntu/9.0 HTTP/1.1", host: "172.22.66.11:8080"

And the directory mos-repos actually does not exist:
[root@fuel92 nginx]# ls /var/www/nailgun/mirrors/
ubuntu

I suppose I need to build the mos-repos repo also locally. If yes, how do I
do this? I thought it would have built it with the above
"fuel-mirror create -P ubuntu -G ubuntu" command.

Attaching screenshot of settings page, which shows currently configured
repos.

Please help me with this one.

Regards,
Raja.



On 31 October 2017 at 19:29, Evgeniy L  wrote:

> Run "apt-cache policy fuel-ha-utils" and see from which repository does it
> come from, if your mirrors configured correctly, the package should come
> from your mirror.
> It also shows what command it failed to run, "/usr/bin/apt-get -q -y -o
> DPkg::Options::=--force-confold -o APT::Get::AllowUnauthenticated=1
> install fuel-ha-utils" you can run it manually on the node and see what the
> error is.
>
> Thanks,
>
> On Tue, Oct 31, 2017 at 12:27 AM, Raja T Nair  wrote:
>
>> Hi,
>>
>> I built the repos locally, using the instructions in this page:
>> https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-
>> install-guide/local-repo.html
>>
>> Now, while trying to deploy to 2 newly added nodes, it fails with this
>> error:
>>
>> 2017-10-31 06:45:11ERR(/Stage[main]/Osnailyfacter::Fuel_pkgs::Fuel_
>> pkgs/Package[fuel-ha-utils]/ensure) E: Unable to locate package
>> fuel-ha-utils
>> 2017-10-31 06:45:11ERR(/Stage[main]/Osnailyfacter::Fuel_pkgs::Fuel_
>> pkgs/Package[fuel-ha-utils]/ensure) Reading state information...
>> 2017-10-31 06:45:11ERR(/Stage[main]/Osnailyfacter::Fuel_pkgs::Fuel_
>> pkgs/Package[fuel-ha-utils]/ensure) Building dependency tree...
>> 2017-10-31 06:45:11ERR(/Stage[main]/Osnailyfacter::Fuel_pkgs::Fuel_
>> pkgs/Package[fuel-ha-utils]/ensure) change from purged to present
>> failed: Execution of '/usr/bin/apt-get -q -y -o
>> DPkg::Options::=--force-confold -o APT::Get::AllowUnauthenticated=1
>> install fuel-ha-utils' returned 100: Reading package lists...
>> 2017-10-31 06:45:11ERR/usr/bin/puppet:8:in `'2017-10-31
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:92:in
>> `execute'
>> 2017-10-31 
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:146:in
>> `run'2017-10-31 06:45:11ERR/usr/lib/ruby/vendo
>> r_ruby/puppet/application.rb:381:in `run'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/util.rb:496:in
>> `exit_on_fail'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application.rb:381:in
>> `block in run'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application.rb:507:in
>> `plugin_hook'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application.rb:381:in
>> `block (2 levels) in run'
>> 2017-10-31 
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application/apply.rb:159:in
>> `run_command'
>> 2017-10-31 
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application/apply.rb:198:in
>> `main'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet.rb:246:in
>> `override'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/context.rb:64:in
>> `override'
>> 2017-10-31 
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application/apply.rb:236:in
>> `block in main'
>> 2017-10-31 
>> 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/application/apply.rb:302:in
>> `apply_catalog'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:133:in
>> `run'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet.rb:246:in
>> `override'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/context.rb:64:in
>> `override'
>> 2017-10-31 06:45:11ERR/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:134:in
>> `blo

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Tomáš Vondra]

Hi!

When I need to reboot a compute node (because of some driver lock-up or such 
problems), I first stop nova-compute so that it does not report the shutoff 
state of VMs to the database and resume_guests_state_on_host_boot=true does 
actually start them. Then I press the power switch on the VMs using virsh 
shutdown, one by one, and only after that I reboot the node. This is a script I 
scrounged somewhere and modified so that it does not take too much time:

Tomas

 

root@cmp03:~# cat vm-shutdown

#!/bin/bash

# file: /usr/local/sbin/vm-shutdown

# Description: shutdown active virtual machines

debug=1

#fake=1

 

# Get list of active virtual machines

vmList="`virsh list | (

while read vmID vmName vmStatus

do

  if [ -n "$vmName" -a "$vmName" != "Name" -a "$vmName" != "Domain-0" ]

  then

[ -z "$vmList" ] && vmList="$vmName" || vmList="$vmList $vmName"

  fi

done

echo $vmList )`"

 

# check there are some active VM's

if [ -n "$vmList" ]; then

  # Shutdown VM's with verification

  for vmName in $vmList

  do

# send initial request

[ -n "$debug" ] && echo -n "Attempting to shutdown $vmName "

[ -z "$fake" ] && virsh shutdown $vmName

# wait a limited time for the VM to be not running

count=30

while $( virsh list | grep $vmName >/dev/null ) && [ $count -gt 0 ]

do

  sleep 1

  let count=count-1

  [ -n "$debug" ] && echo -n "."

done

# report current status

( virsh list | grep $vmName >/dev/null ) && echo " failed!" || echo "down."

# if still running, destroy it

if ( virsh list | grep $vmName >/dev/null )

then

  [ -n "$debug" ] && echo -n "Attempting to destroy $vmName "

  [ -z "$fake" ] && virsh destroy $vmName

  # wait a limited time for the VM to be not running

  count=30

  while $( virsh list | grep $vmName >/dev/null ) && [ $count -gt 0 ]

  do

sleep 1

let count=count-1

[ -n "$debug" ] && echo -n "."

  done

  # report current status

  ( virsh list | grep $vmName >/dev/null ) && echo " failed!" || echo 
"down."

fi

  done

 

From: Tzach Shefi [mailto:tsh...@redhat.com] 
Sent: Thursday, November 02, 2017 9:55 AM
To: Chris
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] Compute Node shutdown how to prevent instance suspend

 

Hi, 

 

A better Q would be why do you shutdown a compute node to begin with?

I mean if you need you should do so in an orderly fashion basically excavate 
instances

or shut instances down manually, put the compute node in maintenance mode. 

On rebooting compute node remove it from maintenance mode, turn on instances or 
migrate them back to this compute node should you need. 

Od delete them if you wish. 

 

There is this nova option:

resume_guests_state_on_host_boot=true

 

But it doesn't delete or shutdown instances but rather turns them on 
automatically once compute host resumes. 

which might also work for you, probably not just mentioning it any way.  

 

I don't know of an option to stop/delete instance on compute node shutdown. 

 

Another option check maybe you could shelve suspended instance and then later 
delete them. 

 

Shelving stops the instance and takes a snapshot of it. Then depending on the 
value of the shelved_offload_time config option, the instance is deleted from 
the hypervisor (0), never deleted (-1), or deleted after some period of time (> 
0). Note that it's just destroying the backing instance on the hypervisor, the 
actual instance in the nova database is not deleted. Then you can later 
unshelve the instance:

 

 

This might help, but do not if you mess with kvm without updating Nova you 
might be left haning else where :)

https://ask.fedoraproject.org/en/question/8796/make-libvirt-to-shutdown-my-guests-not-suspend/

 

 

 

 

On Thu, Nov 2, 2017 at 9:03 AM, Chris  wrote:

Hello,

When we shut down a compute node the instances running on it get suspended. 
This generates some difficulties with some applications like RabbitMQ dont like 
to be suspended. Is there a way to change this behavior so that the running 
instances gets killed or shutdown instead?

Thanks in advance.

Cheers,
Chris

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack





 

-- 

Tzach Shefi

Senior Quality Engineer, RHCSA

  Red Hat 



  tsh...@redaht.comM:   
+972-54-4701080 IM: tshefi


  Obrázek byl odebrán odesílatelem.

 

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Compute Node shutdown how to prevent instance suspend

[Tzach Shefi]

Hi,

A better Q would be why do you shutdown a compute node to begin with?
I mean if you need you should do so in an orderly fashion basically
excavate instances
or shut instances down manually, put the compute node in maintenance mode.
On rebooting compute node remove it from maintenance mode, turn on
instances or migrate them back to this compute node should you need.
Od delete them if you wish.

There is this nova option:
resume_guests_state_on_host_boot=true

But it doesn't delete or shutdown instances but rather turns them on
automatically once compute host resumes.
which might also work for you, probably not just mentioning it any way.

I don't know of an option to stop/delete instance on compute node shutdown.

Another option check maybe you could shelve suspended instance and then
later delete them.

Shelving stops the instance and takes a snapshot of it. Then depending on
the value of the shelved_offload_time config option, the instance is
deleted from the hypervisor (0), never deleted (-1), or deleted after some
period of time (> 0). Note that it's just destroying the backing instance
on the hypervisor, the actual instance in the nova database is not deleted.
Then you can later unshelve the instance:


This might help, but do not if you mess with kvm without updating Nova you
might be left haning else where :)
https://ask.fedoraproject.org/en/question/8796/make-libvirt-to-shutdown-my-guests-not-suspend/




On Thu, Nov 2, 2017 at 9:03 AM, Chris  wrote:

> Hello,
>
> When we shut down a compute node the instances running on it get
> suspended. This generates some difficulties with some applications like
> RabbitMQ dont like to be suspended. Is there a way to change this behavior
> so that the running instances gets killed or shutdown instead?
>
> Thanks in advance.
>
> Cheers,
> Chris
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>



-- 

Tzach Shefi

Senior Quality Engineer, RHCSA

Red Hat



tsh...@redaht.comM: +972-54-4701080 IM: tshefi

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Compute Node shutdown how to prevent instance suspend

[Chris]

Hello,

When we shut down a compute node the instances running on it get 
suspended. This generates some difficulties with some applications like 
RabbitMQ dont like to be suspended. Is there a way to change this 
behavior so that the running instances gets killed or shutdown instead?


Thanks in advance.

Cheers,
Chris

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack