[openstack-dev] [masakari] No masakari meeting on 11/12

[Sam P]

Hi all!,
 Sorry for the late announcement. Since most of us in Berlin summit,
there will be no IRC meeting at 11/12.

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

Re: [openstack-dev] [masakari][congress] what is a host?

[Sam P]

Hi Eric,

(1) "virtual machine" is bug. This need to be corrected as physical machine
or hypervisor.
  Masakari host is a physical host/hypervisor. I will correct this.

(2) Not through masakari APIs. You have to add metadata key
'HA_Enabled=True' to each VM by using nova API.
 Masakeri monitors check for failures and send notification to masakari
API if detected any failure (i.e host, VM or process failures).
 In host failure (hypervisor down) scenario, Masakari engine get the VM
list on that hypervisor and start evacuate VMs.
 Operator can configure masakari to evacuate all VMs or only the VMs
with the metadata key   'HA_Enabled=True.
 Please see the config file [1] section [host_failure] for more details.

Let me know if you need more info on this.

[1] https://docs.openstack.org/masakari/latest/sample_config.html

--- Regards,
Sampath



On Sun, Oct 7, 2018 at 8:55 AM Eric K  wrote:

> Hi all, I'm working on a potential integration between masakari and
> congress. But I am stuck on some basic usage questions I could not
> answer in my search of docs and demos. Any clarification or references
> would be much appreciated!
>
> 1. What does a host refer to in masakari API? Here's the explanation in
> API doc:
> "Host can be any kind of virtual machine which can have compute
> service running on it."
> (https://developer.openstack.org/api-ref/instance-ha/#hosts-hosts)
>
> So is a masakari host usually a nova instance/server instead of a
> host/hypervisor?
>
> 2. Through the masakari api, how does one go about configuring a VM to
> be managed by masakari instance HA?
>
> Thanks so much!
>
> Eric Kao
>
> __
> 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 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-dev] [masakari] No meeting on next week (9/10)

[Sam P]

Hi All,
 Since most of us in Denver for PTG, there will be not meeting on 9/10.

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

Re: [openstack-dev] [Release-job-failures][masakari][release] Pre-release of openstack/masakari failed

[Sam P]

Hi Doug,
 Thanks. I will fix this.

--- Regards,
Sampath



On Fri, Aug 10, 2018 at 2:51 AM Doug Hellmann  wrote:

> Excerpts from zuul's message of 2018-08-09 17:23:01 +:
> > Build failed.
> >
> > - release-openstack-python
> http://logs.openstack.org/84/84135048cb372cbd11080fc27151949cee4e52d1/pre-release/release-openstack-python/095990b/
> : FAILURE in 8m 57s
> > - announce-release announce-release : SKIPPED
> > - propose-update-constraints propose-update-constraints : SKIPPED
> >
>
> The RC1 build for Masakari failed with this error:
>
>   error: can't copy 'etc/masakari/masakari-custom-recovery-methods.conf':
>   doesn't exist or not a regular file
>
> The packaging files need to be fixed so a new release candidate can be
> prepared. The changes will need to be made on master and then backported
> to the new stable/rocky branch.
>
> Doug
>
>
> http://logs.openstack.org/84/84135048cb372cbd11080fc27151949cee4e52d1/pre-release/release-openstack-python/095990b/ara-report/result/7459d483-48d8-414f-8830-d6411158f9a2/
>
> __
> 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 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-dev] [masakari] weekly meeting time changed

[Sam P]

Hi All,

Gentle reminder about  next Masakari meeting time.
Form next meeting (5th June), meeting will be start at 0300UTC.
Please find more details at [1].

[1] http://eavesdrop.openstack.org/#Masakari_Team_Meeting
--- 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

Re: [openstack-dev] [all][ptl][release][masakari][murano][qinling][searchlight][zaqar] reminder for rocky-1 milestone deadline

[Sam P]

Hi Doug and ALL,

Thank you for the reminder.
This was my mistake and really
​s
orry for any inconvenience this may have caused.
This will not happen again.​​
​Patches are up to review for following projects.​
>
masakari-monitors
​> ​
masakari

--- Regards,
Sampath


On Sat, Apr 21, 2018 at 3:04 AM, Doug Hellmann 
wrote:

> Excerpts from Doug Hellmann's message of 2018-04-19 09:15:49 -0400:
> > Today is the deadline for proposing a release for the Rocky-1 milestone.
> > Please don't forget to include your libraries (client or otherwise) as
> > well.
> >
> > Doug
>
> A few projects have missed the first milestone tagging deadline:
>
> ​​
>   masakari-monitors
>   masakari
>
>   murano-dashboard
>
>   qinling
>
>   searchlight-ui
>   searchlight
>
>   zaqar-ui
>   zaqar
>
> The policy on missing deadlines this cycle is changing [1]:
>
>   Projects using milestones are expected to tag at least 2 out of
>   the 3 for each cycle, or risk being dropped as an official project.
>   The release team will remind projects that miss the first milestone,
>   and force tags on any later milestones by tagging HEAD at the
>   time of the deadline.
>
> The masakari, murano, qinling, searchlight, and zaqar teams should
> consider this your reminder.
>
> We really don't want to be making decisions for you about what
> constitutes a good release, but we also do not want to have projects
> that are not preparing releases. Please keep up with the deadlines.
>
> Doug
>
> [1] https://review.openstack.org/#/c/561258
>
__
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

Re: [openstack-dev] [masakari] Introspective Instance Monitoring through QEMU Guest Agent

[Sam P]

Hi Louie,
 Thanks for bring this up.
 I add this topic to today's meeting agenda.

--- Regards,
Sampath


On Tue, Apr 24, 2018 at 5:15 AM, Kwan, Louie 
wrote:

> Submitted the following review on January 17, 2018,
>
> https://review.openstack.org/#/c/534958/
>
> Would like to know who else could be on the reviewer list ? or anything
> else is needed for the next step?
>
> Also, I am planning to attend our coming Masakari Weekly meeting,  April
> 24, 0400 UTC in #openstack-meeting
> and would like add an agenda item to  follow up how to move the  review
> forward.
>
> Thanks.
> Louie
>
> __
> 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 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

Re: [openstack-dev] [TripleO][CI][QA][HA][Eris][LCOO] Validating HA on upstream

[Sam P]

Hi All,
 Sorry, Late to the party...
 I have added myself.

--- Regards,
Sampath


On Fri, Mar 16, 2018 at 9:31 AM, Ghanshyam Mann 
wrote:

> On Thu, Mar 15, 2018 at 9:45 PM, Adam Spiers  wrote:
> > Raoul Scarazzini  wrote:
> >>
> >> On 15/03/2018 01:57, Ghanshyam Mann wrote:
> >>>
> >>> Thanks all for starting the collaboration on this which is long pending
> >>> things and we all want to have some start on this.
> >>> Myself and SamP talked about it during OPS meetup in Tokyo and we
> talked
> >>> about below draft plan-
> >>> - Update the Spec - https://review.openstack.org/#/c/443504/. which is
> >>> almost ready as per SamP and his team is working on that.
> >>> - Start the technical debate on tooling we can use/reuse like Yardstick
> >>> etc, which is more this mailing thread.
> >>> - Accept the new repo for Eris under QA and start at least something in
> >>> Rocky cycle.
> >>> I am in for having meeting on this which is really good idea. non-IRC
> >>> meeting is totally fine here. Do we have meeting place and time setup ?
> >>> -gmann
> >>
> >>
> >> Hi Ghanshyam,
> >> as I wrote earlier in the thread it's no problem for me to offer my
> >> bluejeans channel, let's sort out which timeslice can be good. I've
> >> added to the main etherpad [1] my timezone (line 53), let's do all that
> >> so that we can create the meeting invite.
> >>
> >> [1] https://etherpad.openstack.org/p/extreme-testing-contacts
> >
> >
> > Good idea!  I've added mine.  We're still missing replies from several
> > key stakeholders though (lines 62++) - probably worth getting buy-in
> > from a few more people before we organise anything.  I'm pinging a few
> > on IRC with reminders about this.
> >
>
> Thanks rasca, aspiers. I have added myself there and yea good ides to
> ping remaining on IRC.
>
> -gmann
>
> > 
> __
> > 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 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 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-dev] [masakari] Rocky work items

[Sam P]

Hi All,
  Rocky work items will be discussed in 3/20 masakari IRC meeting [1].
Current items are listed in etherpad [2] and new items, comments, questions
are welcome.
If you are not able to join IRC meeting, then please add sufficient details
to your comment
and your contacts (IRC or email) where we can reach you for further
discussion.

[1] http://eavesdrop.openstack.org/#Masakari_Team_Meeting
[2] https://etherpad.openstack.org/p/masakari-rocky-work-items

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

Re: [openstack-dev] [masakari] Masakari Project mascot ideas

[Sam P]

Thanks all. Seems like we are good to go with "St. Bernard".
I think general image is [1]. Or let me know I am wrong.
I will inform to Anne and Kendall,about our choice.

[1] https://www.min-inuzukan.com/st-bernard.html

--- Regards,
Sampath


On Wed, Mar 14, 2018 at 6:42 PM, Shewale, Bhagyashri <
bhagyashri.shew...@nttdata.com> wrote:

> +1 for St. Bernard
>
> Regards,
> Bhagyashri Shewale
>
> 
> From: Patil, Tushar <tushar.pa...@nttdata.com>
> Sent: Wednesday, March 14, 2018 7:52:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [masakari] Masakari Project mascot ideas
>
> Hi,
>
>
> Total 4 people attended last IRC meeting and all of them have voted for
> St.Bernard Dog.
>
>
> If someone has missed to vote, please vote for mascot now.
>
>
> Options:
>
> 1) Asiatic black bear
> 2) Gekko : Geckos is able to regrow it's tail when the tail is lost.
> 3) St. Bernard: St. Bernard is famous as rescue dog (Masakari rescues VM
> instances)
>
>
> Thank you.
>
>
> Regards,
>
> Tushar Patil
>
>
>
> 
> From: Bhor, Dinesh <dinesh.b...@nttdata.com>
> Sent: Wednesday, March 14, 2018 10:16:29 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [masakari] Masakari Project mascot ideas
>
>
> Hi Sampath San,
>
>
> There is one more option which we discussed in yesterdays masakari meeting
> [1]:
>
> St. Bernard(Dog) [2].
>
>
> [1] http://eavesdrop.openstack.org/meetings/masakari/2018/
> masakari.2018-03-13-04.01.log.html#l-38
>
>
> [2] https://en.wikipedia.org/wiki/St._Bernard_(dog)
>
>
> Thank you,
>
> Dinesh Bhor
>
>
> 
> From: Sam P <sam47pr...@gmail.com>
> Sent: 13 March 2018 22:19:00
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [masakari] Masakari Project mascot ideas
>
> Hi All,
>
> We started this discussion on IRC meeting few weeks ago and still no
> progress..;)
> (aspiers: thanks for the reminder!)
>
> Need mascot proposals for Masakari, see FAQ [1] for more info
> Current ideas: Origin of "Masakari" is related to hero from Japanese
> folklore [2].
> Considering that relationship and to start the process, here are few ideas,
> (1) Asiatic black bear
> (2) Gekko : Geckos is able to regrow it's tail when the tail is lost.
>
> [1] https://www.openstack.org/project-mascots/
> [http://www.openstack.org/themes/openstack/images/openstack-logo-full.png
> ]<https://www.openstack.org/project-mascots/>
>
> Project Mascots - OpenStack is open source software for ...<
> https://www.openstack.org/project-mascots/>
> www.openstack.org
> We are OpenStack. We’re also passionately developing more than 60 projects
> within OpenStack. To support each project’s unique identity and visually
> demonstrate ...
>
>
> [2] https://en.wikipedia.org/wiki/Kintar%C5%8D
>
> --- Regards,
> Sampath
>
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> 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 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

Re: [openstack-dev] [masakari] Masakari Project mascot ideas

[Sam P]

Nice idea. Thanks..
​>
3) St. > Bernard: St. Bernard is famous as rescue dog (Masakari rescues VM
instances)
​+1​
​ I will confirm in advance whether we can use this as our mascot.

--- Regards,
Sampath


On Wed, Mar 14, 2018 at 11:22 AM, Patil, Tushar <tushar.pa...@nttdata.com>
wrote:

> Hi,
>
>
> Total 4 people attended last IRC meeting and all of them have voted for
> St.Bernard Dog.
>
>
> If someone has missed to vote, please vote for mascot now.
>
>
> Options:
> 1) Asiatic black bear
>
> 2) Gekko : Geckos is able to regrow it's tail when the tail is lost.
> ​​
> 3) St. Bernard: St. Bernard is famous as rescue dog (Masakari rescues VM
> instances)
>
> Thank you.
>
>
> Regards,
>
> Tushar Patil
>
>
>
> --
> *From:* Bhor, Dinesh <dinesh.b...@nttdata.com>
> *Sent:* Wednesday, March 14, 2018 10:16:29 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [masakari] Masakari Project mascot ideas
>
>
> Hi Sampath San,
>
>
> There is one more option which we discussed in yesterdays masakari meeting
> [1]:
>
> St. Bernard(Dog) [2].
>
>
> [1] http://eavesdrop.openstack.org/meetings/masakari/2018/
> masakari.2018-03-13-04.01.log.html#l-38
>
>
> [2] https://en.wikipedia.org/wiki/St._Bernard_(dog)
>
>
> Thank you,
>
> Dinesh Bhor
>
>
> --
> *From:* Sam P <sam47pr...@gmail.com>
> *Sent:* 13 March 2018 22:19:00
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [masakari] Masakari Project mascot ideas
>
> Hi All,
>
> We started this discussion on IRC meeting few weeks ago and still no
> progress..;)
> (aspiers: thanks for the reminder!)
>
> Need mascot proposals for Masakari, see FAQ [1] for more info
>
> Current ideas: Origin of "Masakari" is related to hero from Japanese
> folklore [2].
> Considering that relationship and to start the process, here are few
> ideas,
> (1) Asiatic black bear
>
> (2) Gekko : Geckos is able to regrow it's tail when the tail is lost.
>
> [1] https://www.openstack.org/project-mascots/
> <https://www.openstack.org/project-mascots/>
> Project Mascots - OpenStack is open source software for ...
> <https://www.openstack.org/project-mascots/>
> www.openstack.org
> We are OpenStack. We’re also passionately developing more than 60 projects
> within OpenStack. To support each project’s unique identity and visually
> demonstrate ...
>
> [2] https://en.wikipedia.org/wiki/Kintar%C5%8D
>
> --- Regards,
> Sampath
>
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> 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 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-dev] [masakari] Masakari Project mascot ideas

[Sam P]

Hi All,

We started this discussion on IRC meeting few weeks ago and still no
progress..;)
​(aspiers: thanks for the reminder!)

Need mascot proposals for Masakari, see FAQ [1] for more info

Current ideas: Origin of "Masakari" is related to hero from Japanese
folklore [2].
Considering that relationship and to start the process, here are few
ideas,
(1) Asiatic black bear

(2) Gekko : Geckos is able to regrow it's tail when the tail is lost.

[1] https://www.openstack.org/project-mascots/
[2] https://en.wikipedia.org/wiki/Kintar%C5%8D

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

Re: [openstack-dev] [masakari] Any masakari folks at the PTG this week ?

[Sam P]

Hi All,
 Really sorry, I couldn't make it to PTG. However, as Dinesh said some team
members are at PTG.
 I can connect on Zoom or Skype or Hangout... etc. Let me know the time if
you are meeting up..
 Thanks..


--- Regards,
Sampath


On Thu, Mar 1, 2018 at 8:03 AM, Adam Spiers  wrote:

> My claim to being a masakari person is pretty weak, but still I'd like
> to say hello too :-)  Please ping me (aspiers on IRC) if you guys are
> meeting up!
>
>
> Bhor, Dinesh  wrote:
>
>> Hi Greg,
>>
>>
>> We below are present:
>>
>>
>> Tushar Patil(tpatil)
>>
>> Yukinori Sagara(sagara)
>>
>> Abhishek Kekane(abhishekk)
>>
>> Dinesh Bhor(Dinesh_Bhor)
>>
>>
>> Thank you,
>>
>> Dinesh Bhor
>>
>>
>> 
>> From: Waines, Greg 
>> Sent: 28 February 2018 19:22:26
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [masakari] Any masakari folks at the PTG this
>> week ?
>>
>>
>> Any masakari folks at the PTG this week ?
>>
>>
>>
>> Would be interested in meeting up and chatting,
>>
>> let me know,
>>
>> Greg.
>>
>> __
>> Disclaimer: This email and any attachments are sent in strictest
>> confidence
>> for the sole use of the addressee and may contain legally privileged,
>> confidential, and proprietary data. If you are not the intended recipient,
>> please advise the sender by replying promptly to this email and then
>> delete
>> and destroy this email and any attachments without any further use,
>> copying
>> or forwarding.
>>
>
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> 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 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

Re: [openstack-dev] [masakari] [masakari-monitors] : Intrusive Instance Monitoring through QEMU Guest Agent Design Update

[Sam P]

​Hi Louie,
 Thank you for patch and Sorry for the delay​ response.
I prefer ​option 2.
>From Masakari point of view, this is an instance event. Because, even if
some thing
wrong inside the VM, Masakari only can try to fix it by restart, rebuilt,
migrate... etc the VM.
Which are the same recovery work flow for instance failures.  Therefore, I
prefer option 2
rather than option1.
 Currently, we are discussing how to implement recovery method
customization feature [0] in
Masakari. With this feature, you may able to call external workflows for
certain failure events.
For this feature, different failure models required distinguishable events
and option 3 will not
be appropriate.

[0] https://review.openstack.org/#/c/458023/


​> 1. define a new type of event for Intrusive Instance monitoring or
> 2. add a new event within the INSTANCE_EVENTS as we may  eventually
integrate with instance monitoring  or
>3.simply reuse the LIFECYCLE/STOPPED_FAILED event ( which is what we are
implementing for now.)

--- Regards,
Sampath


On Fri, Feb 16, 2018 at 12:05 AM, Kwan, Louie 
wrote:

> We submitted the first implementation patch for the following blueprint
>
>
>
> https://blueprints.launchpad.net/openstack/?searchtext=
> intrusive-instance-monitoring
>
>
>
> i.e. https://review.openstack.org/#/c/534958/
>
>
>
> The second patch  will be pushed within a week time or so.
>
>
>
> One item we would like to seek clarification among the community is about
>  how we should integrate the notification within the masakari engine.
>
>
>
> One option is to reuse what has been defined at  masakari/engine/instance_
> events.py.
>
>
>
> e.g.
>
> def masakari_notifier(self, domain_uuid):
>
> if self.getJournalObject(domain_uuid).getSentNotification():
>
> LOG.debug('notifier.send_notification Skipped:' + domain_uuid)
>
> else:
>
> hostname = socket.gethostname()
>
> noticeType = ec.EventConstants.TYPE_VM
>
> current_time = timeutils.utcnow()
>
> event = {
>
> 'notification': {
>
> 'type': noticeType,
>
> 'hostname': hostname,
>
> 'generated_time': current_time,
>
> 'payload': {
>
> 'event': 'LIFECYCLE',
>
> 'instance_uuid': domain_uuid,
>
> 'vir_domain_event': 'STOPPED_FAILED'
>
> }
>
> }
>
> }
>
> LOG.debug(str(event))
>
> self.notifier.send_notification(CONF.callback.retry_max,
>
> CONF.callback.retry_interval,
>
> event)
>
> self.getJournalObject(domain_uuid).setSentNotification(True)
>
>
>
>
>
> ​​
> Should we
>
>
>
> 1.   define a new type of event for Intrusive Instance monitoring or
>
> 2.   add a new event within the INSTANCE_EVENTS as we may  eventually
> integrate with instance monitoring  or
>
> 3.   simply reuse the LIFECYCLE/STOPPED_FAILED event ( which is what
> we are implementing for now.)
>
>
>
> One of our reference test case is to detect application meltdown within VM
> which QEMU may not  aware the failure. The recovery should pretty much be
> the same as LIFECYCLE/STOPPED_FAILED event. What do you think?
>
>
>
> Thanks.
>
> Louie
>
>
>
> Ntoe:
>
>
>
> Here is what we got from masakari/engine/instance_events.py
>
>
>
> These are the events which needs to be processed by masakari in case of
>
> instance recovery failure.
>
> """
>
>
>
> INSTANCE_EVENTS = {
>
> # Add more events and vir_domain_events here.
>
> 'LIFECYCLE': ['STOPPED_FAILED'],
>
> 'IO_ERROR': ['IO_ERROR_REPORT']
>
> }
>
>
>
> __
> 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 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

Re: [openstack-dev] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]

[Sam P]

Hi Matthew,

 Thanks for the info.
 For Masakari, after discussing with release team, all following 3 project
will do independent
 release for Queens.
masakari   masakari
​​
masakari-monitorsmasakari
python-masakariclient   masakari

Still need 3-4 days to create stable/queens for masakari and
masakari-monitors
and python-masakariclinet can be done late today.
I will create stable/queens as soon as we merged the required patches.
Requirement update will unfreeze soon, and we will hold the requirement
updates till we create stable/queens.


--- Regards,
Sampath


On Thu, Feb 8, 2018 at 7:33 PM, Dmitry Tantsur  wrote:

> On 02/07/2018 10:31 PM, Tony Breeds wrote:
>
>> On Thu, Feb 08, 2018 at 08:18:37AM +1100, Tony Breeds wrote:
>>
>> Okay  It's safe to ignore then ;P  We should probably remove it from
>>> projects.txt if it really is empty  I'll propose that.
>>>
>>
>> Oh my bad, ironic-python-agent-builder was included as it's included as
>> an ironic project[1] NOT because it;s listed in projects.txt.  Given
>> that it's clearly not for me to remove anything.
>>
>> Having said that if the project hasn't had any updates at all since it's
>> creation in July 2017 perhaps it's no longer needed and could be
>> removed?
>>
>
> We do plan to use it, we just never had time to populate it :(
>
>
>> Yours Tony.
>>
>> [1] http://git.openstack.org/cgit/openstack/governance/tree/refe
>> rence/projects.yaml#n1539
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> 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 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-dev] [masakari] Rocky PTL Candidacy

[Sam P]

Hello everyone,

 I’m Sampath Priyankara. I would like to announce my candidacy to continue
as
PTL of Masakari for the Rocky development cycle. In Queens, we mainly
focused
on bugfixing, documentation, add new features and become an official
OpenStack
project which is one of the most important achievements from Queens.

For Rocky, I would like to continue to focus on:
- Recovery method customization feature and integration with Mistral
- OpenStack Ansible support for Masakari
- Masakari Dashboard ( Horizon plugin for Masakari)
- Continue to work with OpenStack HA team to develop OpenStack resource
  agents as an alternative for masakari-monitors.
- Ironic Bare Metal instance HA support

 While working on above development, I think it is equally important to
focus
on raising awareness and adoption of Masakari, improve diversity of the
team,
and improve cross project/community communication and support. I will make
my
best effort to find more users, more reviewers and more developers for
Masakari.

Finally, I would like to thank you all Masakari contributors for your hard
work
over past cycles, and all OpenStack community members for your valuable
comments, opportunities, and all the help you gave. Also, thank you for
considering my candidacy.

--- Regards,
Sampath
​ (samP)​
__
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

Re: [openstack-dev] [release][masakari] Need help on masakari deliverables

[Sam P]

Hi Sean,

 Thanks. That make sense.
 I will proceed masakari release as independent for Queens.
 And will push those patches to Rocky.

--- Regards,
Sampath


On Thu, Feb 1, 2018 at 12:30 AM, Sean McGinnis <sean.mcgin...@gmx.com>
wrote:

> On Thu, Feb 01, 2018 at 12:19:16AM +0900, Sam P wrote:
> > Hi release team,
> >
> >  I did not realize at the time however, I noticed that masakari does not
> > have any
> >  of it deliverables are set for Queens in [1]. Which is my fault and
> really
> > sorry for that.
> >
> > We currently have 3 deliverables,
> > masakari:
> > repos:
> > - openstack/masakari
> > masakari-monitors:
> >   repos:
> > - openstack/masakari-monitors
> > python-masakariclient:
> >   repos:
> > - openstack/python-masakariclient
> >
> >  I would like to propose those patches to openstack/releases.
> >  "Now" is a bad timing for that?
> >  Your advice is greatly appreciated.
> >
> > [1]
> > http://git.openstack.org/cgit/openstack/releases/tree/
> deliverables/queens
> >
> > --- Regards,
> > Sampath
>
>
> Hi Sampath,
>
> Since these have missed all milestones for this cycle, we do not want to
> add it
> now. Especially as we are past all freeze dates.
>
> I think at this point the best option is to release this as independent
> (under
> the deliverables/_independent directory in the openstack/releases repo)
> and we
> can get it on the normal cycle-with-milestones or cycle-with-intermediary
> sequence in Rocky.
>
> Make sense?
>
> Any questions, feel free to drop in #openstack-release. Or we can continue
> here
> of course.
>
> Thanks,
> Sean
>
> __
> 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 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-dev] [release][masakari] Need help on masakari deliverables

[Sam P]

Hi release team,

 I did not realize at the time however, I noticed that masakari does not
have any
 of it deliverables are set for Queens in [1]. Which is my fault and really
sorry for that.

We currently have 3 deliverables,
masakari:
repos:
- openstack/masakari
masakari-monitors:
  repos:
- openstack/masakari-monitors
python-masakariclient:
  repos:
- openstack/python-masakariclient

 I would like to propose those patches to openstack/releases.
 "Now" is a bad timing for that?
 Your advice is greatly appreciated.

[1]
http://git.openstack.org/cgit/openstack/releases/tree/deliverables/queens

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

Re: [openstack-dev] [masakari] [Release-job-failures] Tag of openstack/masakari failed

[Sam P]

Hi Sean,

 Thanks for the advice. Above fix has merged.

--- Regards,
Sampath


On Wed, Jan 31, 2018 at 9:39 PM, Sean McGinnis 
wrote:

> Masakari had a release job fail for publishing the release notes. It
> appears to
> be due to the release notes not being updated to follow the latest
> requirements
> with the changes that were done in the zuul job.
>
> There is an outstanding patch in openstack/masakari that should fix this:
>
> https://review.openstack.org/#/c/520887/
>
> Thanks,
> Sean
>
> - Forwarded message from z...@openstack.org -
>
> Date: Wed, 31 Jan 2018 09:56:58 +
> From: z...@openstack.org
> To: release-job-failu...@lists.openstack.org
> Subject: [Release-job-failures] Tag of openstack/masakari failed
> Reply-To: openstack-dev@lists.openstack.org
>
> Build failed.
>
> - publish-openstack-releasenotes http://logs.openstack.org/6b/
> 6b10645d92e7560efc088f7f09991d332af7096f/tag/publish-
> openstack-releasenotes/de4278d/ : FAILURE in 3m 46s
>
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
>
> - End forwarded message -
>
> __
> 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 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

Re: [openstack-dev] [tc][masakari][api] masakari service-type, docs, api-ref and releasenotes

[Sam P]

Hi Monty,
 Thanks for the patches.
 Agree that 'ha' is a pretty broad service-type for Masakari.
 compute-ha or instance-ha are both OK, as  Andreas proposed,
 I would like to change it to instance-ha.
 If no objections, I will fix the python-masakariclient, devstack
pulgin etc.. from masakari side.
--- Regards,
Sampath



On Thu, Jan 18, 2018 at 4:42 PM, Andreas Jaeger  wrote:
> On 2018-01-17 20:23, Monty Taylor wrote:
>> Hey everybody,
>>
>> I noticed today while preparing patches to projects that are using
>> openstacksdk that masakari is not listed in service-types-authority. [0]
>>
>> I pushed up a patch to fix that [1] as well as to add api-ref, docs and
>> releasenotes jobs to the masakari repo so that each of those will be
>> published appropriately.
>>
>> As part of doing this, it came up that 'ha' is a pretty broad
>> service-type and that perhaps it should be 'compute-ha' or 'instance-ha'.
>>
>> The service-type is a unique key for identifying a service in the
>> catalog, so the same service-type cannot be shared amongst openstack
>> services. It is also used for api-ref publication (to
>> https://developer.openstack.org/api-ref/{service-type} ) - and in
>> openstacksdk as the name used for the service attribute on the
>> Connection object. (So the service-type 'ha' would result in having
>> conn.ha on an openstack.connection.Connection)
>>
>> We do support specifying historical aliases. Since masakari has been
>> using ha up until now, we'll need to list is in the aliases at the very
>> least.
>>
>> Do we want to change it? What should we change it to?
>
> Yes, I would change it - instance-ha sounds best seeing that the
> governance file has:
> "  service: Instances High Availability Service"
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>

__
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

Re: [openstack-dev] [masakari] A current high-level description of masakari architecture

[Sam P]

Hi Greg,

 [1] is pretty out-of-date, and [2] much closer what we have now.
 Plus, I am updating [2] with current details, for Masakari Project On
boarding session.
 I will update the wiki and share the slides soon.
 Till then, [2] is the best options we have now..
 [1] 
https://www.slideshare.net/masahito12/masakari-virtual-machine-high-availability-for-openstack
 [2] https://wiki.openstack.org/wiki/Masakari#Architecture
--- Regards,
Sampath



On Thu, Nov 2, 2017 at 7:50 AM, Waines, Greg  wrote:
> Is there a ‘current’ high-level description of the openstack masakari
> architecture ?
>
>
>
> I can only find these:
>
> https://wiki.openstack.org/wiki/Masakari#Architecture
>
> https://www.slideshare.net/masahito12/masakari-virtual-machine-high-availability-for-openstack
>
> but i am pretty sure these are out-of-date.
>
>
>
> let me know,
>
> Greg.
>
>
> __
> 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 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

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

[Sam P]

Hi Boris,

 Thanks for comment.
 Sorry for the misleading context in the etherpad. It sounds like Eris
will do everything, but it is not.
 I think I need to add more details to etherpad (I will do that)
 Short answer is we are not into  "reinventing wheels" and we will use
all possible existing tools.
 # Me and Gautam are working on a document about what are the gaps,
and what tool should use on what purpose and why.
 # I think that would be the long answer and  we definitely need your
feed back on this.
 #  I will share that here..

 For, Rally,
  Actually we are using Rally in Eris. Here is the PoC we are working on (WIP).
 # At this point, PoC is in it's very early stage. Not all the
Concepts are implemented yet..
  code: https://github.com/gautamdivgi/eris
  doc: 
https://openstack-lcoo.atlassian.net/wiki/spaces/LCOO/pages/22872097/Extreme+Testing+Demo

 You may find lot more doc's about Eris in here,
 
https://openstack-lcoo.atlassian.net/wiki/spaces/LCOO/pages/13393034/Eris+-+Extreme+Testing+Framework+for+OpenStack

 For an example, we are considering,
 Rally: For control plane load injection (Current PoC we don't use Rally
 Shaker: For data plane load injection
 os-fault: fault injection ( lot of work need to be done here)

 Here is a one example:
 Eris is focus on realistic outage scenarios such as, SDN controller
failure, Storage back-end failure, infra L2/L3 SW failure ,etc,,
 If those are vendor specific appliances, then how should we do
failure injection and metrics gathering?
 Eris will provide plugin mechanism to plug vendor drivers ( provide
by the vendor).
 In testing, Eris will use Rally and Shaker for load generation and
inject deterministic/random HW/SW failures in those
 appliances and gather the metrics. Then,  Eris (or Rally or any other
tool or mix of them) can analyze the result and
 create the final report.

 Sorry for ranting.

--- Regards,
Sampath



On Wed, Nov 1, 2017 at 4:02 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:
> Sam,
>
>>  Etherpad: https://etherpad.openstack.org/p/SYD-extreme-testing
>
>
> I really don't want to sound like a person that say use Rally my best ever
> project blablbab and other BS.
> I think that "reinventing wheels" approach is how humanity evolves and
> that's why I like this effort in any case.
>
> But really, I read carefully etherpad and I really see in description of
> Eris just plain Rally as is:
>
> - Rally allows you to create tests as YAML
> - Rally allows you to inject in various actions during the load (Rally
> Hooks) which makes it easy to do chaos and other kind of testing
> - Rally is pluggable and you can write even your own Runners (scenario
> executors) that will generate load pattern that you need
> - Rally has SLAs plugins (that can deeply analyze result of test cases) and
> say whatever they pass or not
> - We are working on feature that allows you to mix different workloads in
> parallel (and generate more realistic load)
> -.
>
> So it would be really nice if you can share gaps that you faced that are
> blocking you to use directly Rally..
>
> Thanks!
>
> Best regards,
> Boris Pavlovic
>
>
> On Tue, Oct 31, 2017 at 10:50 PM, Sam P <sam47pr...@gmail.com> wrote:
>>
>> Hi All,
>>
>>  Sending out a gentle reminder of Sydney Summit Forum Session
>> regarding this topic.
>>
>>  Extreme/Destructive Testing
>>  Tuesday, November 7, 1:50pm-2:30pm
>>  Sydney Convention and Exhibition Centre - Level 4 - C4.11
>>
>> [https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20470/extremedestructive-testing]
>>  Eatherpad: https://etherpad.openstack.org/p/SYD-extreme-testing
>>
>>  Your participation in this session would be greatly appreciated.
>> --- Regards,
>> Sampath
>>
>>
>>
>> On Mon, Aug 14, 2017 at 11:43 PM, Tim Bell <tim.b...@cern.ch> wrote:
>> > +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 <bo...@pavlovic.me>
>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> > <openstack-dev@lists.openstack.org>
>> > Date: Monday, 14 August 2017 at 12:57
>> > To: "OpenStack Development Mailing List (not for usage questions)"
>> > <openstack-dev@lists.openst

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

[Sam P]

Hi All,

 Sending out a gentle reminder of Sydney Summit Forum Session
regarding this topic.

 Extreme/Destructive Testing
 Tuesday, November 7, 1:50pm-2:30pm
 Sydney Convention and Exhibition Centre - Level 4 - C4.11
 
[https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20470/extremedestructive-testing]
 Eatherpad: https://etherpad.openstack.org/p/SYD-extreme-testing

 Your participation in this session would be greatly appreciated.
--- Regards,
Sampath



On Mon, Aug 14, 2017 at 11:43 PM, Tim Bell <tim.b...@cern.ch> wrote:
> +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 <bo...@pavlovic.me>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: Monday, 14 August 2017 at 12:57
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Cc: openstack-operators <openstack-operat...@lists.openstack.org>
> 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 <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 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 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-dev] [masakari] Propose changes of the core team

[Sam P]

Hi All Masakari Cores,

 I would like to propose following changes to Masakari core team.

Current core team:
Masahito Muroi
Rikimaru Honjo
Sampath Priyankara (samP)
Takashi Kajinami
Toshikazu Ichikawa
Tushar Patil
Yukinori Sagara

(A) Proposed to remove from Core team:
(1) Toshikazu Ichikawa
 He was one of the initial members of the project and did a great work
on design the initial Masakari API and Masakari architecture.
However, he is no longer a active member of the community.
I would like to take this opportunity to thank Toshikazu for his work
on Masakari.

(B) Confirm your availability as Core member:
 Following members, please confirm your ability to contribute to
Masakari in Queens and future cycles.
(1) Takashi Kajinami
(2) Masahito Muroi
I understand that you are extremely busy with other tasks or other projects
in OpenStack. If it is difficult for you to contribute to Masakari,
I suggest that you step down from core team for now. In future, if you are
wish to participate again, then we can discuss about reinstate you as a core
member of the team.

(C) Add to new members to core team:
(1) Adam Spiers (Suse)
  I would like to add  Adam to core team. He is the current maintainer
of the openstack-resource-agents and leader of the OpenStack HA team.
Considering his technical knowledge of the subject, and past work he
has done in Masakari and related work[1][2],
I think Adam is one of the best persons we can have in our team.

(2) Kengo Takahara (NTT-TX)
 Kengo has been an active contributor to the Masakari project from Newton
 and heavily contribute to crate masakari-monitors and python-masakariclient
 from scratch [3].

All Masakari core members, please respond with your comments and objections.
Please cast your vote on (A) and (C).

[1] 
https://review.openstack.org/#/q/project:openstack/openstack-resource-agents-specs
[2] https://etherpad.openstack.org/p/newton-instance-ha
[3] 
http://stackalytics.com/?project_type=all=all=commits_id=takahara.kengo@as.ntts.co.jp

--- 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-dev] [all][masakari] Masakari accepted into official projects

[Sam P]

Hi All,

 I am happy to announce that Masakari [1] (Instances High Availability Service)
 has become official OpenStack from last week[2].

  I would like to take this opportunity to thank, all Masakari
contributors for your
hard work over the past years, and all OpenStack community members for your
valuable comments, opportunities, and all the help you gave us.  Special thanks
goes to all the people who review and improve the application [2], and
spent your
valuable time to discuss with us on Queens PTG, IRC, ML. And, I
greatly appreciate
all the support from OpenStack HA community from the beginning of this
project.
This would not have been possible without your help.
Once again a very BIG thank you all!

Currently, we have weekly IRC meeting[3], and feel free to reach out us
on IRC #openstack-masakari on freenode, or opensack-dev ML with [masakari].
You all are welcome!!!

[1] https://wiki.openstack.org/wiki/Masakari
[2] https://review.openstack.org/#/c/500118/
[3] https://wiki.openstack.org/wiki/Meetings/Masakari

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

Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms

[Sam P]

Hi Kendall,
 Thank you..
--- Regards,
Sampath



On Thu, Oct 12, 2017 at 1:57 AM, Kendall Nelson <kennelso...@gmail.com> wrote:
> Hello :)
>
> Congrats! I added you/Masakari to my list.
>
> -Kendall (diablo_rojo)
>
> On Wed, Oct 11, 2017 at 12:28 AM Sam P <sam47pr...@gmail.com> wrote:
>>
>> Hi Kendall,
>>
>>  Thank you for info.
>>  If slots are still available, we would like to do an On-boarding
>> session for Masakari [1].
>>  # BTW, got the TC approval yesterday [2]...
>>
>>
>> [1] https://wiki.openstack.org/wiki/Masakari
>> [2] https://review.openstack.org/#/c/500118/
>> --- Regards,
>> Sampath
>>
>>
>>
>> On Wed, Oct 11, 2017 at 5:12 AM, Kendall Nelson <kennelso...@gmail.com>
>> wrote:
>> > Of course :) I added Designate.
>> >
>> > -Kendall Nelson(diablo_rojo)
>> >
>> >
>> > On Tue, Oct 10, 2017 at 1:01 PM Graham Hayes <g...@ham.ie> wrote:
>> >>
>> >> Can I add designate? I will be there to look after the room.
>> >>
>> >> Thanks,
>> >>
>> >> Graham
>> >>
>> >>
>> >> On Tue, 10 Oct 2017, at 20:20, Kendall Nelson wrote:
>> >>
>> >> Added :)
>> >> -Kendall (diablo_rojo)
>> >>
>> >> On Tue, Oct 10, 2017 at 2:11 AM Spyros Trigazis <strig...@gmail.com>
>> >> wrote:
>> >>
>> >> Magnum - Spyros Trigazis - <strig...@gmail.com>
>> >>
>> >> Thanks!
>> >>
>> >> On 9 October 2017 at 23:24, Kendall Nelson <kennelso...@gmail.com>
>> >> wrote:
>> >> > Wanted to keep this thread towards the top of inboxes for those I
>> >> > haven't
>> >> > heard from yet.
>> >> >
>> >> > About a 1/4 of the way booked, so there are still slots available!
>> >> >
>> >> > -Kendall (diablo_rojo)
>> >> >
>> >> >
>> >> > On Thu, Oct 5, 2017 at 8:50 AM Kendall Nelson <kennelso...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hello :)
>> >> >>
>> >> >> We have a little over 40 slots available so we should be able to
>> >> >> accommodate almost everyone, but it will be a first response first
>> >> >> serve
>> >> >> basis.
>> >> >>
>> >> >> Logistics: Slots are 40 min long and will have projection set up in
>> >> >> them.
>> >> >> The rooms have a capacity of about 40 people and will be set up
>> >> >> classroom
>> >> >> style.
>> >> >>
>> >> >> If you are interested in reserving a spot, just reply directly to me
>> >> >> and I
>> >> >> will put your project on the list. Please let me know if you want
>> >> >> one
>> >> >> and
>> >> >> also include the names and emails anyone that will be speaking with
>> >> >> you.
>> >> >>
>> >> >> When slots run out, they run out.
>> >> >>
>> >> >> Thanks!
>> >> >>
>> >> >> -Kendall Nelson (diablo_rojo)
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > __
>> >> > 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 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 Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman

Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms

[Sam P]

Hi Kendall,

 Thank you for info.
 If slots are still available, we would like to do an On-boarding
session for Masakari [1].
 # BTW, got the TC approval yesterday [2]...


[1] https://wiki.openstack.org/wiki/Masakari
[2] https://review.openstack.org/#/c/500118/
--- Regards,
Sampath



On Wed, Oct 11, 2017 at 5:12 AM, Kendall Nelson  wrote:
> Of course :) I added Designate.
>
> -Kendall Nelson(diablo_rojo)
>
>
> On Tue, Oct 10, 2017 at 1:01 PM Graham Hayes  wrote:
>>
>> Can I add designate? I will be there to look after the room.
>>
>> Thanks,
>>
>> Graham
>>
>>
>> On Tue, 10 Oct 2017, at 20:20, Kendall Nelson wrote:
>>
>> Added :)
>> -Kendall (diablo_rojo)
>>
>> On Tue, Oct 10, 2017 at 2:11 AM Spyros Trigazis 
>> wrote:
>>
>> Magnum - Spyros Trigazis - 
>>
>> Thanks!
>>
>> On 9 October 2017 at 23:24, Kendall Nelson  wrote:
>> > Wanted to keep this thread towards the top of inboxes for those I
>> > haven't
>> > heard from yet.
>> >
>> > About a 1/4 of the way booked, so there are still slots available!
>> >
>> > -Kendall (diablo_rojo)
>> >
>> >
>> > On Thu, Oct 5, 2017 at 8:50 AM Kendall Nelson 
>> > wrote:
>> >>
>> >> Hello :)
>> >>
>> >> We have a little over 40 slots available so we should be able to
>> >> accommodate almost everyone, but it will be a first response first
>> >> serve
>> >> basis.
>> >>
>> >> Logistics: Slots are 40 min long and will have projection set up in
>> >> them.
>> >> The rooms have a capacity of about 40 people and will be set up
>> >> classroom
>> >> style.
>> >>
>> >> If you are interested in reserving a spot, just reply directly to me
>> >> and I
>> >> will put your project on the list. Please let me know if you want one
>> >> and
>> >> also include the names and emails anyone that will be speaking with
>> >> you.
>> >>
>> >> When slots run out, they run out.
>> >>
>> >> Thanks!
>> >>
>> >> -Kendall Nelson (diablo_rojo)
>> >
>> >
>> >
>> > __
>> > 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 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 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 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 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 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

Re: [openstack-dev] [masakari] No IRC meeting this week

[Sam P]

Hi All,

 We are planning to have meeting on Sep 14 Thursday 4:00-5:00pm in
Ballroom C in PTG venue.
 Place and time might change suddenly. In that case I will send
updates to this thread.
--- Regards,
Sampath



On Mon, Sep 11, 2017 at 7:05 PM, Sam P <sam47pr...@gmail.com> wrote:
> Hi All,
>
>  As we discussed in our last week IRC meeting, there will be no IRC
> meting today.
> I will check the possible/available space in PTG venue and send
> details for PTG meetup.
> [1] is the agenda for the meeting.
>
> [1] https://etherpad.openstack.org/p/masakari-queens-workitems
> --- 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-dev] [masakari] No IRC meeting this week

[Sam P]

Hi All,

 As we discussed in our last week IRC meeting, there will be no IRC
meting today.
I will check the possible/available space in PTG venue and send
details for PTG meetup.
[1] is the agenda for the meeting.

[1] https://etherpad.openstack.org/p/masakari-queens-workitems
--- 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

Re: [openstack-dev] [tc][masakari] new project teams application for Masakari

[Sam P]

Hi Dims. Thanks, done.

Hi Tim,

Thanks for the question.
In OpenStack HA community, we discussed about converged upstream
solution for 3 cycles now [1][2]. Adam Spiers and I present our findings and
proposal in Boston summit [3]. Comparison with other F/OSS solutions are
in [4] and, as the HA community we presented our unified architecture.
Our unified solution for compute node failure scenario is in [5],
where Masakari is a key component of the architecture. For other
failure scenarios such as, process failure or instance failure, only
Masakari can
recover instances.  From all the discussions I had with community
members so far,
I  think Masakari is the right solution to address VMs HA.
Or otherwise, anyone is welcome to raise their concerns now.
I will be happy to discuss them.

[1] https://etherpad.openstack.org/p/newton-instance-ha
[2] 
https://review.openstack.org/#/q/project:openstack/openstack-resource-agents-specs
[3] 
https://www.openstack.org/videos/boston-2017/high-availability-for-instances-moving-to-a-converged-upstream-solution
[4] 
https://aspiers.github.io/openstack-summit-2017-boston-compute-ha/#/comparison
[5] 
https://aspiers.github.io/openstack-summit-2017-boston-compute-ha/#/grand-unified-architecture




--- Regards,
Sampath



On Sat, Sep 2, 2017 at 3:30 AM, Tim Bell <tim.b...@cern.ch> wrote:
> Great to see efforts for this use case.
>
> Is there community convergence that Masakari is the solution to address VMs 
> high availability?
>
> Tim
>
> -Original Message-
> From: Sam P <sam47pr...@gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Date: Friday, 1 September 2017 at 19:27
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [tc][masakari] new project teams application for 
>   Masakari
>
> Hi All,
>
> I have just proposed inclusion of Masakari[1] (Instances High Availability
> Service) into list of official OpenStack projects in [2]. Regarding this
> proposal, I would like to ask OpenStack community for what else can be 
> improved
> in the project to meet all the necessary requirements.
>
> And I would like use this thread to extend the discussion about project
> masakari. It would be great if you can post your comments/questions in 
> [2] or in
> this thread. I would be happy to discuss and answer to your questions.
>
> I will be at PTG in Denver from 9/12 (Tuesday) to 9/14(Thursday). Other 
> Masakari
> team members also will be there at PTG. We are happy to discuss anything
> regarding to Masakari in PTG.
> Please contact us via freenode IRC @ #openstack-masakari, or 
> openstack-dev ML
> with prefix [masakari].
>
> Thank you.
>
> [1] https://wiki.openstack.org/wiki/Masakari
> [2] https://review.openstack.org/#/c/500118/
>
> --- 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 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 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-dev] [tc][masakari] new project teams application for Masakari

[Sam P]

Hi All,

I have just proposed inclusion of Masakari[1] (Instances High Availability
Service) into list of official OpenStack projects in [2]. Regarding this
proposal, I would like to ask OpenStack community for what else can be improved
in the project to meet all the necessary requirements.

And I would like use this thread to extend the discussion about project
masakari. It would be great if you can post your comments/questions in [2] or in
this thread. I would be happy to discuss and answer to your questions.

I will be at PTG in Denver from 9/12 (Tuesday) to 9/14(Thursday). Other Masakari
team members also will be there at PTG. We are happy to discuss anything
regarding to Masakari in PTG.
Please contact us via freenode IRC @ #openstack-masakari, or openstack-dev ML
with prefix [masakari].

Thank you.

[1] https://wiki.openstack.org/wiki/Masakari
[2] https://review.openstack.org/#/c/500118/

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

Re: [openstack-dev] [masakari]I withdraw my remark of today's IRC meerting.

[Sam P]

Hi Rikimaru,

 Thank you for verification.

--- Regards,
Sampath



On Tue, Aug 15, 2017 at 7:37 PM, Rikimaru Honjo
 wrote:
> Hello,
>
> In today's Masakari IRC meeting, I said that executing masakari notification
> API was failed in the latest devstack environment[1].
>
> I rebuilt my environment after that.
> As a result, I couldn't reproduce the issue.
>
> So I don't report it to launchpad.
> Sorry.
>
> [1]
> http://eavesdrop.openstack.org/meetings/masakari/2017/masakari.2017-08-15-04.00.log.html#l-132
>
> Best regards,
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> Rikimaru Honjo
> E-mail:honjo.rikim...@po.ntt-tx.co.jp
>
>
>
> __
> 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 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-dev] [masakari] Make 'error' instances recovery configurable

[Sam P]

Hi Dinesh and Rikimaru,

 It seems that Dinesh[1] and Rikimaru [2] pushed a patch to fix same
issue. Thank you for your effort. Please discuss and merge them into
one patch.

[1] https://review.openstack.org/#/c/493534/
[2] https://review.openstack.org/#/c/493476/

--- 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-dev] [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 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

Re: [openstack-dev] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

[Sam P]

Hi Tony,
 Thanks.
> - Abandon: https://review.openstack.org/457491
> - Merge  : https://review.openstack.org/492965
Done.

--- Regards,
Sampath



On Sat, Aug 12, 2017 at 8:13 AM, Tony Breeds <t...@bakeyournoodle.com> wrote:
> On Fri, Aug 11, 2017 at 12:23:12AM -0500, Sam P wrote:
>> Hi Tony,
>>
>> Correction:
>> >> You can take that or:
>> >> https://review.openstack.org/#/c/457491/
>> > Thanks for the update and I will try to merge #/c/457491 asap.
>> > Otherwise I will resolve the merge conflicts.
>> I did not realize that you add [1] depends on [2]. I will wait for [2]
>> to get merged.
>
> Okay that's all done.  Please:
> - Abandon: https://review.openstack.org/457491
> - Merge  : https://review.openstack.org/492965
>
> Then you're good to go :)
>
> Yours Tony.
>
> __
> 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 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

Re: [openstack-dev] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

[Sam P]

Hi Tony,

Correction:
>> You can take that or:
>> https://review.openstack.org/#/c/457491/
> Thanks for the update and I will try to merge #/c/457491 asap.
> Otherwise I will resolve the merge conflicts.
I did not realize that you add [1] depends on [2]. I will wait for [2]
to get merged.

[1] https://review.openstack.org/#/c/457491
[2] https://review.openstack.org/#/c/491692/
--- Regards,
Sampath



On Thu, Aug 10, 2017 at 11:59 PM, Sam P <sam47pr...@gmail.com> wrote:
> Hi Tony,
>
>  As you suggested, I would like go with option 1.
>
>> Once that merges the bot will suggest a review to update your
>> requirements files.
>>
>> You can take that or:
>> https://review.openstack.org/#/c/457491/
> Thanks for the update and I will try to merge #/c/457491 asap.
> Otherwise I will resolve the merge conflicts.
>
>> Apart from the change described above you're right.  You need to block
>> and changes generated by the proposal bot from the time requirements
>> branches until you branch.
>> All good?
> All good.  Thank you for all the help and support..
>
>
> --- Regards,
> Sampath
>
>
>
> On Thu, Aug 10, 2017 at 7:08 PM, Tony Breeds <t...@bakeyournoodle.com> wrote:
>> On Thu, Aug 10, 2017 at 12:58:21PM -0500, Sam P wrote:
>>> Hi Tony,
>>>
>>> For maskari-monitors, earliest we can cut stable/pike is 8/11.
>>> You was mentioned about masakari and related projects in [1].
>>> For python-masakariclient, stable/pike can be cut on 8/11.
>>> However, for maskari I would like to land few changes before cut 
>>> stable/pike and
>>> hopefully we can cut stable/pike after 8/15 masakari team meeting.
>>>
>>>   As I discussed with Matthew[2], In the case, you unfreeze
>>> requirements before 8/15,
>>>  we can block requirements update for masakari till we create the
>>> stable/pike branch.
>>>  Any comments on this plan?
>>
>> Based on what you've said Masakari is going to have a stable/pike
>> branch.  So we have 3 options:
>>
>> 1) Grant the FFE and ensure that the bot-generated change lands in
>>masakari-monitors before they branch ; or
>>
>> 2) Wait until after both requirements and masakari branch and takes this
>>on master backport it to pike (which would kinda sorta be a process
>>violation) and then let the bot take over ; or
>>
>> 3) Just take this on master and disable the check-requirements for
>>masakari on stable/*
>>
>> It seems to me that option 1 is the least work and ends up with the best
>> result.
>>
>> So with that in mind I'm going to approve:
>> https://review.openstack.org/#/c/491692/
>>
>> Once that merges the bot will suggest a review to update your
>> requirements files.
>>
>> You can take that or:
>> https://review.openstack.org/#/c/457491/
>>
>> or some combination of both after resolving any merge conflicts.
>>
>> You'll need to do one of those before you branch stable/pike
>>
>> Apart from the change described above you're right.  You need to block
>> and changes generated by the proposal bot from the time requirements
>> branches until you branch.
>>
>> All good?
>>
>> Yours Tony.
>>
>> __
>> 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 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

Re: [openstack-dev] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

[Sam P]

Hi Tony,

 As you suggested, I would like go with option 1.

> Once that merges the bot will suggest a review to update your
> requirements files.
>
> You can take that or:
> https://review.openstack.org/#/c/457491/
Thanks for the update and I will try to merge #/c/457491 asap.
Otherwise I will resolve the merge conflicts.

> Apart from the change described above you're right.  You need to block
> and changes generated by the proposal bot from the time requirements
> branches until you branch.
> All good?
All good.  Thank you for all the help and support..


--- Regards,
Sampath



On Thu, Aug 10, 2017 at 7:08 PM, Tony Breeds <t...@bakeyournoodle.com> wrote:
> On Thu, Aug 10, 2017 at 12:58:21PM -0500, Sam P wrote:
>> Hi Tony,
>>
>> For maskari-monitors, earliest we can cut stable/pike is 8/11.
>> You was mentioned about masakari and related projects in [1].
>> For python-masakariclient, stable/pike can be cut on 8/11.
>> However, for maskari I would like to land few changes before cut stable/pike 
>> and
>> hopefully we can cut stable/pike after 8/15 masakari team meeting.
>>
>>   As I discussed with Matthew[2], In the case, you unfreeze
>> requirements before 8/15,
>>  we can block requirements update for masakari till we create the
>> stable/pike branch.
>>  Any comments on this plan?
>
> Based on what you've said Masakari is going to have a stable/pike
> branch.  So we have 3 options:
>
> 1) Grant the FFE and ensure that the bot-generated change lands in
>masakari-monitors before they branch ; or
>
> 2) Wait until after both requirements and masakari branch and takes this
>on master backport it to pike (which would kinda sorta be a process
>violation) and then let the bot take over ; or
>
> 3) Just take this on master and disable the check-requirements for
>masakari on stable/*
>
> It seems to me that option 1 is the least work and ends up with the best
> result.
>
> So with that in mind I'm going to approve:
> https://review.openstack.org/#/c/491692/
>
> Once that merges the bot will suggest a review to update your
> requirements files.
>
> You can take that or:
> https://review.openstack.org/#/c/457491/
>
> or some combination of both after resolving any merge conflicts.
>
> You'll need to do one of those before you branch stable/pike
>
> Apart from the change described above you're right.  You need to block
> and changes generated by the proposal bot from the time requirements
> branches until you branch.
>
> All good?
>
> Yours Tony.
>
> __
> 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 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

Re: [openstack-dev] [masakari]Remove ERROR instances from recovery targets

[Sam P]

Hi Rikimaru,

 Currently, [1] does not skip error instances from evacuating.
 However, it does make it back to error after evacuating the instance.
 If your requirement does not satisfied with that, then the next option will be
 create a option for not to evacuate error VMs first place.
 Because, solution proposed in [1], there will be small chance that
the VM will be
 active for a small time and it will cause critical problems in
1ACT/n SBY or any HA model.

[1] https://review.openstack.org/#/c/469029/
--- Regards,
Sampath



On Tue, Jul 11, 2017 at 2:51 AM, Rikimaru Honjo
 wrote:
> Hello all,
>
> Current Masakari also rescues ERROR instances when host failure happen.
> Those instances will be changed to ACTIVE after rescued.[1]
>
> But I think that some users don't want to rescue ERROR instances.
> For example, if user is running 1ACT/n SBY application on instances,
> launching ERROR instances will cause unexpected effect.
>
> So I want to add a configurable option.
> ERROR instances won't be rescued if the option is set.
>
> Please talk your opinion about this issue.
>
> P.S.
> I talked about this issue in IRC meeting.
> http://eavesdrop.openstack.org/meetings/masakari/2017/masakari.2017-07-11-04.00.log.html
> But time was up at that time.
>
> [1]
> This is Evacuate API's behavior.
>
> [2]
> There is a possibility that following patch resolve this issue,
> but that will take time.
> https://review.openstack.org/#/c/469029/
>
> Best regards,
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> Rikmaru Honjo
> E-mail:honjo.rikim...@po.ntt-tx.co.jp
>
>
>
> __
> 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 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

Re: [openstack-dev] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

[Sam P]

Hi Tony,

For maskari-monitors, earliest we can cut stable/pike is 8/11.
You was mentioned about masakari and related projects in [1].
For python-masakariclient, stable/pike can be cut on 8/11.
However, for maskari I would like to land few changes before cut stable/pike and
hopefully we can cut stable/pike after 8/15 masakari team meeting.

  As I discussed with Matthew[2], In the case, you unfreeze
requirements before 8/15,
 we can block requirements update for masakari till we create the
stable/pike branch.
 Any comments on this plan?

> Looking at masakari-monitors the whole history can be seen on one page so 
> it's clearly very new.
I created it 10 months ago. Original code can be found in [3]. We
split [3] into masakari and masakari-monitors and
did lot of enhancements.


[1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120922.html
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-requirements/%23openstack-requirements.2017-08-10.log.html#t2017-08-10T17:11:42
[3] https://github.com/ntt-sic/masakari
--- Regards,
Sampath



On Thu, Aug 10, 2017 at 1:23 AM, Bhor, Dinesh  wrote:
> Hi Tony and all,
>
> Sorry for the delay to reply.
>
> We are planning to create the stable/pike branch soon. I am contacting the 
> PTL Sampath Priyankara(samP) for the exact date.
>
> Thanks and Regards,
> Dinesh Bhor | App. Software Dev. Cnslt.
> dinesh.b...@nttdata.com | nttdata.com/americas
>
>
> -Original Message-
> From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> Sent: Wednesday, August 09, 2017 5:25 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [requirements][masakari] FFE for adding 
> python-masakariclient in global-requirements
>
> On Wed, Aug 09, 2017 at 06:39:52AM +, Bhor, Dinesh wrote:
>> Hello everyone,
>>
>> I would like to ask for the FFE for adding "python-masakariclient" in 
>> global-requirements.
>>
>> Earlier, we were not having "check-requirements" job for masakari-* 
>> projects. At that time, we use to manually add "python-masakariclient" as a 
>> requirement in masakari-monitors project [1].
>> Now we have added "check-requirements" job for masakari-* projects,
>> but we missed to add "python-masakariclient" in global-requirements and now 
>> the bigger issue is it is not possible to manually update the 
>> "python-masakariclient" requirement in masakari-monitors project as the 
>> "gate-masakari-monitors-requirements" requirements job keeps failing on the 
>> patch [1].
>> To resolve this problem permanently, we need to add "python-masakariclient" 
>> library requirement in global-requirements.
>> I have submitted a patch [2] for adding the python-masakariclient in 
>> global-requirements.
>>
>> Please consider my request and grant FFE to solve this problem.
>>
>> [1] https://review.openstack.org/#/c/457491/
>> [2] https://review.openstack.org/#/c/491692/
>
> Are you intending to create a stable/pike branch and perform releases from 
> it?  Looking at masakari-monitors the whole history can be seen on one page 
> so it's clearly very new.
>
> Yours Tony.
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
> __
> 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 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

Re: [openstack-dev] [masakari]Where is the masakari-monitors spec repository?

[Sam P]

Hi Honjo,

 There are no dedicated spec repositories for masakari-monitors and
python-masakariclient.
 Please use the masakari-spec repository[1] for spec discussion for
those 2 projects.

 [1] https://review.openstack.org/#/q/project:openstack/masakari-specs
--- Regards,
Sampath



On Fri, Jul 14, 2017 at 4:53 PM, Rikimaru Honjo
 wrote:
> Hi all,
>
> I want to push a new spec document of masakari-monitors.
> But there is not a masakari-monitors-spec repository.
> Can I push it to masakari-spec repository?
>
> Best regards,
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> Rikimaru Honjo
> E-mail:honjo.rikim...@po.ntt-tx.co.jp
>
>
>
> __
> 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 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

Re: [openstack-dev] [vitrage] [nova] [HA] [masakari] VM Heartbeat / Healthcheck Monitoring

[Sam P]

Hi Vikash,

  Greg submit the spec [1] for intrusive instance monitoring.
  Your review will be highly appreciated..
 [1] https://review.openstack.org/#/c/469070/
--- Regards,
Sampath



On Sat, May 20, 2017 at 4:49 PM, Vikash Kumar
<vikash.ku...@oneconvergence.com> wrote:
> Thanks Sam
>
>
> On Sat, 20 May 2017, 06:51 Sam P, <sam47pr...@gmail.com> wrote:
>>
>> Hi Vikash,
>>  Great... I will add you as reviewer to this spec.
>>  Thank you..
>> --- Regards,
>> Sampath
>>
>>
>>
>> On Fri, May 19, 2017 at 1:06 PM, Vikash Kumar
>> <vikash.ku...@oneconvergence.com> wrote:
>> > Hi Greg,
>> >
>> > Please include my email in this spec also. We are also dealing with
>> > HA
>> > of Virtual Instances (especially for Vendors) and will participate.
>> >
>> > On Thu, May 18, 2017 at 11:33 PM, Waines, Greg
>> > <greg.wai...@windriver.com>
>> > wrote:
>> >>
>> >> Yes I am good with writing spec for this in masakari-spec.
>> >>
>> >>
>> >>
>> >> Do you use gerrit for this git ?
>> >>
>> >> Do you have a template for your specs ?
>> >>
>> >>
>> >>
>> >> Greg.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> From: Sam P <sam47pr...@gmail.com>
>> >> Reply-To: "openstack-dev@lists.openstack.org"
>> >> <openstack-dev@lists.openstack.org>
>> >> Date: Thursday, May 18, 2017 at 1:51 PM
>> >> To: "openstack-dev@lists.openstack.org"
>> >> <openstack-dev@lists.openstack.org>
>> >> Subject: Re: [openstack-dev] [vitrage] [nova] [HA] [masakari] VM
>> >> Heartbeat
>> >> / Healthcheck Monitoring
>> >>
>> >>
>> >>
>> >> Hi Greg,
>> >>
>> >> Thank you Adam for followup.
>> >>
>> >> This is new feature for masakari-monitors and think  Masakari can
>> >>
>> >> accommodate this feature in  masakari-monitors.
>> >>
>> >> From the implementation prospective, it is not that hard to do.
>> >>
>> >> However, as you can see in our Boston presentation, Masakari will
>> >>
>> >> replace its monitoring parts ( which is masakari-monitors) with,
>> >>
>> >> nova-host-alerter, **-process-alerter, and **-instance-alerter. (**
>> >>
>> >> part is not defined yet..:p)...
>> >>
>> >> Therefore, I would like to save this specifications, and make sure we
>> >>
>> >> will not miss  anything in the transformation..
>> >>
>> >> Does is make sense to write simple spec for this in masakari-spec [1]?
>> >>
>> >> So we can discuss about the requirements how to implement it.
>> >>
>> >>
>> >>
>> >> [1] https://github.com/openstack/masakari-specs
>> >>
>> >>
>> >>
>> >> --- Regards,
>> >>
>> >> Sampath
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, May 18, 2017 at 2:29 AM, Adam Spiers <aspi...@suse.com> wrote:
>> >>
>> >> I don't see any reason why masakari couldn't handle that, but you'd
>> >>
>> >> have to ask Sampath and the masakari team whether they would consider
>> >>
>> >> that in scope for their roadmap.
>> >>
>> >>
>> >>
>> >> Waines, Greg <greg.wai...@windriver.com> wrote:
>> >>
>> >>
>> >>
>> >> Sure.  I can propose a new user story.
>> >>
>> >>
>> >>
>> >> And then are you thinking of including this user story in the scope of
>> >>
>> >> what masakari would be looking at ?
>> >>
>> >>
>> >>
>> >> Greg.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> From: Adam Spiers <aspi...@suse.com>
>> >>
>> >> Reply-To: "openstack-dev@lists.openstack.org"
>> >>
>> >> <openstack-dev@lists.openstack.org>
>> >>
>> >> Date: Wednesday, May 17, 2017 at 10:08 AM
>> >>
>> >> To: "openstack-dev@lists.op

Re: [openstack-dev] [masakari] Intrusive Instance Monitoring

[Sam P]

Hi Greg,

 Great.. thank you. I will ask people to review this..

--- Regards,
Sampath



On Tue, May 30, 2017 at 9:06 PM, Waines, Greg <greg.wai...@windriver.com> wrote:
> Hey Sam,
>
>
>
> Was able to submit the blueprint and spec.
>
>
>
> Blueprint:
> https://blueprints.launchpad.net/masakari/+spec/intrusive-instance-monitoring
>
> Spec: https://review.openstack.org/#/c/469070/
>
>
>
> Greg.
>
>
>
> From: Sam P <sam47pr...@gmail.com>
> Reply-To: "openstack-dev@lists.openstack.org"
> <openstack-dev@lists.openstack.org>
> Date: Monday, May 29, 2017 at 10:01 PM
> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [masakari] Intrusive Instance Monitoring
>
>
>
> Hi Greg,
>
>
>
> # Thank you Jeremy..!
>
>
>
> I couldn't find any problem with repo side.
>
> As Jeremy pointed out, could you please check the `git remote show gerrit`.
>
>
>
> BTW, could you please create a BP in [1] and link it to your spec when
>
> you commit it.
>
> In this way, we could track all the changes related to this task.
>
> Please include the related bp Name in commit massage of your spec as,
>
>
>
> Implements: bp name-of-your-bp
>
> # Please refer to open to review spec [2] for more details.
>
> # You may find more details on [3]
>
>
>
> [1] https://blueprints.launchpad.net/masakari
>
> [2] https://review.openstack.org/#/c/458023/4//COMMIT_MSG
>
> [3]
> https://docs.openstack.org/infra/manual/developers.html#working-on-specifications-and-blueprints
>
> --- Regards,
>
> Sampath
>
>
>
>
>
>
>
> On Tue, May 30, 2017 at 4:39 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:
>
> On 2017-05-29 14:48:10 + (+), Waines, Greg wrote:
>
> Was just trying to submit my spec for Intrusive Instance
>
> Monitoring for review.
>
>
>
> And I get the following warning after committing when I do the
>
> ‘git review’
>
>
>
> gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git review
>
> You are about to submit multiple commits. This is expected if you are
>
> submitting a commit that is dependent on one or more in-review
>
> commits. Otherwise you should consider squashing your changes into one
>
> commit before submitting.
>
>
>
> The outstanding commits are:
>
>
>
> f09deee (HEAD -> myBranch) Initial draft specification of Intrusive Instance
> Monitoring.
>
> 21aeb96 (origin/master, origin/HEAD, master) Prepare specs repository for
> Pike
>
> 83d1a0a Implement reserved_host, auto_priority and rh_priority recovery
> methods
>
> 4e746cb Add periodic task to clean up workflow failure
>
> 2c10be4 Add spec repo structure
>
> a82016f Added .gitreview
>
>
>
> Do you really want to submit the above commits?
>
> Type 'yes' to confirm, other to cancel: no
>
> Aborting.
>
> gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$
>
>
>
> Seems like my clone picked up someone else’s open commit ?
>
>
>
> Any help would be appreciated,
>
> The full log of my git session is below,
>
> [...]
>
>
>
> The output doesn't show any open changes, but rather seems to
>
> indicate that the parent is the commit at the tip of origin/master.
>
> This condition shouldn't normally happen unless Gerrit doesn't
>
> actually know about any of those commits for some reason.
>
>
>
> One thing, I notice your `git review -s` output in your log was
>
> empty. Make sure the output of `git remote show gerrit` looks
>
> something like this (obviously with your username in place of mine):
>
>
>
>  * remote gerrit
>
>Fetch URL:
> ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
>
>Push  URL:
> ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
>
>HEAD branch: master
>
>Remote branch:
>
>  master tracked
>
>Local ref configured for 'git push':
>
>  master pushes to master (up to date)
>
>
>
> Using git-review 1.25.0 I attempted to replicate the issue like
>
> this, but everything worked normally:
>
>
>
>  fungi@dhole:~/work/openstack/openstack$ git clone
> https://github.com/openstack/masakari-specs.git
>
>  Cloning into 'masakari-specs'...
>
>  remote: Counting objects: 61, done.
>
>  remote: Total 61 (delta 0), reused 0 (delta 0), pack-reused 61
>
>  Unpacking objects: 100% (61/61), done.
>
>  fungi@dhole:~/work/openstack/openstack$ cd masakari

Re: [openstack-dev] [masakari] Intrusive Instance Monitoring

[Sam P]

Hi Greg,

# Thank you Jeremy..!

 I couldn't find any problem with repo side.
 As Jeremy pointed out, could you please check the `git remote show gerrit`.

BTW, could you please create a BP in [1] and link it to your spec when
you commit it.
In this way, we could track all the changes related to this task.
Please include the related bp Name in commit massage of your spec as,

Implements: bp name-of-your-bp
# Please refer to open to review spec [2] for more details.
# You may find more details on [3]

[1] https://blueprints.launchpad.net/masakari
[2] https://review.openstack.org/#/c/458023/4//COMMIT_MSG
[3] 
https://docs.openstack.org/infra/manual/developers.html#working-on-specifications-and-blueprints
--- Regards,
Sampath



On Tue, May 30, 2017 at 4:39 AM, Jeremy Stanley  wrote:
> On 2017-05-29 14:48:10 + (+), Waines, Greg wrote:
>> Was just trying to submit my spec for Intrusive Instance
>> Monitoring for review.
>>
>> And I get the following warning after committing when I do the
>> ‘git review’
>>
>> gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git review
>> You are about to submit multiple commits. This is expected if you are
>> submitting a commit that is dependent on one or more in-review
>> commits. Otherwise you should consider squashing your changes into one
>> commit before submitting.
>>
>> The outstanding commits are:
>>
>> f09deee (HEAD -> myBranch) Initial draft specification of Intrusive Instance 
>> Monitoring.
>> 21aeb96 (origin/master, origin/HEAD, master) Prepare specs repository for 
>> Pike
>> 83d1a0a Implement reserved_host, auto_priority and rh_priority recovery 
>> methods
>> 4e746cb Add periodic task to clean up workflow failure
>> 2c10be4 Add spec repo structure
>> a82016f Added .gitreview
>>
>> Do you really want to submit the above commits?
>> Type 'yes' to confirm, other to cancel: no
>> Aborting.
>> gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$
>>
>> Seems like my clone picked up someone else’s open commit ?
>>
>> Any help would be appreciated,
>> The full log of my git session is below,
> [...]
>
> The output doesn't show any open changes, but rather seems to
> indicate that the parent is the commit at the tip of origin/master.
> This condition shouldn't normally happen unless Gerrit doesn't
> actually know about any of those commits for some reason.
>
> One thing, I notice your `git review -s` output in your log was
> empty. Make sure the output of `git remote show gerrit` looks
> something like this (obviously with your username in place of mine):
>
> * remote gerrit
>   Fetch URL: 
> ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
>   Push  URL: 
> ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
>   HEAD branch: master
>   Remote branch:
> master tracked
>   Local ref configured for 'git push':
> master pushes to master (up to date)
>
> Using git-review 1.25.0 I attempted to replicate the issue like
> this, but everything worked normally:
>
> fungi@dhole:~/work/openstack/openstack$ git clone 
> https://github.com/openstack/masakari-specs.git
> Cloning into 'masakari-specs'...
> remote: Counting objects: 61, done.
> remote: Total 61 (delta 0), reused 0 (delta 0), pack-reused 61
> Unpacking objects: 100% (61/61), done.
> fungi@dhole:~/work/openstack/openstack$ cd masakari-specs/
> fungi@dhole:~/work/openstack/openstack/masakari-specs$ git log
> commit 21aeb965acea0b3ebe8448715bb88df4409dd402
> Author: Abhishek Kekane 
> Date:   Wed Apr 19 16:00:53 2017 +0530
>
> Prepare specs repository for Pike
>
> Add directories, index file, and template symlinks for Pike specs.
>
> Change-Id: I7dce74430e4569a5978f8f4b953db3b20125c53e
>
> commit 83d1a0aae17e4e8110ac64c7975a8520592712f9
> Author: Abhishek Kekane 
> Date:   Fri Jan 20 12:00:12 2017 +0530
>
> Implement reserved_host, auto_priority and rh_priority recovery 
> methods
>
> Implements: bp implement-recovery-methods
> Change-Id: I83ce204d8f25b240fa6ce723dc15192ae9b4e191
>
> commit 4e746cb5a39df5aa833ab32ce7ba961637753a15
> Author: Abhishek Kekane 
> Date:   Fri Jan 20 11:38:09 2017 +0530
>
> fungi@dhole:~/work/openstack/openstack/masakari-specs$ git review -s
> Creating a git remote called 'gerrit' that maps to:
> 
> ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
> fungi@dhole:~/work/openstack/openstack/masakari-specs$ git checkout -b 
> myBranch
> Switched to a new branch 'myBranch'
> fungi@dhole:~/work/openstack/openstack/masakari-specs$ cp 
> doc/source/specs/pike/implemented/pike-template.rst 
> doc/source/specs/pike/implemented/vmHeartbeat.masa
> kari.specfile.rst
> fungi@dhole:~/work/openstack/openstack/masakari-specs$ git add 
> 

Re: [openstack-dev] [vitrage] [nova] [HA] [masakari] VM Heartbeat / Healthcheck Monitoring

[Sam P]

Hi Vikash,
 Great... I will add you as reviewer to this spec.
 Thank you..
--- Regards,
Sampath



On Fri, May 19, 2017 at 1:06 PM, Vikash Kumar
<vikash.ku...@oneconvergence.com> wrote:
> Hi Greg,
>
> Please include my email in this spec also. We are also dealing with HA
> of Virtual Instances (especially for Vendors) and will participate.
>
> On Thu, May 18, 2017 at 11:33 PM, Waines, Greg <greg.wai...@windriver.com>
> wrote:
>>
>> Yes I am good with writing spec for this in masakari-spec.
>>
>>
>>
>> Do you use gerrit for this git ?
>>
>> Do you have a template for your specs ?
>>
>>
>>
>> Greg.
>>
>>
>>
>>
>>
>>
>>
>> From: Sam P <sam47pr...@gmail.com>
>> Reply-To: "openstack-dev@lists.openstack.org"
>> <openstack-dev@lists.openstack.org>
>> Date: Thursday, May 18, 2017 at 1:51 PM
>> To: "openstack-dev@lists.openstack.org"
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [vitrage] [nova] [HA] [masakari] VM Heartbeat
>> / Healthcheck Monitoring
>>
>>
>>
>> Hi Greg,
>>
>> Thank you Adam for followup.
>>
>> This is new feature for masakari-monitors and think  Masakari can
>>
>> accommodate this feature in  masakari-monitors.
>>
>> From the implementation prospective, it is not that hard to do.
>>
>> However, as you can see in our Boston presentation, Masakari will
>>
>> replace its monitoring parts ( which is masakari-monitors) with,
>>
>> nova-host-alerter, **-process-alerter, and **-instance-alerter. (**
>>
>> part is not defined yet..:p)...
>>
>> Therefore, I would like to save this specifications, and make sure we
>>
>> will not miss  anything in the transformation..
>>
>> Does is make sense to write simple spec for this in masakari-spec [1]?
>>
>> So we can discuss about the requirements how to implement it.
>>
>>
>>
>> [1] https://github.com/openstack/masakari-specs
>>
>>
>>
>> --- Regards,
>>
>> Sampath
>>
>>
>>
>>
>>
>>
>>
>> On Thu, May 18, 2017 at 2:29 AM, Adam Spiers <aspi...@suse.com> wrote:
>>
>> I don't see any reason why masakari couldn't handle that, but you'd
>>
>> have to ask Sampath and the masakari team whether they would consider
>>
>> that in scope for their roadmap.
>>
>>
>>
>> Waines, Greg <greg.wai...@windriver.com> wrote:
>>
>>
>>
>> Sure.  I can propose a new user story.
>>
>>
>>
>> And then are you thinking of including this user story in the scope of
>>
>> what masakari would be looking at ?
>>
>>
>>
>> Greg.
>>
>>
>>
>>
>>
>> From: Adam Spiers <aspi...@suse.com>
>>
>> Reply-To: "openstack-dev@lists.openstack.org"
>>
>> <openstack-dev@lists.openstack.org>
>>
>> Date: Wednesday, May 17, 2017 at 10:08 AM
>>
>> To: "openstack-dev@lists.openstack.org"
>>
>> <openstack-dev@lists.openstack.org>
>>
>> Subject: Re: [openstack-dev] [vitrage] [nova] [HA] VM Heartbeat /
>>
>> Healthcheck Monitoring
>>
>>
>>
>> Thanks for the clarification Greg.  This sounds like it has the
>>
>> potential to be a very useful capability.  May I suggest that you
>>
>> propose a new user story for it, along similar lines to this existing
>>
>> one?
>>
>>
>>
>>
>>
>>
>> http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html
>>
>>
>>
>> Waines, Greg <greg.wai...@windriver.com<mailto:greg.wai...@windriver.com>>
>>
>> wrote:
>>
>> Yes that’s correct.
>>
>> VM Heartbeating / Health-check Monitoring would introduce intrusive /
>>
>> white-box type monitoring of VMs / Instances.
>>
>>
>>
>> I realize this is somewhat in the gray-zone of what a cloud should be
>>
>> monitoring or not,
>>
>> but I believe it provides an alternative for Applications deployed in VMs
>>
>> that do not have an external monitoring/management entity like a VNF
>> Manager
>>
>> in the MANO architecture.
>>
>> And even for VMs with VNF Managers, it provides a highly reliable
>>
>> alternate monitoring path that does not rely on Tenant Networking.
>>
>>
>>
>> Y

Re: [openstack-dev] [vitrage] [nova] [HA] [masakari] VM Heartbeat / Healthcheck Monitoring

[Sam P]

Hi Greg,

 Thank you.
> Do you use gerrit for this git ?
Yes, we use gerrit, same as other openstack projects.
https://review.openstack.org/#/admin/projects/openstack/masakari-specs
Here is the list for current and past spec works.
https://review.openstack.org/#/q/project:openstack/masakari-specs

> Do you have a template for your specs ?
Yes, please see the template in pike directory.
https://github.com/openstack/masakari-specs/blob/master/doc/source/specs/pike/template.rst


--- Regards,
Sampath



On Fri, May 19, 2017 at 3:03 AM, Waines, Greg <greg.wai...@windriver.com> wrote:
> Yes I am good with writing spec for this in masakari-spec.
>
>
>
> Do you use gerrit for this git ?
>
> Do you have a template for your specs ?
>
>
>
> Greg.
>
>
>
>
>
>
>
> From: Sam P <sam47pr...@gmail.com>
> Reply-To: "openstack-dev@lists.openstack.org"
> <openstack-dev@lists.openstack.org>
> Date: Thursday, May 18, 2017 at 1:51 PM
> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [vitrage] [nova] [HA] [masakari] VM Heartbeat /
> Healthcheck Monitoring
>
>
>
> Hi Greg,
>
> Thank you Adam for followup.
>
> This is new feature for masakari-monitors and think  Masakari can
>
> accommodate this feature in  masakari-monitors.
>
> From the implementation prospective, it is not that hard to do.
>
> However, as you can see in our Boston presentation, Masakari will
>
> replace its monitoring parts ( which is masakari-monitors) with,
>
> nova-host-alerter, **-process-alerter, and **-instance-alerter. (**
>
> part is not defined yet..:p)...
>
> Therefore, I would like to save this specifications, and make sure we
>
> will not miss  anything in the transformation..
>
> Does is make sense to write simple spec for this in masakari-spec [1]?
>
> So we can discuss about the requirements how to implement it.
>
>
>
> [1] https://github.com/openstack/masakari-specs
>
>
>
> --- Regards,
>
> Sampath
>
>
>
>
>
>
>
> On Thu, May 18, 2017 at 2:29 AM, Adam Spiers <aspi...@suse.com> wrote:
>
> I don't see any reason why masakari couldn't handle that, but you'd
>
> have to ask Sampath and the masakari team whether they would consider
>
> that in scope for their roadmap.
>
>
>
> Waines, Greg <greg.wai...@windriver.com> wrote:
>
>
>
> Sure.  I can propose a new user story.
>
>
>
> And then are you thinking of including this user story in the scope of
>
> what masakari would be looking at ?
>
>
>
> Greg.
>
>
>
>
>
> From: Adam Spiers <aspi...@suse.com>
>
> Reply-To: "openstack-dev@lists.openstack.org"
>
> <openstack-dev@lists.openstack.org>
>
> Date: Wednesday, May 17, 2017 at 10:08 AM
>
> To: "openstack-dev@lists.openstack.org"
>
> <openstack-dev@lists.openstack.org>
>
> Subject: Re: [openstack-dev] [vitrage] [nova] [HA] VM Heartbeat /
>
> Healthcheck Monitoring
>
>
>
> Thanks for the clarification Greg.  This sounds like it has the
>
> potential to be a very useful capability.  May I suggest that you
>
> propose a new user story for it, along similar lines to this existing
>
> one?
>
>
>
>
>
> http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html
>
>
>
> Waines, Greg <greg.wai...@windriver.com<mailto:greg.wai...@windriver.com>>
>
> wrote:
>
> Yes that’s correct.
>
> VM Heartbeating / Health-check Monitoring would introduce intrusive /
>
> white-box type monitoring of VMs / Instances.
>
>
>
> I realize this is somewhat in the gray-zone of what a cloud should be
>
> monitoring or not,
>
> but I believe it provides an alternative for Applications deployed in VMs
>
> that do not have an external monitoring/management entity like a VNF Manager
>
> in the MANO architecture.
>
> And even for VMs with VNF Managers, it provides a highly reliable
>
> alternate monitoring path that does not rely on Tenant Networking.
>
>
>
> You’re correct, that VM HB/HC Monitoring would leverage
>
> https://wiki.libvirt.org/page/Qemu_guest_agent
>
> that would require the agent to be installed in the images for talking
>
> back to the compute host.
>
> ( there are other examples of similar approaches in openstack ... the
>
> murano-agent for installation, the swift-agent for object store management )
>
> Although here, in the case of VM HB/HC Monitoring, via the QEMU Guest
>
> Agent, the messaging path is internal thru a QEMU virtual serial device.
&

Re: [openstack-dev] [masakari] Intrusive Instance Monitoring

[Sam P]

Hi Greg,

 Thank you for proposal.
 #BTW, I replied to our discussion in [1].

 Masakari mainly focuses on black box monitoring the VMs.
 But that does not mean Masakari do not do white box type of monitoring.
 There will be a configuration options for operators for whether to
use it or not and how to configure it.
 For masakari, this is one of the ways to extend its instance
monitoring capabilities.

 I really appreciate it if you could write a spec for this in [2], and
it will help masakari community and openstack-ha community to
understand the requirements and
 support them in future developments.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117003.html
[2] https://github.com/openstack/masakari-specs
--- Regards,
Sampath



On Thu, May 18, 2017 at 6:15 AM, Waines, Greg  wrote:
> ( I have been having a discussion with Adam Spiers on
> [openstack-dev][vitrage][nova] on this topic ... thought I would switchover
> to [masakari] )
>
>
>
> I am interested in contributing an implementation of Intrusive Instance
> Monitoring,
>
> initially specifically VM Heartbeat / Heath-check Monitoring thru the QEMU
> Guest Agent (https://wiki.libvirt.org/page/Qemu_guest_agent).
>
>
>
> I’d like to know whether Masakari project leaders would consider a blueprint
> on “VM Heartbeat / Health-check Monitoring”.
>
> See below for some more details,
>
> Greg.
>
>
>
> -
>
>
>
>
>
> VM Heartbeating / Health-check Monitoring would introduce intrusive /
> white-box type monitoring of VMs / Instances to Masakari.
>
>
>
> Briefly, “VM Heartbeat / Health-check Monitoring”
>
> · is optionally enabled thru a Nova flavor extra-spec,
>
> · is a service that runs on an OpenStack Compute Node,
>
> · it sends periodic Heartbeat / Health-check Challenge Requests to a
> VM
> over a virtio-serial-device setup between the Compute Node and the VM thru
> QEMU,
> ( https://wiki.libvirt.org/page/Qemu_guest_agent )
>
> · on loss of heartbeat or a failed health check status will result
> in fault event, against the VM, being
> reported to Masakari and any other registered reporting backends like
> Mistral, or Vitrage.
>
>
>
> I realize this is somewhat in the gray-zone of what a cloud should be
> monitoring or not,
>
> but I believe it provides an alternative for Applications deployed in VMs
> that do not have an external monitoring/management entity like a VNF Manager
> in the MANO architecture.
>
> And even for VMs with VNF Managers, it provides a highly reliable alternate
> monitoring path that does not rely on Tenant Networking.
>
>
>
> VM HB/HC Monitoring would leverage
> https://wiki.libvirt.org/page/Qemu_guest_agent
>
> that would require the agent to be installed in the images for talking back
> to the compute host.
>
> ( there are other examples of similar approaches in openstack ... the
> murano-agent for installation, the swift-agent for object store management )
>
> Although here, in the case of VM HB/HC Monitoring, via the QEMU Guest Agent,
> the messaging path is internal thru a QEMU virtual serial device.  i.e. a
> very simple interface with very few dependencies ... it’s up and available
> very early in VM lifecycle and virtually always up.
>
>
>
> Wrt failure modes / use-cases
>
> · a VM’s response to a Heartbeat Challenge Request can be as simple
> as just ACK-ing,
> this alone allows for detection of:
>
> oa failed or hung QEMU/KVM instance, or
>
> oa failed or hung VM’s OS, or
>
> oa failure of the VM’s OS to schedule the QEMU Guest Agent daemon, or
>
> oa failure of the VM to route basic IO via linux sockets.
>
> · I have had feedback that this is similar to the virtual hardware
> watchdog of QEMU/KVM (https://libvirt.org/formatdomain.html#elementsWatchdog
> )
>
> · However, the VM Heartbeat / Health-check Monitoring
>
> o   provides a higher-level (i.e. application-level) heartbeating
>
> §  i.e. if the Heartbeat requests are being answered by the Application
> running within the VM
>
> o   provides more than just heartbeating, as the Application can use it to
> trigger a variety of audits,
>
> o   provides a mechanism for the Application within the VM to report a
> Health Status / Info back to the Host / Cloud,
>
> o   provides notification of the Heartbeat / Health-check status to
> higher-level cloud entities thru Masakari, Mistral and/or Vitrage
>
> §  e.g.   VM-Heartbeat-Monitor - to - Vitrage - (EventAlarm) - Aodh - ... -
> VNF-Manager
>
> - (StateChange) - Nova - ... - VNF Manager
>
>
>
> NOTE: perhaps the reporting to Vitrage would be a separate blueprint within
> Masakari.
>
>
>
>
>
>
> __
> 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
>

Re: [openstack-dev] [vitrage] [nova] [HA] [masakari] VM Heartbeat / Healthcheck Monitoring

[Sam P]

Hi Greg,
 Thank you Adam for followup.
 This is new feature for masakari-monitors and think  Masakari can
accommodate this feature in  masakari-monitors.
 From the implementation prospective, it is not that hard to do.
 However, as you can see in our Boston presentation, Masakari will
replace its monitoring parts ( which is masakari-monitors) with,
 nova-host-alerter, **-process-alerter, and **-instance-alerter. (**
part is not defined yet..:p)...
 Therefore, I would like to save this specifications, and make sure we
will not miss  anything in the transformation..
 Does is make sense to write simple spec for this in masakari-spec [1]?
 So we can discuss about the requirements how to implement it.

[1] https://github.com/openstack/masakari-specs

--- Regards,
Sampath



On Thu, May 18, 2017 at 2:29 AM, Adam Spiers  wrote:
> I don't see any reason why masakari couldn't handle that, but you'd
> have to ask Sampath and the masakari team whether they would consider
> that in scope for their roadmap.
>
> Waines, Greg  wrote:
>>
>> Sure.  I can propose a new user story.
>>
>> And then are you thinking of including this user story in the scope of
>> what masakari would be looking at ?
>>
>> Greg.
>>
>>
>> From: Adam Spiers 
>> Reply-To: "openstack-dev@lists.openstack.org"
>> 
>> Date: Wednesday, May 17, 2017 at 10:08 AM
>> To: "openstack-dev@lists.openstack.org"
>> 
>> Subject: Re: [openstack-dev] [vitrage] [nova] [HA] VM Heartbeat /
>> Healthcheck Monitoring
>>
>> Thanks for the clarification Greg.  This sounds like it has the
>> potential to be a very useful capability.  May I suggest that you
>> propose a new user story for it, along similar lines to this existing
>> one?
>>
>>
>> http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html
>>
>> Waines, Greg >
>> wrote:
>> Yes that’s correct.
>> VM Heartbeating / Health-check Monitoring would introduce intrusive /
>> white-box type monitoring of VMs / Instances.
>>
>> I realize this is somewhat in the gray-zone of what a cloud should be
>> monitoring or not,
>> but I believe it provides an alternative for Applications deployed in VMs
>> that do not have an external monitoring/management entity like a VNF Manager
>> in the MANO architecture.
>> And even for VMs with VNF Managers, it provides a highly reliable
>> alternate monitoring path that does not rely on Tenant Networking.
>>
>> You’re correct, that VM HB/HC Monitoring would leverage
>> https://wiki.libvirt.org/page/Qemu_guest_agent
>> that would require the agent to be installed in the images for talking
>> back to the compute host.
>> ( there are other examples of similar approaches in openstack ... the
>> murano-agent for installation, the swift-agent for object store management )
>> Although here, in the case of VM HB/HC Monitoring, via the QEMU Guest
>> Agent, the messaging path is internal thru a QEMU virtual serial device.
>> i.e. a very simple interface with very few dependencies ... it’s up and
>> available very early in VM lifecycle and virtually always up.
>>
>> Wrt failure modes / use-cases
>>
>> · a VM’s response to a Heartbeat Challenge Request can be as
>> simple as just ACK-ing,
>> this alone allows for detection of:
>>
>> oa failed or hung QEMU/KVM instance, or
>>
>> oa failed or hung VM’s OS, or
>>
>> oa failure of the VM’s OS to schedule the QEMU Guest Agent daemon, or
>>
>> oa failure of the VM to route basic IO via linux sockets.
>>
>> · I have had feedback that this is similar to the virtual hardware
>> watchdog of QEMU/KVM (
>> https://libvirt.org/formatdomain.html#elementsWatchdog )
>>
>> · However, the VM Heartbeat / Health-check Monitoring
>>
>> o   provides a higher-level (i.e. application-level) heartbeating
>>
>> §  i.e. if the Heartbeat requests are being answered by the Application
>> running within the VM
>>
>> o   provides more than just heartbeating, as the Application can use it to
>> trigger a variety of audits,
>>
>> o   provides a mechanism for the Application within the VM to report a
>> Health Status / Info back to the Host / Cloud,
>>
>> o   provides notification of the Heartbeat / Health-check status to
>> higher-level cloud entities thru Vitrage
>>
>> §  e.g.   VM-Heartbeat-Monitor - to - Vitrage - (EventAlarm) - Aodh - ...
>> - VNF-Manager
>>
>> - (StateChange) - Nova - ... - VNF Manager
>>
>>
>> Greg.
>>
>>
>> From: Adam Spiers >
>> Reply-To:
>> "openstack-dev@lists.openstack.org"
>> >
>> Date: Tuesday, May 16, 2017 at 7:29 PM
>> To:
>> "openstack-dev@lists.openstack.org"
>> 

Re: [openstack-dev] [vitrage] [nova] VM Heartbeat / Healthcheck Monitoring

[Sam P]

Hi Greg,

 In Masakari [0] for VMHA, we have already implemented some what
similar function in masakri-monitors.
 Masakari-monitors runs on nova-compute node, and monitors the host,
process or instance failures.
 Masakari instance monitor has similar functionality with what you
have described.
 Please see [1] for more details on instance monitoring.
 [0] https://wiki.openstack.org/wiki/Masakari
 [1] 
https://github.com/openstack/masakari-monitors/tree/master/masakarimonitors/instancemonitor

 Once masakari-monitors detect failures, it will send notifications to
masakari-api to take appropriate recovery actions to recover that VM
from failures.

__
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

Re: [openstack-dev] [FaaS] Introduce a FaaS project

[Sam P]

Hi Larry,
 Thank you for the details.
 I am interested and like the idea of no vendor/platform lock-in.

 However,  I still have this stupid question in me.
 Why FaaS need to be in the OpenStack ecosystem? Can it survive
outside and still be able to integrate with OpenStack?
 This FaaS must able to well integrated with OpenStack ecosystem and
no argument there.

>>IMHO, none of them can be well integrated with OpenStack ecosystem.
Can you share more details on this?  If you have done any survey on
this,  please share.
Crating FaaS with pure OpenStack means, we need to create something
similar to OpenWhisk or IronFunctions with existing or new OpenStack
components.
I just want to make sure it is worth it to recreate the wheels.


Jsut for the info, I think this [0] is your previous ML thread...
[0] http://lists.openstack.org/pipermail/openstack-dev/2017-May/116472.html
--- Regards,
Sampath



On Mon, May 15, 2017 at 2:59 PM, Li Ma  wrote:
> That's interesting. Serverless is a general computing engine that can
> brings lots of possibility of how to make use of resource managed by
> OpenStack. I'd like to see a purely OpenStack-powered solution there.
>
> Do you have submitted a proposal to create this project under
> OpenStack umbrella?
>
> On Mon, May 15, 2017 at 9:36 AM, Lingxian Kong  wrote:
>> Yes, I am recreating the wheels :-)
>>
>> I am sending this email not intend to say Qinling[1] project is a better
>> option than others as a project of function as a service, I just provide
>> another
>> possibility for developers/operators already in OpenStack world, and try my
>> luck to seek people who have the same interest in serverless area and
>> cooperate
>> together to make it more and more mature if possible, because I see
>> serverless
>> becomes more and more popular in current agile IT world but I don't see
>> there
>> is a good candidate in OpenStack ecosystem.
>>
>> I remember I asked the question that if we have a FaaS available project in
>> OpenStack, what I got are something like: Picasso[2], OpenWhisk[3], etc, but
>> IMHO, none of them can be well integrated with OpenStack ecosystem. I don't
>> mean they are not good, on the contrary, they are good, especially OpenWhisk
>> which is already deployed and available in IBM Bluemix production. Picasso
>> is
>> only a very thin proxy layer to IronFunctions which is an open source
>> project
>> comes from Iron.io company who also has a commercial FaaS product.
>>
>> However, there are several reasons make me create a new project:
>>
>> - Maybe not many OpenStack operators/developers want to touch a project
>>   written in another programming language besides Python (and maybe Go? not
>> sure
>>   the result of TC resolution). The deployment/dependency management/code
>>   maintenance will bring much more overhead.
>>
>> - I'd like to see a project which is using the similar
>>   components/infrastructure as most of the other OpenStack projects, e.g.
>>   keystone authentication, message queue(in order to receive notification
>> from
>>   Panko then trigger functions), database, oslo library, swift(for code
>>   package storage), etc. Of course, I could directly contribute and modify
>>   some existing project(e.g. Picasso) to satisfy these conditions, but I am
>>   afraid the time and effort it could take is exactly the same as if I
>> create
>>   a new one.
>>
>> - I'd like to see a project with no vendor/platform lock-in. Most of the
>> FaaS
>>   projects are based on one specific container orchestration platform or
>> want
>>   to promote usage of its own commercial product. For me, it's always a good
>>   thing to have more technical options when evaluating a new service.
>>
>> Qinling project is still at the very very early stage. I created it one
>> month ago
>> and work on it only in my spare time. But it works, you can see a basic
>> usage
>> introduction in README.rst and give it a try. A lot of things are still
>> missing, CLI, UT, devstack plugin, UI, etc.
>>
>> Of course, you can ignore me (still appreciate you read here) if you think
>> it's really not necessary and stupid to create such a project in OpenStack,
>> or you can join me to discuss what we could do to improve it gradually and
>> provide a better option for a real function as a service to people in
>> OpenStack world.
>>
>> [1]: https://github.com/LingxianKong/qinling
>> [2]: https://github.com/openstack/picasso
>> [3]: https://github.com/openwhisk/openwhisk
>>
>> Cheers,
>> Lingxian Kong (Larry)
>>
>> __
>> 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
>>
>
>
>
> --
>
> Li Ma (Nick)
> Email: skywalker.n...@gmail.com
>
> __
> 

Re: [openstack-dev] [HA] HA Discussion at Boston Forum

[Sam P]

Hi All,

This is a quick reminder for HA Forum session at Boston Summit.
Thank you all for your comments and effort to make this happen in Boston Summit.

 Time: Thu 11 , 11:00am-11:40am
 Location: Hynes Convention Center - Level One - MR 103
 Etherpad: https://etherpad.openstack.org/p/BOS-forum-HA-in-openstack

 Please join and let's discuss the HA issues in OpenStack...

--- Regards,
Sampath



On Mon, Apr 10, 2017 at 12:37 PM, Sam P <sam47pr...@gmail.com> wrote:
> Hi All,
>
>  I proposed a session [1] to Boston Forum and it is now at incomplete state.
>  This is good opportunity for all of us to get together and discuss
> our HA related issues.
>  I need your help to reform this session.
>  Please put comments on [1] or replay to this with your comments.
>
> [1] http://forumtopics.openstack.org/cfp/details/117
>
> --- 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

Re: [openstack-dev] 答复: [Openstack] 答复: OpenStack-Ansible HA solution

[Sam P]

Hi Maxwell,

 > It is so kind of you if you can touch Masakari team.
No problem. I will bring up this topic in Masakari team meetup in Boston summit.
If you are attend to summit, it would be great if you could attend to
the discussion.
Please check [1] for Masakri meetings at summit. ( it will update)

[1] https://etherpad.openstack.org/p/Masakari-Boston-Summit


--- Regards,
Sampath



On Tue, May 2, 2017 at 3:32 PM, Liyuenan (Maxwell Li)
<liyue...@huawei.com> wrote:
> Hi Sampath
>
> I do appreciate for your help! And I will pay attention to Masakari.
>
> It is so kind of you if you can touch Masakari team.
>
> Thank you again!
>
> Best Regards!
> Maxwell Li
> maxwelli.com
>
> -邮件原件-
> 发件人: Sam P [mailto:sam47pr...@gmail.com]
> 发送时间: 2017年4月28日 0:16
> 收件人: OpenStack Development Mailing List (not for usage questions)
> 抄送: Andy McCrae; openst...@lists.openstack.org; Liyuenan (Maxwell Li)
> 主题: Re: [openstack-dev] [Openstack] 答复: OpenStack-Ansible HA solution
>
> Hi Maxwell,
>
>  As John mentioned, current OSA does not support Masakri.
>  However, if it make your work easier, then I would love to discuss this with 
> Masakri team [1].
>
> [1] https://wiki.openstack.org/wiki/Meetings/Masakari
> --- Regards,
> Sampath
>
>
>
> On Thu, Apr 27, 2017 at 10:39 PM, John Petrini <jpetr...@coredial.com> wrote:
>> Hi Maxwell,
>>
>> For compute HA have a look at Masakari -
>> https://wiki.openstack.org/wiki/Masakari. I don't believe OSA
>> currently supports it but you could always build your own role for it
>> and the community would likely be open to integrating it into OSA.
>>
>>
>> On Thu, Apr 27, 2017 at 5:24 AM, Andy McCrae <andy.mcc...@gmail.com> wrote:
>>>
>>> Hi Maxwell,
>>>
>>>
>>>> I found that OSA use keepalived to resolve controller HA, but
>>>> whether the keepalived support compute HA? What shoud I do or which
>>>> file I need to config if I want to resolve compute HA?
>>>>
>>>>
>>>>
>>>> And there are some solutions for compute HA in this web:
>>>> http://aspiers.github.io/openstack-summit-2016-austin-compute-ha/ .
>>>> Would the OSA use pacemaker or some other solutions to support compute HA?
>>>>
>>>>
>>>
>>> We don't currently have a nova compute HA solution built-in -
>>> although OSA itself is quite pluggable, so if you were interested in
>>> adding functionality to OSA for that - by utilizing the inventory and
>>> roles that are setup in OSA you would be able to achieve this.
>>>
>>> However, as it stands there is only functionality for adding
>>> keepalived HA functionality for the controller/API services.
>>>
>>> Andy
>>>
>>> ___
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openst...@lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>
>>
>> __
>>  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 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

Re: [openstack-dev] [User-committee] [Forum] Moderators needed!

[Sam P]

Hi Arkandy,

 Thank you.
 I replied to Shamail with "I am available to moderate the session" for
​
High Availability in OpenStack

.
 However, by mistake my reply only sent to individual members and not for
the MLs.
 Sorry

--- Regards,
Sampath


On Sat, Apr 29, 2017 at 10:06 AM,  wrote:

> ​​
> Shamail,
>
> I can moderate either
>
> Achieving Resiliency at Scales of 1000+
> 
> or
>
> High Availability in OpenStack
> 
>
>
>
> Thanks,
>
> Arkady
>
>
>
> *From:* Shamail Tahir [mailto:itzsham...@gmail.com]
> *Sent:* Friday, April 28, 2017 7:23 AM
> *To:* openstack-operators ;
> OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>; user-committee  openstack.org>
> *Subject:* [User-committee] [Forum] Moderators needed!
>
>
>
> Hi everyone,
>
>
>
> Most of the proposed/accepted Forum sessions currently have moderators but
> there are six sessions that do not have a confirmed moderator yet. Please
> look at the list below and let us know if you would be willing to help
> moderate any of these sessions.
>
>
>
> The topics look really interesting but it will be difficult to keep the
> sessions on the schedule if there is not an assigned moderator. We look
> forward to seeing you at the Summit/Forum in Boston soon!
>
>
> ​​
>
> Achieving Resiliency at Scales of 1000+
> 
>
> Feedback from users for I18n & translation - important part?
> 
>
> Neutron Pain Points
> 
>
> Making Neutron easy for people who want basic networking
> 
>
>
> 
> ​​
> 
> High Availability in OpenStack
> 
>
> Cloud-Native Design/Refactoring across OpenStack
> 
>
>
>
>
>
> Thanks,
>
> Doug, Emilien, Melvin, Mike, Shamail & Tom
> Forum Scheduling Committee
>
> ___
> User-committee mailing list
> user-commit...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>
__
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

Re: [openstack-dev] [Openstack] 答复: OpenStack-Ansible HA solution

[Sam P]

Hi Maxwell,

 As John mentioned, current OSA does not support Masakri.
 However, if it make your work easier, then I would love to discuss
this with Masakri team [1].

[1] https://wiki.openstack.org/wiki/Meetings/Masakari
--- Regards,
Sampath



On Thu, Apr 27, 2017 at 10:39 PM, John Petrini  wrote:
> Hi Maxwell,
>
> For compute HA have a look at Masakari -
> https://wiki.openstack.org/wiki/Masakari. I don't believe OSA currently
> supports it but you could always build your own role for it and the
> community would likely be open to integrating it into OSA.
>
>
> On Thu, Apr 27, 2017 at 5:24 AM, Andy McCrae  wrote:
>>
>> Hi Maxwell,
>>
>>
>>> I found that OSA use keepalived to resolve controller HA, but whether the
>>> keepalived support compute HA? What shoud I do or which file I need to
>>> config if I want to resolve compute HA?
>>>
>>>
>>>
>>> And there are some solutions for compute HA in this web:
>>> http://aspiers.github.io/openstack-summit-2016-austin-compute-ha/ . Would
>>> the OSA use pacemaker or some other solutions to support compute HA?
>>>
>>>
>>
>> We don't currently have a nova compute HA solution built-in - although OSA
>> itself is quite pluggable, so if you were interested in adding functionality
>> to OSA for that - by utilizing the inventory and roles
>> that are setup in OSA you would be able to achieve this.
>>
>> However, as it stands there is only functionality for adding keepalived HA
>> functionality for the controller/API services.
>>
>> Andy
>>
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openst...@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
>
> __
> 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 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-dev] [HA] HA Discussion at Boston Forum

[Sam P]

Hi All,

 I proposed a session [1] to Boston Forum and it is now at incomplete state.
 This is good opportunity for all of us to get together and discuss
our HA related issues.
 I need your help to reform this session.
 Please put comments on [1] or replay to this with your comments.

[1] http://forumtopics.openstack.org/cfp/details/117

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

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

[Sam P]

Hi Dims, Hi gmann,

Thanks guys.
 Slowly recovering from PTG jet lag

OK then.., I will start working on this.
I would also like to coordinate this work with LCOO [1] team,  where
we can get valuable feedback and contributions..
I will give you update on next QA IRC on 0900 UTC meeting, which is
9th of March?
(1700 UTC meeting is difficult for me, however I will definitely be
there if needed)

[1] https://wiki.openstack.org/wiki/LCOO
--- Regards,
Sampath



On Fri, Feb 24, 2017 at 8:57 PM, Ghanshyam Mann <ghanshyamm...@gmail.com> wrote:
> Yea, agree with dims.
>
> Sampath ,
>
> Thanks for taking over this, it is really great help. Please update the
> current spec with approaches you have. Timur help will be great if he show
> up sometime.
>
> Also we will add destructive testing as one of weekly meeting agenda and
> make sure you will get all help & required attention from QA team.
>
> -gmann
>
>
> On Fri, Feb 24, 2017 at 7:26 AM, Davanum Srinivas <dava...@gmail.com> wrote:
>>
>> Sampath,
>>
>> I am not sure if you will hear back from Timur soon as he may not be
>> working on this stuff anymore (in Mirantis). So i'd recommend picking
>> up the work if you don't hear from him soon.
>>
>> Thanks,
>> Dims
>>
>> On Thu, Feb 23, 2017 at 3:41 PM, Sam P <sam47pr...@gmail.com> wrote:
>> > Hi Timur,
>> >
>> >  The current status of this work is,
>> > 1) The QA user story for destructive testing of OpenStack cloud [1] is
>> > merged .
>> > 2) The spec for a new framework which will focus on HA/failover and
>> > destructive testing  [2] has no update since Nov 30 2016.
>> > 3) The commit for the new repository [3]  has abandoned due to no
>> > update after Nov 29 2016.
>> >
>> > Currently, I am working on 3rd party destructive/HA testing CI for
>> > Masakari[4] and very much interested in this work.
>> > I will keep working on [1] with PWG.
>> > Please let me know your plans for [2], and [3].
>> > If it is difficult for you to continue, I would love to continue your
>> > work on [2], and [3].
>> >
>> > [1] https://review.openstack.org/#/c/396142
>> > [2] https://review.openstack.org/#/c/399618
>> > [3] https://review.openstack.org/#/c/374667
>> > [4] https://wiki.openstack.org/wiki/Masakari
>> > --- Regards,
>> > Sampath
>> >
>> >
>> >
>> > On Mon, Nov 28, 2016 at 6:37 AM, Timur Nurlygayanov
>> > <tnurlygaya...@mirantis.com> wrote:
>> >> Hi team,
>> >>
>> >> here is a short update:
>> >>
>> >> 1) The QA user story for destructive testing of OpenStack cloud is on
>> >> review
>> >> [1].
>> >> 2) The spec for a new framework which will focus on HA/failover and
>> >> destructive testing is no review [2].
>> >> 3) The commit for the new repository is on review [3] as well.
>> >>
>> >> [1] https://review.openstack.org/#/c/396142
>> >> [2] https://review.openstack.org/#/c/399618
>> >> [3] https://review.openstack.org/#/c/374667
>> >>
>> >>
>> >> On Fri, Oct 14, 2016 at 3:47 AM, Ghanshyam Mann
>> >> <ghanshyam.m...@nectechnologies.in> wrote:
>> >>>
>> >>> I like os-faults library which can provide the abstraction over
>> >>> different
>> >>> destructive actions like reboot/poweroff node etc.
>> >>>
>> >>>
>> >>>
>> >>> But not much clear about Stepler that what all tests it will contain.
>> >>> Tempest do have scenario tests which can hit the production env with
>> >>> significant way of testing scenario.
>> >>>
>> >>> It can cover the end user scenario also which involves the interaction
>> >>> of
>> >>> public OpenStack APIs and always in enhancement state by adding more
>> >>> and
>> >>> more scenario tests.
>> >>>
>> >>>
>> >>>
>> >>> Few query over Stepler as separate project:
>> >>>
>> >>> 1.   Is Stepler will cover only tests which hits the node level
>> >>> action(reboot, HA etc)?
>> >>>
>> >>> 2.   This should not mix the scenario tests which are in Tempest
>> >>> scope
>> >>> because that can make confusion for developers (where to add scenario
>> >>> tests)
>> >>> 

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

[Sam P]

Hi Timur,

 The current status of this work is,
1) The QA user story for destructive testing of OpenStack cloud [1] is merged .
2) The spec for a new framework which will focus on HA/failover and
destructive testing  [2] has no update since Nov 30 2016.
3) The commit for the new repository [3]  has abandoned due to no
update after Nov 29 2016.

Currently, I am working on 3rd party destructive/HA testing CI for
Masakari[4] and very much interested in this work.
I will keep working on [1] with PWG.
Please let me know your plans for [2], and [3].
If it is difficult for you to continue, I would love to continue your
work on [2], and [3].

[1] https://review.openstack.org/#/c/396142
[2] https://review.openstack.org/#/c/399618
[3] https://review.openstack.org/#/c/374667
[4] https://wiki.openstack.org/wiki/Masakari
--- Regards,
Sampath



On Mon, Nov 28, 2016 at 6:37 AM, Timur Nurlygayanov
 wrote:
> Hi team,
>
> here is a short update:
>
> 1) The QA user story for destructive testing of OpenStack cloud is on review
> [1].
> 2) The spec for a new framework which will focus on HA/failover and
> destructive testing is no review [2].
> 3) The commit for the new repository is on review [3] as well.
>
> [1] https://review.openstack.org/#/c/396142
> [2] https://review.openstack.org/#/c/399618
> [3] https://review.openstack.org/#/c/374667
>
>
> On Fri, Oct 14, 2016 at 3:47 AM, Ghanshyam Mann
>  wrote:
>>
>> I like os-faults library which can provide the abstraction over different
>> destructive actions like reboot/poweroff node etc.
>>
>>
>>
>> But not much clear about Stepler that what all tests it will contain.
>> Tempest do have scenario tests which can hit the production env with
>> significant way of testing scenario.
>>
>> It can cover the end user scenario also which involves the interaction of
>> public OpenStack APIs and always in enhancement state by adding more and
>> more scenario tests.
>>
>>
>>
>> Few query over Stepler as separate project:
>>
>> 1.   Is Stepler will cover only tests which hits the node level
>> action(reboot, HA etc)?
>>
>> 2.   This should not mix the scenario tests which are in Tempest scope
>> because that can make confusion for developers (where to add scenario tests)
>> as well as for tester(from where to run what scenario tests).
>>
>> 3.   How we make sure those tests run fine or at least run while
>> adding.
>>
>> a.   I think devstack enhancement for multi-node etc can do this as
>> mentioned by you also.
>>
>> b.  If so then why not adding those tests in Tempest only using
>> os-faults lib ?
>>
>>
>>
>> Overall I feel os-faults  as lib is really nice idea but tests scope can
>> go in Tempest under HW_scenario  (or something else) till it does not break
>> basic principle of Tempest.
>>
>>
>>
>> Thanks
>>
>> gmann
>>
>>
>>
>> From: Timur Nurlygayanov [mailto:tnurlygaya...@mirantis.com]
>> Sent: 06 October 2016 20:09
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [QA] The end-user test suite for OpenStack
>> clusters
>>
>>
>>
>> Ken, it is a good idea!
>>
>>
>>
>> The plan is to develop os-faults as a library which will be able
>>
>> to manage cluster nodes and OpenStack services on these nodes.
>>
>> It is a good idea to add some Tempest tests which will use
>>
>> os-faults library as well for some API tests.
>>
>>
>>
>> The Stepler framework [1] will use os-faults to perform all destructive
>>
>> actions in the clouds (the reboot of nodes, restart of OpenStack services,
>>
>> enable/disable network interfaces or some firewall rules and etc).
>>
>>
>>
>> We need to get +1 from you in [1] to create the repository with
>>
>> advanced end-user scenario tests.
>>
>>
>>
>> Thank you!
>>
>>
>>
>> [1] https://review.openstack.org/#/c/374667/
>>
>>
>>
>> On Tue, Oct 4, 2016 at 8:53 PM, Yaroslav Lobankov 
>> wrote:
>>
>> Hi Ken,
>>
>>
>>
>> OS-Faults doesn't have any scenarios in the tree yet (the project is two
>> months old), but you can find some examples of the use in the
>> os-faults/examples directory.
>>
>>
>>
>> Regards,
>>
>> Yaroslav Lobankov.
>>
>>
>>
>> On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi 
>> wrote:
>>
>> Hi Timur,
>>
>> Thanks for your explanation.
>>
>>
>> 2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov :
>> >
>> >> I am guessing the above "restart nodes" is for verifying each
>> >> OpenStack service restarts successfully, right?
>> >
>> > Yes, this is right. And we also will check that HA logic for these
>> > services works correctly (for example, rescheduling of L3 Neutron
>> > agents for networks).
>> >
>> >> But these service scripts are provided by distributors, and Devstack
>> >> itself doesn't contain service scripts IIUC.
>> >> So I'd like to know how to verify it on Devstack clouds.
>> >
>> > Yes, DevStack 

Re: [openstack-dev] [openstack-community] OpenStack Summit Boston-CFP closes February 6th

[Sam P]

Hi Erin,

 Thank you for the reminder and other info.
 In you previous mail,
 > Panels are allowed a total of four speakers plus one moderator, whereas
 > presentations and lightning talks are limited to two speakers.
 To the best of my knowledge, presentations limited to three speakers.
 Not sure about the lightning talks.


--- Regards,
Sampath



On Thu, Feb 2, 2017 at 4:14 AM, Erin Disney  wrote:
> Hi Everyone-
>
> Don’t forget: the Call for Presentations for the upcoming OpenStack Summit
> Boston closes next week!
>
> The submission deadline is February 6, 2017 at 11:59PM PDT (February 7, 2017
> at 6:59 UTC).
>
> Reminder: Proposed sessions must indicate a format: Panel, presentation or
> lightning talk. Each format has a maximum number of speakers associated.
> Panels are allowed a total of four speakers plus one moderator, whereas
> presentations and lightning talks are limited to two speakers.
>
> As a reminder, speakers are limited to a maximum of three submissions total.
>
> Contact speakersupp...@openstack.org with any submission questions.
>
> BOSTON REGISTRATION
> Attendee registration is now open. Purchase your discounted early bird
> passes now. Prices will increase in mid March.
>
> SPONSORSHIP SALES
> Summit sponsorship sales are also open. You can now sign the electronic
> contract here. If you plan to sponsor both 2017 OpenStack Summits (Boston in
> May & Sydney in November), then check out page 4 of the Boston Summit
> Sponsorship Prospectus for a special 15% discount on Sydney Summit
> sponsorship packages. Please note this only applies to companies who sponsor
> both the Boston Summit and Sydney Summit. Full details of the sponsorship
> signing process are outlined here.
>
> If you have any general Summit questions, contact us at
> sum...@openstack.org.
>
>
> Erin Disney
> OpenStack Marketing
> e...@openstack.org
>
>
> ___
> Community mailing list
> commun...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/community
>

__
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

Re: [openstack-dev] Introduction

[Sam P]

Hi Nalaka,

 FYI.
 In addition to Jay's advice, I recommend you to follow the work of
 openstack Scientific working group
https://wiki.openstack.org/wiki/Scientific_working_group.
 If you have any special project in mind then go for it.
 Otherwise, work of the above WG (working group) would be a grate
place to know what other researchers/scientists/academics do with
openstack.

--- Regards,
Sampath



On Tue, Jun 28, 2016 at 1:54 AM, Jay Faulkner  wrote:
> Hi and welcome
>
> https://wiki.openstack.org/wiki/How_To_Contribute will have some information
> on different ways to contribute. If you have a specific project in mind, I'd
> suggest searching on their bugtracker for 'low-hanging-fruit'. Either one of
> those bugs, or any issues/bugs you see in developer documentation are great
> choices for getting started. If you have any trouble, asking in IRC is often
> a quick way to get over a problem, but most of it's documented pretty well
> so make sure to exhaust the docs first.
>
> Good luck + thanks,
> Jay Faulkner
> OSIC
>
> On Jun 27, 2016, at 9:10 AM, Nalaka Rajamanthri 
> wrote:
>
> Hi,
> I am new to the open source community. I would like to contribute to the
> openstack. So I would like to help this project by solving bugs.
>
> Best Regards,
> Nalaka Rajamanthri,
> University of Peradeniya (undergraduate)
> __
> 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 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 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-dev] [HA] About 6/2 HA Team meeting (VoIP)

[Sam P]

Hi All,

 Here are the details for our next VoIP meeting.
 Time: 2 June 2016 09:00 UTC
 Place: GoToMeeting  (follow the link below)

1.  Please join my meeting, Jun 2, 2016 at 09:00 UTC
https://global.gotomeeting.com/join/926781989

2. You will be connected to audio using your computer's microphone and
speakers (VoIP).  A headset is recommended.

Meeting ID: 926-781-989


Please ask if anything unclear.
--- 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

Re: [openstack-dev] [HA] About next HA Team meeting (VoIP)

[Sam P]

Hi All,

 Thank you all for attending to meeting.
 You can find the meeting notes at following etherpad in section
[Notes from meeting 2016/05/18 Wed]
 https://etherpad.openstack.org/p/newton-instance-ha

 Next meeting will be on 5/23 Monday (normal IRC meeting).
 http://eavesdrop.openstack.org/#High_Availability_Meeting

--- Regards,
Sampath



On Tue, May 17, 2016 at 8:03 PM, Sam P <sam47pr...@gmail.com> wrote:
> Hi All,
>
>  Since no objections raised, HA team VoIP meeting will shift to 9am
> UTC 18th May 2016.
>
> Here are the gotomeeting details for the meeting.
> 1.  Please join the meeting, May 18, 2016 at 18:00 GMT+9 (9am UTC).
> https://global.gotomeeting.com/join/424496645
> 2. You will be connected to audio using your computer's microphone and
> speakers (VoIP).  A headset is recommended.
> Meeting ID: 424-496-645
>
>
>
>
> I would like to add following topic to agenda.
> ---
> Instance HA API use case
>
>   We consider following use cases need APIs to manage instance HA in 
> operation.
>   Detailed specs and database schema can be found at following link.
>   https://github.com/ntt-sic/masakari/wiki/Masakari-API-Design
>
> [Failover Segment]
> System can be zoned from top to down levels, into Regions,
> Availability Zones and Host Aggregates (or Cells). Within those zones,
> one or more pacemaker/pacemaker-remote clusters may exist. In addition
> to those boundaries, shared storage boundary is also important to
> decide the optimal host for fail-over. Openstack zoned boundaries
> (such as Regions, AZ, Host Aggregates, etc..) can be managed by the
> nova scheduler. However, shared storage boundaries are difficult to
> manage. Moreover, the operator may want to use other types of boundary
> such as rack layout and powering. Therefore, operator may want to
> define the segment of hypervisor hosts and assign the failover
> host/hosts for each of them. Those segment can be define based on the
> shared storage boundaries or any other limitations may critical for
> selection of the failover host.
>
> [Capacity Reservation]
> Service provider who ensures an uptime of VM instance to their
> customer needs to make sure that the certain amount of host capacity
> are reserved to prepare a failure event. If the host capacity of
> system is full and the host failure happens, the VM on the failure
> host cannot be evacuated to other host. The system capacity is
> typically fragmented into segments due to underlying component’s
> scalability and each segment has a limited capacity. To increase
> resource efficiency, high utilization of host capacity is preferred.
> However, as any user consume resources on demand, the host capacity of
> each segment tends to reach the full if the system doesn’t provides
> the way to reserve the portion of host capacity to the operators.
> Therefore, the function to reserve host capacity for failover event is
> important to ensure the high availability of VM instance.
>
> [Host Maintenance]
> A host has to be temporarily and safely removed from the system for
> the maintenance such as hardware failure, firmware update and so on.
> During the maintenance, the monitoring function on the host should be
> disabled and the monitoring alert from the host should be ignored not
> to trigger any recovery action of VM instance on the host if it’s
> running. The host should be excluded from reserved hosts as well.
> ---
> --- Regards,
> Sampath
>
>
>
> On Mon, May 9, 2016 at 8:45 PM, Adam Spiers <aspi...@suse.com> wrote:
>> Sam P <sam47pr...@gmail.com> wrote:
>>> Hi All,
>>>
>>>  In today's ( 9th May 2016) meeting we agree to skip the next IRC
>>> meeting (which is 16th May 2016)  in favour of a gotomeeting VoIP on
>>> 18th May 2016 (Wednesday).
>>>  Today's meeting logs and summary can be found here.
>>>  http://eavesdrop.openstack.org/meetings/ha/2016/ha.2016-05-09-08.04.html
>>>
>>>  About the meeting Time:
>>>  Every one was convenient with 8:00am UTC.
>>>  However due to some resource allocation issues, I would like to shift
>>> this VoIP meeting to
>>>  9am UTC 18th May 2016
>>>
>>>  Please let me know if you are convenient or not with this time slot.
>>
>> That later time is fine for me :)  Thanks!
>>
>> __
>> 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 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

Re: [openstack-dev] [HA] About next HA Team meeting (VoIP)

[Sam P]

Hi All,

 Since no objections raised, HA team VoIP meeting will shift to 9am
UTC 18th May 2016.

Here are the gotomeeting details for the meeting.
1.  Please join the meeting, May 18, 2016 at 18:00 GMT+9 (9am UTC).
https://global.gotomeeting.com/join/424496645
2. You will be connected to audio using your computer's microphone and
speakers (VoIP).  A headset is recommended.
Meeting ID: 424-496-645




I would like to add following topic to agenda.
---
Instance HA API use case

  We consider following use cases need APIs to manage instance HA in operation.
  Detailed specs and database schema can be found at following link.
  https://github.com/ntt-sic/masakari/wiki/Masakari-API-Design

[Failover Segment]
System can be zoned from top to down levels, into Regions,
Availability Zones and Host Aggregates (or Cells). Within those zones,
one or more pacemaker/pacemaker-remote clusters may exist. In addition
to those boundaries, shared storage boundary is also important to
decide the optimal host for fail-over. Openstack zoned boundaries
(such as Regions, AZ, Host Aggregates, etc..) can be managed by the
nova scheduler. However, shared storage boundaries are difficult to
manage. Moreover, the operator may want to use other types of boundary
such as rack layout and powering. Therefore, operator may want to
define the segment of hypervisor hosts and assign the failover
host/hosts for each of them. Those segment can be define based on the
shared storage boundaries or any other limitations may critical for
selection of the failover host.

[Capacity Reservation]
Service provider who ensures an uptime of VM instance to their
customer needs to make sure that the certain amount of host capacity
are reserved to prepare a failure event. If the host capacity of
system is full and the host failure happens, the VM on the failure
host cannot be evacuated to other host. The system capacity is
typically fragmented into segments due to underlying component’s
scalability and each segment has a limited capacity. To increase
resource efficiency, high utilization of host capacity is preferred.
However, as any user consume resources on demand, the host capacity of
each segment tends to reach the full if the system doesn’t provides
the way to reserve the portion of host capacity to the operators.
Therefore, the function to reserve host capacity for failover event is
important to ensure the high availability of VM instance.

[Host Maintenance]
A host has to be temporarily and safely removed from the system for
the maintenance such as hardware failure, firmware update and so on.
During the maintenance, the monitoring function on the host should be
disabled and the monitoring alert from the host should be ignored not
to trigger any recovery action of VM instance on the host if it’s
running. The host should be excluded from reserved hosts as well.
---
--- Regards,
Sampath



On Mon, May 9, 2016 at 8:45 PM, Adam Spiers <aspi...@suse.com> wrote:
> Sam P <sam47pr...@gmail.com> wrote:
>> Hi All,
>>
>>  In today's ( 9th May 2016) meeting we agree to skip the next IRC
>> meeting (which is 16th May 2016)  in favour of a gotomeeting VoIP on
>> 18th May 2016 (Wednesday).
>>  Today's meeting logs and summary can be found here.
>>  http://eavesdrop.openstack.org/meetings/ha/2016/ha.2016-05-09-08.04.html
>>
>>  About the meeting Time:
>>  Every one was convenient with 8:00am UTC.
>>  However due to some resource allocation issues, I would like to shift
>> this VoIP meeting to
>>  9am UTC 18th May 2016
>>
>>  Please let me know if you are convenient or not with this time slot.
>
> That later time is fine for me :)  Thanks!
>
> __
> 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 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-dev] [HA] About next HA Team meeting (VoIP)

[Sam P]

Hi All,

 In today's ( 9th May 2016) meeting we agree to skip the next IRC
meeting (which is 16th May 2016)  in favour of a gotomeeting VoIP on
18th May 2016 (Wednesday).
 Today's meeting logs and summary can be found here.
 http://eavesdrop.openstack.org/meetings/ha/2016/ha.2016-05-09-08.04.html

 About the meeting Time:
 Every one was convenient with 8:00am UTC.
 However due to some resource allocation issues, I would like to shift
this VoIP meeting to
 9am UTC 18th May 2016

 Please let me know if you are convenient or not with this time slot.

--- 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-dev] [HA] Watcher Meethings

[Sam P]

Hi all,

 In Austin summit, Susanne Balle (with Watcher team)  invite HA people
to come to Watcher sessions and discuss the use case.

 FYI, here are the watcher sessions and mail they sent to watcher team.

On Fri, Apr 22, 2016 at 12:37 PM, Antoine Cabot
 wrote:
> Hi Watcher team,
>
> We will have a couple of meetings next week to discuss Watcher
> achievements during the Mitaka cycle and define priorities for Newton.
>
> Meetings will be held in the developer lounge in Austin
> https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Watcher
>
> A proposed open agenda is available
> https://etherpad.openstack.org/p/watcher-newton-design-session
>
> If you want to meet with Watcher team and discuss your use cases,
> feel free to join us and add your discussion topic to the agenda.
>
> Thanks,
>
> Antoine (acabot)


--- Regards,
 SamP

__
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