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

[Chris Morgan]

I'll get these loaded and see how they look, thanks!

Chris

Sent from my iPhone

> On Aug 14, 2017, at 9:07 PM, Yuki Kasuya  wrote:
> 
> Hi Chris,
> 
> Attached is all converting files under 
> "openstack-manuals/doc/ops-guide/source".
> 
> Best regards,
> Yuki
> 
>> On 8/15/17 03:15, Chris Morgan wrote:
>> I have privileges to edit wiki pages on openstack.org
>>  so you could send me a few converted pages
>> (perhaps ones that link to each other) and I could upload them and we
>> can all look at the result and see if we like it. Happy to do that.
>> 
>> Chris
>> 
>> On Sun, Aug 13, 2017 at 9:44 PM, Yuki Kasuya > > wrote:
>> 
>>Hi,
>> 
>>How about that if some directives can be ignored (using pandoc),
>>I'll create one new ops-guide page as a example on wiki. After that
>>could you review it ? I don't know any approval to create/edit pages
>>on wiki. Or I can send you converting files. Attached is a
>>converting example.
>>And let's discuss which url is good for new ops-guides like below.
>>Which is good using file name or first header as url of wiki? And
>>which directory is fine?
>> 
>>https://wiki.openstack.org/wiki/OpsGuide
>> (as index)
>>https://wiki.openstack.org/wiki/OpsGuide/acknowledgements
>>
>>https://wiki.openstack.org/wiki/OpsGuide/app-crypt
>>
>>...
>> 
>>Best regards,
>>Yuki
>> 
>>On 8/12/17 23:38, Chris Morgan wrote:
>> 
>>I just got back from the ops meetup in Mexico City and I think I
>>volunteered to help with this ops guide transition and
>>maintaining it on
>>the wiki. So if the current output of the conversion is available
>>anywhere for review I could try being a proofreader for it. It seems
>>there is approval to put it as is on the wiki, what does that
>>require?
>> 
>>I am not very familiar with the docs build process so if we are
>>still
>>attempting to get a minimally viable conversion I may be able to
>>help
>>but will need more time to come up to speed with that.
>> 
>>Chris
>> 
>>On Thu, Aug 10, 2017 at 8:47 AM, Anne Gentle
>>>
>>>>>
>>wrote:
>> 
>>On Thu, Aug 10, 2017 at 3:09 AM, Yuki Kasuya
>>>
>>>>> wrote:
>>> Hi,
>>>
>>>
>>> On 7/19/17 23:51, Anne Gentle wrote:
>>>>
>>>> On Wed, Jul 19, 2017 at 5:51 AM, Doug Hellmann
>>mailto:d...@doughellmann.com>
>>>>
>>>> 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
>>  

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

[Chris Morgan]

I have privileges to edit wiki pages on openstack.org so you could send me
a few converted pages (perhaps ones that link to each other) and I could
upload them and we can all look at the result and see if we like it. Happy
to do that.

Chris

On Sun, Aug 13, 2017 at 9:44 PM, Yuki Kasuya 
wrote:

> Hi,
>
> How about that if some directives can be ignored (using pandoc), I'll
> create one new ops-guide page as a example on wiki. After that could you
> review it ? I don't know any approval to create/edit pages on wiki. Or I
> can send you converting files. Attached is a converting example.
> And let's discuss which url is good for new ops-guides like below. Which
> is good using file name or first header as url of wiki? And which directory
> is fine?
>
> https://wiki.openstack.org/wiki/OpsGuide (as index)
> https://wiki.openstack.org/wiki/OpsGuide/acknowledgements
> https://wiki.openstack.org/wiki/OpsGuide/app-crypt
> ...
>
> Best regards,
> Yuki
>
> On 8/12/17 23:38, Chris Morgan wrote:
>
>> I just got back from the ops meetup in Mexico City and I think I
>> volunteered to help with this ops guide transition and maintaining it on
>> the wiki. So if the current output of the conversion is available
>> anywhere for review I could try being a proofreader for it. It seems
>> there is approval to put it as is on the wiki, what does that require?
>>
>> I am not very familiar with the docs build process so if we are still
>> attempting to get a minimally viable conversion I may be able to help
>> but will need more time to come up to speed with that.
>>
>> Chris
>>
>> On Thu, Aug 10, 2017 at 8:47 AM, Anne Gentle
>> mailto:annegen...@justwriteclick.com>>
>> wrote:
>>
>> On Thu, Aug 10, 2017 at 3:09 AM, Yuki Kasuya
>> mailto:yu-kas...@kddi-research.jp>>
>> wrote:
>> > Hi,
>> >
>> >
>> > On 7/19/17 23:51, Anne Gentle wrote:
>> >>
>> >> On Wed, Jul 19, 2017 at 5:51 AM, Doug Hellmann
>> mailto:d...@doughellmann.com>>
>> >> 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.
>> >>
>> >
>> > I tried to convert all docs under ops-guide dir using pandoc. Like
>> below,
>> > toctree,term and some directives doesn't work after converting.
>> But, at
>> > glance, almost fine after converting.
>> > If you don't mind, I'll able to create wiki pages of ops-guide.
>> >
>> > xxx@devstack02:~/work/openstack-manuals/doc/ops-guide/source$
>> pandoc
>> > index.rst -t mediawiki -o index
>> > .wiki
>> > pandoc: ignoring unknown directive: toctree "source" (line 58,
>> column 1)
>> > pandoc: ignoring unknown role :term: in "source"

[Openstack-operators] Help us grow The Women of OpenStack

[Amy Marrich]

Did you know the Women of OpenStack isn't just for people who identify as
female, but allies as well? Well now you do and we're looking for new
members!

Our mission statement is:

The Women of OpenStack (WOO) strive to increase the diversity of the
OpenStack community by overcoming OpenStack's barrier to entry through
educational sessions, professional networking, mentorship, social
inclusion, and enhanced resource access. WOO recognizes that individuals in
minority groups are more likely to have challenges accessing the resources
it takes to learn and participate in complex technologies, which is why WOO
welcomes all women and their allies who share an interest in OpenStack,
open source, and adjacent technologies. These goals are achieved through
leading and sponsorship of educational sessions and social events that
promote inclusion in the OpenStack Community.

We follow this mission by sponsoring ongoing Mentoring throughout the year
and through the Speed Mentoring and Lunch and Learns which are held during
summit as well as other activities through the year.

Our Wiki page can be found here:
https://wiki.openstack.org/wiki/Women_of_OpenStack

And you can join our mailing list here:
http://lists.openstack.org/cgi-bin/mailman/listinfo/women-of-openstack

And of course you can join us in Freenode IRC on the #openstack-women
channel.

Come sit in on a meeting and check us out! Meetings are held every other
Monday with our next meeting scheduled for 08/21/17. You can join us with
the following information:
2000 UTC, 4 PM EDT, 3 PM CDT, 2 PM MDT, 1 PM PDT
Dial In: 1-203-277-8157 <(203)%20277-8157> or *866-619-0383
<(866)%20619-0383>  Participant: 7217256**#* Leader 4018#
webex - https://verizon2.webex.com/verizon2-en/e.php?MTID=
m0e7ba518a2d4487bc0a78d00055f62e2

And if you forget you'll get a reminder on the mailing list before hand!

Hope you join us!

Amy Marrich (spotz)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme Testing

[Tim Bell]

+1 for Boris’ suggestion. Many of us use Rally to probe our clouds and have 
significant tooling behind it to integrate with local availability reporting 
and trouble ticketing systems. It would be much easier to deploy new 
functionality such as you propose if it was integrated into an existing project 
framework (such as Rally).

Tim

From: Boris Pavlovic 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 14 August 2017 at 12:57
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: openstack-operators 
Subject: Re: [openstack-dev] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme 
Testing

Sam,

Seems like a good plan and huge topic ;)

I would as well suggest to take a look at the similar efforts in OpenStack:
- Failure injection: https://github.com/openstack/os-faults
- Rally Hooks Mechanism (to inject in rally scenarios failures): 
https://rally.readthedocs.io/en/latest/plugins/implementation/hook_and_trigger_plugins.html


Best regards,
Boris Pavlovic


On Mon, Aug 14, 2017 at 2:35 AM, Sam P 
mailto:sam47pr...@gmail.com>> wrote:
Hi All,

This is a follow up for OpenStack Extreme Testing session[1]
we did in MEX-ops-meetup.

Quick intro for those who were not there:
In this work, we proposed to add new testing framework for openstack.
This framework will provides tool for create tests with destructive
scenarios which will check for High Availability, failover and
recovery of OpenStack cloud.
Please refer the link on top of the [1] for further details.

Follow up:
We are planning periodic irc meeting and have an irc
channel for discussion. I will get back to you with those details soon.

At that session, we did not have time to discuss last 3 items,
Reference architectures
 We are discussing about the reference architecture in [2].

What sort of failures do you see today in your environment?
 Currently we are considering, service failures, backend services (mq,
DB, etc.) failures,
 Network sw failures..etc. To begin with the implementation, we are
considering to start with
 service failures. Please let us know what failures are more frequent
in your environment.

Emulation/Simulation mechanisms, etc.
 Rather than doing actual scale, load, or performance tests, we are
thinking to build a emulation/simulation mechanism
to get the predictions or result of how will openstack behave on such
situations.
This interesting idea was proposed by the Gautam and need more
discussion on this.

Please let us know you questions or comments.

Request to Mike Perez:
 We discussed about synergies with openstack assertion tags and other
efforts to do similar testing in openstack.
 Could you please give some info or pointer of previous discussions.

[1] https://etherpad.openstack.org/p/MEX-ops-extreme-testing
[2] 
https://openstack-lcoo.atlassian.net/wiki/spaces/LCOO/pages/15477787/Extreme+Testing-Vision+Arch

--- Regards,
Sampath

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [Openstack-operators] [openstack-dev] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme Testing

[Ilya Shakhat]

2017-08-14 13:41 GMT+02:00 Ghanshyam Mann :

> On Mon, Aug 14, 2017 at 7:56 PM, Boris Pavlovic  wrote:
> > Sam,
> >
> > Seems like a good plan and huge topic ;)
> >
> > I would as well suggest to take a look at the similar efforts in
> OpenStack:
> > - Failure injection: https://github.com/openstack/os-faults
>
> Yea, we are considering this lib, more details in this spec -
> https://review.openstack.org/#/c/443504/
>
> - Rally Hooks Mechanism (to inject in rally scenarios failures):
> > https://rally.readthedocs.io/en/latest/plugins/implementation/hook_and_
> trigger_plugins.html
> >
>

As a little demonstration of Rally and os-faults working together:
OpenStack reliability tests from performance documentation:
 * test plan:
https://docs.openstack.org/performance-docs/latest/test_plans/reliability/version_2/plan.html#reliability-testing-version-2
 * example of report:
https://docs.openstack.org/performance-docs/latest/test_results/reliability/version_2/reports/neutron/create_and_list_networks_with_kill_mysql_service_on_one_node/index.html

Best regards,
Ilya Shakhat
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme Testing

[Boris Pavlovic]

Sam,

Seems like a good plan and huge topic ;)

I would as well suggest to take a look at the similar efforts in OpenStack:
- Failure injection: https://github.com/openstack/os-faults
- Rally Hooks Mechanism (to inject in rally scenarios failures):
https://rally.readthedocs.io/en/latest/plugins/implementation/hook_and_trigger_plugins.html


Best regards,
Boris Pavlovic


On Mon, Aug 14, 2017 at 2:35 AM, Sam P  wrote:

> Hi All,
>
> This is a follow up for OpenStack Extreme Testing session[1]
> we did in MEX-ops-meetup.
>
> Quick intro for those who were not there:
> In this work, we proposed to add new testing framework for openstack.
> This framework will provides tool for create tests with destructive
> scenarios which will check for High Availability, failover and
> recovery of OpenStack cloud.
> Please refer the link on top of the [1] for further details.
>
> Follow up:
> We are planning periodic irc meeting and have an irc
> channel for discussion. I will get back to you with those details soon.
>
> At that session, we did not have time to discuss last 3 items,
> Reference architectures
>  We are discussing about the reference architecture in [2].
>
> What sort of failures do you see today in your environment?
>  Currently we are considering, service failures, backend services (mq,
> DB, etc.) failures,
>  Network sw failures..etc. To begin with the implementation, we are
> considering to start with
>  service failures. Please let us know what failures are more frequent
> in your environment.
>
> Emulation/Simulation mechanisms, etc.
>  Rather than doing actual scale, load, or performance tests, we are
> thinking to build a emulation/simulation mechanism
> to get the predictions or result of how will openstack behave on such
> situations.
> This interesting idea was proposed by the Gautam and need more
> discussion on this.
>
> Please let us know you questions or comments.
>
> Request to Mike Perez:
>  We discussed about synergies with openstack assertion tags and other
> efforts to do similar testing in openstack.
>  Could you please give some info or pointer of previous discussions.
>
> [1] https://etherpad.openstack.org/p/MEX-ops-extreme-testing
> [2] https://openstack-lcoo.atlassian.net/wiki/spaces/
> LCOO/pages/15477787/Extreme+Testing-Vision+Arch
>
> --- Regards,
> Sampath
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme Testing

[Sam P]

Hi All,

This is a follow up for OpenStack Extreme Testing session[1]
we did in MEX-ops-meetup.

Quick intro for those who were not there:
In this work, we proposed to add new testing framework for openstack.
This framework will provides tool for create tests with destructive
scenarios which will check for High Availability, failover and
recovery of OpenStack cloud.
Please refer the link on top of the [1] for further details.

Follow up:
We are planning periodic irc meeting and have an irc
channel for discussion. I will get back to you with those details soon.

At that session, we did not have time to discuss last 3 items,
Reference architectures
 We are discussing about the reference architecture in [2].

What sort of failures do you see today in your environment?
 Currently we are considering, service failures, backend services (mq,
DB, etc.) failures,
 Network sw failures..etc. To begin with the implementation, we are
considering to start with
 service failures. Please let us know what failures are more frequent
in your environment.

Emulation/Simulation mechanisms, etc.
 Rather than doing actual scale, load, or performance tests, we are
thinking to build a emulation/simulation mechanism
to get the predictions or result of how will openstack behave on such
situations.
This interesting idea was proposed by the Gautam and need more
discussion on this.

Please let us know you questions or comments.

Request to Mike Perez:
 We discussed about synergies with openstack assertion tags and other
efforts to do similar testing in openstack.
 Could you please give some info or pointer of previous discussions.

[1] https://etherpad.openstack.org/p/MEX-ops-extreme-testing
[2] 
https://openstack-lcoo.atlassian.net/wiki/spaces/LCOO/pages/15477787/Extreme+Testing-Vision+Arch

--- Regards,
Sampath

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