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

[Jay Pipes]

On 07/19/2017 12:35 PM, Chris Friesen wrote:

On 07/12/2017 06:57 PM, Jay Pipes wrote:

On 07/04/2017 05:21 AM, Kekane, Abhishek wrote:

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'.


I don't understand why you would do this, Abhishek. Why not REVERT the 
resize
operation (which would clean up the _resize directory and files on the 
original

host A) and then try the resize again?


Sorry for the delayed reply (just got back from vacation).  If the dest 
compute node is dead, is it even possible to revert the resize?


Abhishek was describing compute node "B" going down, not the source "A", 
right?


-jay

___
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

[Chris Friesen]

On 07/12/2017 06:57 PM, Jay Pipes wrote:

On 07/04/2017 05:21 AM, Kekane, Abhishek wrote:

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'.


I don't understand why you would do this, Abhishek. Why not REVERT the resize
operation (which would clean up the _resize directory and files on the original
host A) and then try the resize again?


Sorry for the delayed reply (just got back from vacation).  If the dest compute 
node is dead, is it even possible to revert the resize?


Chris

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

[Openstack-operators] OpenStack rabbitmq Mirriored queues

[Ahmed Mostafa]

Dear All,

I am investigating enabling Mirriored queues in my OpenStack cluster.

I have 3 controllers and a 10G network.

One of the videos in Barcelona summit suggested not to do so :

https://www.youtube.com/watch?v=bpmgxrPOrZw

Because it slows down the cloud significantly.

So my question is, would enabling rabbitmq mirrored queus and enabling
rabbit_ha_queues slow down my environment ?

And what are the proper ways to test this ? how can I measure the impact on
my environment ?

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

Re: [Openstack-operators] [OpenStack-docs] [doc] Operations Guide removal

[Anne Gentle]

On Wed, Jul 19, 2017 at 5:51 AM, Doug Hellmann  wrote:
> Excerpts from Blair Bethwaite's message of 2017-07-19 20:40:25 +1000:
>> Hi Alex,
>>
>> I just managed to take a half hour to look at this and have a few
>> questions/comments towards making a plan for how to proceed with
>> moving the Ops Guide content to the wiki...
>>
>> 1) Need to define wiki location and structure. Curiously at the moment
>> there is already meta content at
>> https://wiki.openstack.org/wiki/Documentation/OpsGuide, Maybe the
>> content could live at https://wiki.openstack.org/wiki/OpsGuide? I
>> think it makes sense to follow the existing structure with possible
>> exception of culling wrong / very-out-of-date content (but perhaps
>> anything like that should be done as a later step and keep it simple
>> aiming for a "like-for-like" migration to start with)...?
>
> Yes, I would recommend moving the existing content and then making any
> major changes to it.
>
>> 2) Getting the content into the wiki. Looks like there is no obvious
>> up-to-date RST import functionality for MediaWiki. Pandoc seems as
>> though it might support some useful conversions but I didn't try this
>> yet and don't have any experience with it - can anyone say with
>> authority whether it is worth pursuing?
>
> I can't say with authority myself, but I can refer to Anne as an
> authority. :-)

Ha, well, I think Pandoc is the one to try first, let's say that for starters.

Here's what I was thinking:
If you're interested in the export, run an experiment with Pandoc to
convert from RST to Mediawiki.

http://pandoc.org/demos.html

You'll likely still have cleanup but it's a start. Only convert
troubleshooting to start, which gets the most hits: docs.openstack.org/
ops-guide/ops-network-troubleshooting.html
Then see how much you get from Pandoc.


Hope this helps -
Anne

>
>> 3) Future management - obvious can of worms given this is much better
>> addressed by all the tooling and scaffolding the docs team already
>> provides around the repos... but nonetheless some expectations may
>> need to be set upfront to avoid future pain.
>
> What sort of issues do you foresee?
>
> Doug
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 

Read my blog: justwrite.click
Subscribe to Docs|Code: docslikecode.com

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

Re: [Openstack-operators] [OpenStack-docs] [doc] Operations Guide removal

[Alexandra Settle]

Hey Blair!

Thanks for looking into this… Adding Mario and Erik who both also volunteered 
their time :)

1. I can say confidently that the content that lives at 
https://wiki.openstack.org/wiki/Documentation/OpsGuide can be removed. I am 
happy to do this if you would like to use this URL?
2. We (very successfully) used pandoc during our conversion from XML to RST. I 
would recommend it. I admit I haven’t tried converting to a mediaWiki format. 
But hey, worth trying… I guess the other option is manually copying across and 
editing. (Unless someone has a script lying around?)
3. It’s a good question, one I’m not really sure how to answer. The idea of 
pushing back to the wiki was so that the operators can own. Having the guide 
linked from docs.o.o will still ensure there is traffic, and people are able to 
edit. Perhaps the best idea for this is to use the documentation liaison for 
Ops as a first point of call? What do you think about that? Currently Robert 
Starmer is our liaison 
(https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation ) but 
seeing as we’re now making this more of an official ownership thing, we should 
be revisiting the responsibilities of the ops docs liaison?

Cheers,

Alex

On 7/19/17, 11:40 AM, "Blair Bethwaite"  wrote:

Hi Alex,

I just managed to take a half hour to look at this and have a few
questions/comments towards making a plan for how to proceed with
moving the Ops Guide content to the wiki...

1) Need to define wiki location and structure. Curiously at the moment
there is already meta content at
https://wiki.openstack.org/wiki/Documentation/OpsGuide, Maybe the
content could live at https://wiki.openstack.org/wiki/OpsGuide? I
think it makes sense to follow the existing structure with possible
exception of culling wrong / very-out-of-date content (but perhaps
anything like that should be done as a later step and keep it simple
aiming for a "like-for-like" migration to start with)...?

2) Getting the content into the wiki. Looks like there is no obvious
up-to-date RST import functionality for MediaWiki. Pandoc seems as
though it might support some useful conversions but I didn't try this
yet and don't have any experience with it - can anyone say with
authority whether it is worth pursuing?

3) Future management - obvious can of worms given this is much better
addressed by all the tooling and scaffolding the docs team already
provides around the repos... but nonetheless some expectations may
need to be set upfront to avoid future pain.

Cheers,

On 15 July 2017 at 01:48, Alexandra Settle  wrote:
> Hi operators,
>
> Please be aware that I have proposed the following patch:
> https://review.openstack.org/#/c/483937/
>
>
>
> This removes the Operations Guide from the openstack-manuals repo and will
> no longer be accessible via docs.openstack.org after the patch merges.
>
> The documentation team does not have the resources to move the ops guide 
to
> the wiki ourselves. If you are able to work on the migration, please check
> out the ‘before-migration’ tag in the repo to access the deleted content.
> [0]
>
> Once the ops guide is migrated to the wiki, we will help you add a 
redirect
> so that the old link on docs.openstack.org will allow users to find the
> content in the new location.
>
> Thanks,
>
> Alex
>
>
>
> [0] https://github.com/openstack/openstack-manuals/tree/before-migration
>
>
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>



-- 
Cheers,
~Blairo


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

[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 

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

Re: [Openstack-operators] [OpenStack-docs] [doc] Operations Guide removal

[Blair Bethwaite]

Hi Alex,

I just managed to take a half hour to look at this and have a few
questions/comments towards making a plan for how to proceed with
moving the Ops Guide content to the wiki...

1) Need to define wiki location and structure. Curiously at the moment
there is already meta content at
https://wiki.openstack.org/wiki/Documentation/OpsGuide, Maybe the
content could live at https://wiki.openstack.org/wiki/OpsGuide? I
think it makes sense to follow the existing structure with possible
exception of culling wrong / very-out-of-date content (but perhaps
anything like that should be done as a later step and keep it simple
aiming for a "like-for-like" migration to start with)...?

2) Getting the content into the wiki. Looks like there is no obvious
up-to-date RST import functionality for MediaWiki. Pandoc seems as
though it might support some useful conversions but I didn't try this
yet and don't have any experience with it - can anyone say with
authority whether it is worth pursuing?

3) Future management - obvious can of worms given this is much better
addressed by all the tooling and scaffolding the docs team already
provides around the repos... but nonetheless some expectations may
need to be set upfront to avoid future pain.

Cheers,

On 15 July 2017 at 01:48, Alexandra Settle  wrote:
> Hi operators,
>
> Please be aware that I have proposed the following patch:
> https://review.openstack.org/#/c/483937/
>
>
>
> This removes the Operations Guide from the openstack-manuals repo and will
> no longer be accessible via docs.openstack.org after the patch merges.
>
> The documentation team does not have the resources to move the ops guide to
> the wiki ourselves. If you are able to work on the migration, please check
> out the ‘before-migration’ tag in the repo to access the deleted content.
> [0]
>
> Once the ops guide is migrated to the wiki, we will help you add a redirect
> so that the old link on docs.openstack.org will allow users to find the
> content in the new location.
>
> Thanks,
>
> Alex
>
>
>
> [0] https://github.com/openstack/openstack-manuals/tree/before-migration
>
>
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>



-- 
Cheers,
~Blairo

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

[Openstack-operators] [scientific] Scientific WG IRC Meeting today: Lustre on OpenStack

[Stig Telfer]

Hi All - 

We have a Scientific WG IRC meeting today at 1100 UTC (ie, about 40 minutes 
time) in channel #openstack-meeting.  The agenda is available here:

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


Today we have a guest speaker, James Beal from the Wellcome Trust Sanger 
Institute, who will be talking about his  recent research on using the Lustre 
parallel filesystem in OpenStack.  A link to his presentation is here:

https://docs.google.com/presentation/d/1kGRzcdVQX95abei1bDVoRzxyC02i89_m5_sOfp8Aq6o/edit#slide=id.g22aee564af_0_0
 


Everyone is welcome!

Cheers,
Stig

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