[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] [mistral] Help with test run

[Brad P. Crochet]

On Fri, Apr 27, 2018 at 5:23 AM András Kövi <allp...@gmail.com> wrote:

> Hi,
>
> Can someone please help me with why this build ended with TIMED_OUT?
> http://logs.openstack.org/85/527085/8/check/mistral-tox-unit-mysql/3ffae9f/
>
>
I'm not seeing any particular reason for it. Is it happening consistently?


> Thanks,
> Andras
>
> __
> 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] Proposing Marius Cornea core on upgrade bits

[Brad P. Crochet]

+1 from me!

On Fri, Apr 20, 2018 at 8:04 AM Yolanda Robla Mota <yrobl...@redhat.com>
wrote:

> +1, Marius has been a great help
>
> On Thu, Apr 19, 2018 at 7:01 PM, Emilien Macchi <emil...@redhat.com>
> wrote:
>
>> Greetings,
>>
>> As you probably know mcornea on IRC, Marius Cornea has been contributing
>> on TripleO for a while, specially on the upgrade bits.
>> Part of the quality team, he's always testing real customer scenarios and
>> brings a lot of good feedback in his reviews, and quite often takes care of
>> fixing complex bugs when it comes to advanced upgrades scenarios.
>> He's very involved in tripleo-upgrade repository where he's already core,
>> but I think it's time to let him +2 on other tripleo repos for the patches
>> related to upgrades (we trust people's judgement for reviews).
>>
>> As usual, we'll vote!
>>
>> Thanks everyone for your feedback and thanks Marius for your hard work
>> and involvement in the project.
>> --
>> Emilien Macchi
>>
>> __
>> 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
>>
>>
>
>
> --
>
> Yolanda Robla Mota
>
> Principal Software Engineer, RHCE
>
> Red Hat
>
> <https://www.redhat.com>
>
> C/Avellana 213
>
> Urb Portugal
>
> yrobl...@redhat.comM: +34605641639
> <http://redhatemailsignature-marketing.itos.redhat.com/>
> <https://red.ht/sig>
> ______
> 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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 <gm...@ghanshyammann.com>
wrote:

> On Thu, Mar 15, 2018 at 9:45 PM, Adam Spiers <aspi...@suse.com> wrote:
> > Raoul Scarazzini <ra...@redhat.com> 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 <dtant...@redhat.com> 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] [tripleo] how to reproduce tripleo ci

[Brad P. Crochet]

On Tue, Feb 6, 2018 at 1:59 PM Wesley Hayutin <whayu...@redhat.com> wrote:

> Greetings,
>
> The TripleO-CI team has added a recreate / reproduce script to all the
> tripleo upstream ci jobs as an artifact [1-2] much like the devstack
> reproduce.sh script.  If you find yourself in need of recreating a tripleo
> ci job please take a look at the instructions.
>
> At this time the reproduction of ci is only supported by using an
> openstack cloud to provision test nodes, libvirt and other approaches are
> not yet supported but are on the roadmap.
>
>
Great work TripleO-CI team! I've already used this a number of times and it
has functioned quite well!


> Thank you!
>
> [1]
> https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html
> [2] http://tripleo.org/contributor/reproduce-ci.html
>
> __
> 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] [Release-job-failures][mistral][release][requirements] Pre-release of openstack/mistral-extra failed

[Brad P. Crochet]

On Mon, Jan 29, 2018 at 8:02 PM, Doug Hellmann  wrote:
> Excerpts from zuul's message of 2018-01-30 00:40:13 +:
>> Build failed.
>>
>> - release-openstack-python 
>> http://logs.openstack.org/53/533a5ee424ebf6937f03d3b1d9d5b52e8ecb/pre-release/release-openstack-python/44f2fd4/
>>  : FAILURE in 7m 58s
>> - announce-release announce-release : SKIPPED
>> - propose-update-constraints propose-update-constraints : SKIPPED
>>
>
> This release appears to have failed because tox.ini is set up to use the
> old style of constraints list management and mistral-extra appears in
> the constraints list.
>
> I don't know why the tox environment is being used to build the package;
> I thought we stopped doing that.
>
> One solution is to fix the tox.ini to put the constraints specification
> in the "deps" field. The patch [1] to oslo.config making a similar
> change should show you what is needed.
>
> Doug
>
> [1] https://review.openstack.org/#/c/524496/1/tox.ini
>
> __
> 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

Hopefully https://review.openstack.org/539204 fixes it.

Brad

__
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] [tripleo] Blueprints moved out to Rocky

[Brad P. Crochet]

On Mon, Dec 11, 2017 at 5:20 PM Alex Schultz <aschu...@redhat.com> wrote:

> On Mon, Dec 11, 2017 at 1:20 PM, Brad P. Crochet <b...@redhat.com> wrote:
> >
> >
> > On Fri, Dec 8, 2017 at 6:35 PM Alex Schultz <aschu...@redhat.com> wrote:
> >>
> >> Hey folks,
> >>
> >> So I went through the list of blueprints and moved some that were
> >> either not updated or appeared to have a bunch of patches not in a
> >> mergable state.
> >>
> >> Please take some time to review the list of blueprints currently
> >> associated with Rocky[0] to see if your efforts have been moved. If
> >> you believe you're close to implementing the feature in the next week
> >> or two, let me know and we can move it back into Queens. If you think
> >> it will take an extended period of time (more than 2 weeks) to land
> >> but we need it in Queens, please submit an FFE.
> >>
> >
> > I think these are in a close enough state to warrant inclusion in Queens:
> >
> > https://blueprints.launchpad.net/tripleo/+spec/get-networks-action
> >
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-list-available-roles-action
> >
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-select-roles-workflow
> > https://blueprints.launchpad.net/tripleo/+spec/update-networks-action
> > https://blueprints.launchpad.net/tripleo/+spec/validate-roles-networks
> > https://blueprints.launchpad.net/tripleo/+spec/update-roles-action
> >
>
> Ok I reviewed them and they do appear to have patches posted and are
> getting reviews.  I'll pull them back in to Queens and set the
> milestone to queens-3. Please make sure to update us on the status
> during this week and next week's IRC meetings. I would like to make
> sure these land ASAP. Do you think they should be in a state to land
> by the end of next week say 12/21?
>
> Thanks,
> -Alex
>
>
Yes. They will be in a state to land by 12/21.

Thanks,

Brad


> > There is a good chance of these being completed in the coming week.
> >
> > Thanks,
> >
> > Brad
> >>
> >>
> > --
> > Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
> > Principal Software Engineer
> > (c) 704.236.9385 <(704)%20236-9385>
> >
> >
> >
> __
> > 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] Blueprints moved out to Rocky

[Brad P. Crochet]

On Fri, Dec 8, 2017 at 6:35 PM Alex Schultz <aschu...@redhat.com> wrote:

> Hey folks,
>
> So I went through the list of blueprints and moved some that were
> either not updated or appeared to have a bunch of patches not in a
> mergable state.
>
> Please take some time to review the list of blueprints currently
> associated with Rocky[0] to see if your efforts have been moved. If
> you believe you're close to implementing the feature in the next week
> or two, let me know and we can move it back into Queens. If you think
> it will take an extended period of time (more than 2 weeks) to land
> but we need it in Queens, please submit an FFE.
>
>
I think these are in a close enough state to warrant inclusion in Queens:

https://blueprints.launchpad.net/tripleo/+spec/get-networks-action
https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-list-available-roles-action
https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-select-roles-workflow
https://blueprints.launchpad.net/tripleo/+spec/update-networks-action
https://blueprints.launchpad.net/tripleo/+spec/validate-roles-networks
https://blueprints.launchpad.net/tripleo/+spec/update-roles-action

There is a good chance of these being completed in the coming week.

Thanks,

Brad

>
> --
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Brad P. Crochet]

definite +1

On Wed, Nov 29, 2017 at 2:35 PM John Trowbridge <tr...@redhat.com> wrote:

> I would like to propose Ronelle be given +2 for the above repos. She has
> been a solid contributor to tripleo-quickstart and extras almost since the
> beginning. She has solid review numbers, but more importantly has always
> done quality reviews. She also has been working in the very intense rover
> role on the CI squad in the past CI sprint, and has done very well in that
> role.
> __
> 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] Proposing Wesley Hayutin core on TripleO CI

[Brad P. Crochet]

+1

On Wed, Dec 6, 2017 at 10:46 AM Emilien Macchi <emil...@redhat.com> wrote:

> Team,
>
> Wes has been consistently and heavily involved in TripleO CI work.
> He has a very well understanding on how tripleo-quickstart and
> tripleo-quickstart-extras work, his number and quality of reviews are
> excellent so far. His experience with testing TripleO is more than
> valuable.
> Also, he's always here to help on TripleO CI issues or just
> improvements (he's the guy filling bugs on a Saturday evening).
> I think he would be a good addition to the TripleO CI core team
> (tripleo-ci, t-q and t-q-e repos for now).
> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
> to move on and get you +2 ;-)
>
> As usual, it's open for voting, feel free to bring any feedback.
> Thanks everyone,
> --
> Emilien Macchi
>
> __
> 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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

Re: [openstack-dev] [TripleO] Deployment workflow changes for ui/client

[Brad P. Crochet]

On Thu, Oct 19, 2017 at 4:56 PM James Slagle <james.sla...@gmail.com> wrote:

> I've been looking at how we can hook up the deployment changes for
> config-download[1] with the existing deployment workflows in Mistral.
>
> However, it seems we have not sufficiently abstracted the logic to do
> a "deployment" behind a given workflow(s). The existing things a
> client (or UI) has to do is:
>
> - call tripleo.deployment.v1.deploy_plan
> - poll for success/failure of that workflow
> - poll for success/failure of in progress Heat stack (list events, etc)
> - call tripleo.deployment.v1.overcloudrc
> (probably more things too)
>
> If I want to make some changes to the deployment workflow, such that
> after the Heat stack operation is complete, we run a config-download
> action/workflow, then apply the generated ansible via
> ansible-playbook, I can't really do that without requiring all clients
> to also get updated to use those new steps (via calling new workflows,
> etc).
>
> As a first attempt, I took a shot at creating a workflow that does every
> step:
> https://review.openstack.org/#/c/512876/
> But even that will require client changes as it necessitates a
> behavior change in that the workflow has to wait for the stack to be
> complete as opposed to returning as soon as the stack operation is
> accepted by Heat.
>
>
Thankfully we already have that capability. :)


> I'd like to implement this in a way that minimizes the impact of
> changes on both python-tripleoclient and tripleo-ui, but it's looking
> as if some changes would be required to use this new ansible driven
> approach.
>
> Thoughts or feedback on how to proceed? I'm guess I'm also wondering
> if the existing API exposed by the workflows is easy to consume by the
> UI, or if it would be better to be wrapped in a single workflow...at
> least that way we could make logical implementation changes without
> requiring ui/cilent changes.
>
> [1] https://blueprints.launchpad.net/tripleo/+spec/ansible-config-download
>
>
+1 to all of this. I think from the CLI perspective, it should be a minimal
impact. If anything, it will get rid of a lot of code that doesn't really
belong. I can't say what the impact to the UI would be. However, one thing
that we should make sure of is that we send messages back through Zaqar to
keep the CLI and UI informed of what is occurring. That should happen
already with most of the existing workflows.

This is a great step in the right direction. The Workflows squad will be
happy to assist in any way we can. We will start by reviewing what you have
so far.


> --
> -- James Slagle
> --
>
> __
> 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] [stable][mistral] Asking for stable branch policy exception

[Brad P. Crochet]

On Wed, Oct 18, 2017 at 12:34 AM Renat Akhmerov <renat.akhme...@gmail.com>
wrote:

> Dougal,
>
> I forgot to mention that explicitly but, yes, #1 is needed only not to
> break the sequence of migrations. We can manually fix the migration number
> in #2 just for stable/pike but I somewhat don’t like the idea of having
> different migration numbers in different branches.
>
> It’s a good news that we’re not going to break TripleO.
>
> Thanks
>
>
My thought is take both. Not backporting the migration will break future
upgrades. We have literally been in this situation before.

Brad


>
> Renat Akhmerov
> @Nokia
>
> On 17 Oct 2017, 20:21 +0700, Dougal Matthews <dou...@redhat.com>, wrote:
>
>
>
> On 17 October 2017 at 09:19, Renat Akhmerov <renat.akhme...@gmail.com>
> wrote:
>
>> Hi,
>>
>> We have two patches in Mistral that we need to back port to stable/pike.
>> However, they are against of stable branch management policy because they
>> slightly change the DB schema. The patches are the following:
>>
>>1. https://review.openstack.org/#/c/512528/
>>2. https://review.openstack.org/#/c/512256/
>>
>>
>> #2 is a critically important fix that fixes a problem of decreasing
>> Mistral performance when DB becomes heavy (has lots of execution objects).
>> This is a blocker issue for us (Nokia) preventing us using Mistral in
>> production. It also seriously optimizes performance in general.
>>
>> So hereby I'm asking your advice on what we can do in this situation. Can
>> we merge these patches if we make sure that we don't break anyone in the
>> community? For example, TripleO.
>>
>
> As far as I am aware, this wont be a problem for TripleO. These patches
> are both additive (new db column and new db index).
>
> The first patch (512528) is only a candidate for backport to avoid
> breaking the migration history order, it isn't otherwise needed in Pike.
> How is this normally handled in other projects? i.e. we need to backport
> migration 24 to Pike, but 23 is in master only. I assume this problem has
> came up before and been solved, but I can't find any examples.
>
>
>
>>
>> Thanks
>>
>> Renat Akhmerov
>> @Nokia
>>
>> __
>> 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] [TripleO][DIB] how create triplo overcloud image with latest kernel?

[Brad P. Crochet]

On Tue, Sep 26, 2017 at 2:58 PM Ben Nemec <openst...@nemebean.com> wrote:

>
>
> On 09/26/2017 05:43 AM, Moshe Levi wrote:
> > Hi all,
> >
> > As part of the OVS Hardware Offload [1] [2],  we need to create new
> > Centos/Redhat 7 image  with latest kernel/ovs/iproute.
> >
> > We tried to use virsh-customize to install the packages and we were able
> > to update iproute and ovs, but for the kernel there is no space.
> >
> > We also tried with virsh-customize to uninstall the old kenrel but we no
> > luck.
> >
> > Is other ways to replace kernel  package in existing image?
>
> Do you have to use an existing image?  The easiest way to do this would
> be to create a DIB element that installs what you want and just include
> that in the image build in the first place.  I don't think that would be
> too difficult to do now that we're keeping the image definitions in
> simple YAML files.
>
>
If it is just packages, a DIB element wouldn't even be necessary. You could
define a new yaml that just adds the packages that you want, and add that
to the CLI when you build the images.


> >
> > [1] - https://review.openstack.org/#/c/504911/
> > <
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.openstack.org%2F%23%2Fc%2F504911%2F=02%7C01%7Cmoshele%40mellanox.com%7Cc801dab0778b428e226508d504c97ecf%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636420185839119329=6oEmh0LJacV3WPGGp3wW%2BhL3nPDxRh%2BzNPY67X09Blc%3D=0
> >
> >
> >
> > [2] - https://review.openstack.org/#/c/502313/
> > <
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.openstack.org%2F%23%2Fc%2F502313%2F=02%7C01%7Cmoshele%40mellanox.com%7Cc801dab0778b428e226508d504c97ecf%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636420185839119329=EsydZ9EsUjkYcF92Gys569SJEvQ%2B%2Fu6uV8WAQJ0YMfc%3D=0
> >
> >
> >
> >
> >
> >
> __
> > 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] [tripleo] add mistral to the auto-update package list for TripleO CI

[Brad P. Crochet]

On Thu, Aug 24, 2017 at 5:35 PM, Ben Nemec <openst...@nemebean.com> wrote:
> I think I'm +0 on this.  On the one hand we do have the gating job on
> Mistral, on the other hand our gate jobs don't exercise all of the
> functionality of some projects, especially Mistral.  I know in the past
> introspection has been broken by changes in Mistral, and that wouldn't be
> caught by gate jobs.  If we start using master all the time that becomes a
> blocker for TripleO since it will prevent our OVB jobs from passing.
>
> So I can understand the desire to use master of a tightly coupled project
> like Mistral, but it does open a hole in our promotion pipeline which I
> don't feel great about.  If we had an OVB job running on every patch (and
> respected by the Mistral cores) I'd be +1 with no reservations.

I am +1 on this. However, I do echo Ben's concerns. I will bring this
up with the Mistral group at the PTG. We already have an experimental
job available, but I'm guessing the major concern will be the amount
of time it takes for a TripleO job to run. It would likely double the
amount of time that a Mistral patch takes to get through CI.

>
>
> On 08/24/2017 04:04 PM, Wesley Hayutin wrote:
>>
>> Greetings,
>>
>> I'd like to propose that the mistral project be added to the list of
>> projects where in CI the very latest built packages are added to each CI run
>> [1].
>>
>> This will help get patches that depend on mistral patches to more quickly
>> be tested and merged.  For example Honza's patch [2] depends on a merged
>> mistral change.  The mistral change has not yet landed in a tripleo build
>> and mistral is not on the auto-update list, so the patch fails.
>>
>> Please respond if you would like to see mistral added or have any comments
>> or concerns.
>>
>> Note that we are able to consider mistral for auto-updates because the
>> mistral project has a voting tripleo job [3] and the tripleo project can be
>> assured that the latest mistral patches will not break tripleo-ci.
>>
>> I would encourage other projects to consider adding tripleo jobs to their
>> project to enable auto-updates as well [4] 
>>
>> [1]
>> https://github.com/openstack/tripleo-quickstart/blob/master/config/release/tripleo-ci/master.yml#L54-L70
>> [2] https://review.openstack.org/#/c/469608/
>> [3]
>> https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L11665
>> [4]
>> https://docs.openstack.org/tripleo-docs/latest/contributor/check_gates.html
>>
>>
>> ______
>> 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
>>
>



-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer

__
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] KVM Forum 2017: Call For Participation

[Daniel P. Berrange]

A quick reminder that the deadline for submissions to the KVM Forum
2017 is just 10 days away now, June 15.

On Tue, May 09, 2017 at 01:50:52PM +0100, Daniel P. Berrange wrote:
> 
> KVM Forum 2017: Call For Participation
> October 25-27, 2017 - Hilton Prague - Prague, Czech Republic
> 
> (All submissions must be received before midnight June 15, 2017)
> =
> 
> KVM Forum is an annual event that presents a rare opportunity
> for developers and users to meet, discuss the state of Linux
> virtualization technology, and plan for the challenges ahead. 
> We invite you to lead part of the discussion by submitting a speaking
> proposal for KVM Forum 2017.
> 
> At this highly technical conference, developers driving innovation
> in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can
> meet users who depend on KVM as part of their offerings, or to
> power their data centers and clouds.
> 
> KVM Forum will include sessions on the state of the KVM
> virtualization stack, planning for the future, and many
> opportunities for attendees to collaborate. As we celebrate ten years
> of KVM development in the Linux kernel, KVM continues to be a
> critical part of the FOSS cloud infrastructure.
> 
> This year, KVM Forum is joining Open Source Summit in Prague, 
> Czech Republic. Selected talks from KVM Forum will be presented on
> Wednesday October 25 to the full audience of the Open Source Summit.
> Also, attendees of KVM Forum will have access to all of the talks from
> Open Source Summit on Wednesday.
> 
> http://events.linuxfoundation.org/cfp
> 
> Suggested topics:
> * Scaling, latency optimizations, performance tuning, real-time guests
> * Hardening and security
> * New features
> * Testing
> 
> KVM and the Linux kernel:
> * Nested virtualization
> * Resource management (CPU, I/O, memory) and scheduling
> * VFIO: IOMMU, SR-IOV, virtual GPU, etc.
> * Networking: Open vSwitch, XDP, etc.
> * virtio and vhost
> * Architecture ports and new processor features
> 
> QEMU:
> * Management interfaces: QOM and QMP
> * New devices, new boards, new architectures
> * Graphics, desktop virtualization and virtual GPU
> * New storage features
> * High availability, live migration and fault tolerance
> * Emulation and TCG
> * Firmware: ACPI, UEFI, coreboot, U-Boot, etc.
> 
> Management and infrastructure
> * Managing KVM: Libvirt, OpenStack, oVirt, etc.
> * Storage: Ceph, Gluster, SPDK, etc.r
> * Network Function Virtualization: DPDK, OPNFV, OVN, etc.
> * Provisioning
> 
> 
> ===
> SUBMITTING YOUR PROPOSAL
> ===
> Abstracts due: June 15, 2017
> 
> Please submit a short abstract (~150 words) describing your presentation
> proposal. Slots vary in length up to 45 minutes. Also include the proposal
> type -- one of:
> - technical talk
> - end-user talk
> 
> Submit your proposal here:
> http://events.linuxfoundation.org/cfp
> Please only use the categories "presentation" and "panel discussion"
> 
> You will receive a notification whether or not your presentation proposal
> was accepted by August 10, 2017.
> 
> Speakers will receive a complimentary pass for the event. In the instance
> that case your submission has multiple presenters, only the primary speaker 
> for a
> proposal will receive a complimentary event pass. For panel discussions, all
> panelists will receive a complimentary event pass.
> 
> TECHNICAL TALKS
> 
> A good technical talk should not just report on what has happened over
> the last year; it should present a concrete problem and how it impacts
> the user and/or developer community. Whenever applicable, focus on
> work that needs to be done, difficulties that haven't yet been solved,
> and on decisions that other developers should be aware of. Summarizing
> recent developments is okay but it should not be more than a small
> portion of the overall talk.
> 
> END-USER TALKS
> 
> One of the big challenges as developers is to know what, where and how
> people actually use our software. We will reserve a few slots for end
> users talking about their deployment challenges and achievements.
> 
> If you are using KVM in production you are encouraged submit a speaking
> proposal. Simply mark it as an end-user talk. As an end user, this is a
> unique opportunity to get your input to developers.
> 
> HANDS-ON / BOF SESSIONS
> 
> We will reserve some time for people to get together and discuss
> strategic decisions as well as other topics that are best solved within
> smaller groups.
> 
> These sessions will be announc

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] [nova][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

[Daniel P. Berrange]

On Thu, May 25, 2017 at 11:38:44AM +0100, Duncan Thomas wrote:
> On 25 May 2017 at 11:00, Lee Yarwood  wrote:
> > This has also reminded me that the plain (dm-crypt) format really needs
> > to be deprecated this cycle. I posted to the dev and ops ML [2] last
> > year about this but received no feedback. Assuming there are no last
> > minute objections I'm going to move forward with deprecating this format
> > in os-brick this cycle.
> 
> What is the reasoning for this? There are plenty of people using it, and
> you're going to break them going forward if you remove it.

It has bad security management characteristics because the passphrase is
directly used to create the encryption key. Thus there's no way to update
the passphrase without re-encrypting all data in the device. If your passphrase
is compromised all data is compromised until you can do such re-encryption,
or you have to shred all copies of it, including any backups. If you want
todo the encryption in-place your VMs have to be taken offline too.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

__
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,
 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 <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.
>> 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 c

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

[openstack-dev] KVM Forum 2017: Call For Participation

[Daniel P. Berrange]

KVM Forum 2017: Call For Participation
October 25-27, 2017 - Hilton Prague - Prague, Czech Republic

(All submissions must be received before midnight June 15, 2017)
=

KVM Forum is an annual event that presents a rare opportunity
for developers and users to meet, discuss the state of Linux
virtualization technology, and plan for the challenges ahead. 
We invite you to lead part of the discussion by submitting a speaking
proposal for KVM Forum 2017.

At this highly technical conference, developers driving innovation
in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can
meet users who depend on KVM as part of their offerings, or to
power their data centers and clouds.

KVM Forum will include sessions on the state of the KVM
virtualization stack, planning for the future, and many
opportunities for attendees to collaborate. As we celebrate ten years
of KVM development in the Linux kernel, KVM continues to be a
critical part of the FOSS cloud infrastructure.

This year, KVM Forum is joining Open Source Summit in Prague, 
Czech Republic. Selected talks from KVM Forum will be presented on
Wednesday October 25 to the full audience of the Open Source Summit.
Also, attendees of KVM Forum will have access to all of the talks from
Open Source Summit on Wednesday.

http://events.linuxfoundation.org/cfp

Suggested topics:
* Scaling, latency optimizations, performance tuning, real-time guests
* Hardening and security
* New features
* Testing

KVM and the Linux kernel:
* Nested virtualization
* Resource management (CPU, I/O, memory) and scheduling
* VFIO: IOMMU, SR-IOV, virtual GPU, etc.
* Networking: Open vSwitch, XDP, etc.
* virtio and vhost
* Architecture ports and new processor features

QEMU:
* Management interfaces: QOM and QMP
* New devices, new boards, new architectures
* Graphics, desktop virtualization and virtual GPU
* New storage features
* High availability, live migration and fault tolerance
* Emulation and TCG
* Firmware: ACPI, UEFI, coreboot, U-Boot, etc.

Management and infrastructure
* Managing KVM: Libvirt, OpenStack, oVirt, etc.
* Storage: Ceph, Gluster, SPDK, etc.r
* Network Function Virtualization: DPDK, OPNFV, OVN, etc.
* Provisioning


===
SUBMITTING YOUR PROPOSAL
===
Abstracts due: June 15, 2017

Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes. Also include the proposal
type -- one of:
- technical talk
- end-user talk

Submit your proposal here:
http://events.linuxfoundation.org/cfp
Please only use the categories "presentation" and "panel discussion"

You will receive a notification whether or not your presentation proposal
was accepted by August 10, 2017.

Speakers will receive a complimentary pass for the event. In the instance
that case your submission has multiple presenters, only the primary speaker for 
a
proposal will receive a complimentary event pass. For panel discussions, all
panelists will receive a complimentary event pass.

TECHNICAL TALKS

A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, focus on
work that needs to be done, difficulties that haven't yet been solved,
and on decisions that other developers should be aware of. Summarizing
recent developments is okay but it should not be more than a small
portion of the overall talk.

END-USER TALKS

One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.

If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.

HANDS-ON / BOF SESSIONS

We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups.

These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at

  http://www.linux-kvm.org/page/KVM_Forum_2017_BOF

Let people you think who might be interested know about your BOF, and encourage
them to add their names to the wiki page as well. Please try to
add your ideas to the list before KVM Forum starts.


PANEL DISCUSSIONS

If you are proposing a panel discussion, please make sure that you list
all of your potential panelists in your the abstract. We will request full
biographies if a panel is accepted.


===
HOTEL / TRAVEL
===

This year's event will take place at the Hilton Prague.
For information on discounted room rates for conference attendees
and on other hotels close to the 

Re: [openstack-dev] [nova] Discussions for DPDK support in OpenStack

[Daniel P. Berrange]

On Fri, Apr 28, 2017 at 09:38:38AM +0100, sfinu...@redhat.com wrote:
> On Fri, 2017-04-28 at 13:23 +0900, TETSURO NAKAMURA wrote:
> > Hi Nova team,
> > 
> > I'm writing this e-mail because I'd like to have a discussion about
> > DPDK support at OpenStack Summit in Boston.
> > 
> > We have developed a dpdk-based patch panel named SPP[1], and we'd
> > like to start working on Openstack (ML2 driver) to develop
> > "networking-spp".
> > 
> > Especially, we'd like to use DPDK-ivshmem that was used to be used
> > to create "dpdkr" interface in ovs-dpdk[2].
> 
> To the best of my knowledge, IVSHMEM ports are no longer supported in
> upstream. The documentation for this feature was recently removed from
> OVS [1] stating:
> 
>   - The ivshmem library has been removed in DPDK since DPDK 16.11.
>   - The instructions/scheme provided will not work with current
>     supported and future DPDK versions.
>   - The linked patch needed to enable support in QEMU has never
>     been upstreamed and does not apply to the last 4 QEMU releases.
>   - Userspace vhost has become the defacto OVS-DPDK path to the guest.
> 
> Note: I worked on DPDK vSwitch [2] way back when, and there were severe
> security implications with sharing a chunk of host memory between
> multiple guests (which is how IVSHMEM works). I'm not at all surprised
> the feature was killed.

Security is only one of the issues. Upstream QEMU maintainers considered
the ivshmem device to have a seriously flawed design and discourage anyone
from using it. For anything network related QEMU maintainers strongly
recommand using vhost-user.

IIUC, there is some experimental work to create a virtio based replacement
for ivshmem, for non-network related vm-2-vm communications, but that is
not going to be something usable for a while yet. This however just
reinforces the point that ivshmem is considered obsolete / flawed
technology by QEMU maintainers.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

__
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

Re: [openstack-dev] [mistral] New CI Job definitions

[Brad P. Crochet]

On Tue, Apr 18, 2017 at 2:10 AM Ренат Ахмеров <renat.akhme...@gmail.com>
wrote:

> Thanks Brad!
>
> So kombu gate is now non-apache, right?
>
>
No. It would be running under mod_wsgi. We can make it non-apache if you
like. Would be pretty easy to do so.


> Thanks
>
> Renat Akhmerov
> @Nokia
>
> On 17 Apr 2017, 22:17 +0700, Brad P. Crochet <b...@redhat.com>, wrote:
>
> Hi y'all...
>
> In the midst of trying to track down some errors being seen with tempest
> tests whilst running under mod_wsgi/apache, I've made it so that the
> devstack plugin is capable of also running with mod_wsgi/apache.[1]
>
> In doing so, It's become the default devstack job. I've also now created
> some 'non-apache' jobs that basically are what the old jobs did, just
> renamed.
>
> Also, I've consolidated the job definitions (the original and the kombu)
> to simplify and DRY out the jobs. You can see the infra review here.[2]
>
> The list of jobs will be:
> gate-mistral-devstack-dsvm-ubuntu-xenial-nv
> gate-mistral-devstack-dsvm-non-apache-ubuntu-xenial-nv
> gate-mistral-devstack-dsvm-kombu-ubuntu-xenial-nv
>
> Note that the trusty jobs have been eliminated.
>
> Essentially, I've added a '{special}' tag to the job definition, allowing
> us to create special-cased devstack jobs. So, as you can see, I've migrated
> the kombu job to be such a thing. It should also be possible to combine
> them.
>
> [1] https://review.openstack.org/#/c/454710/
> [2] https://review.openstack.org/#/c/457106/
> --
> Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
> Principal Software Engineer
> (c) 704.236.9385 <(704)%20236-9385>
>
> __
> 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] [mistral] New CI Job definitions

[Brad P. Crochet]

Hi y'all...

In the midst of trying to track down some errors being seen with tempest
tests whilst running under mod_wsgi/apache, I've made it so that the
devstack plugin is capable of also running with mod_wsgi/apache.[1]

In doing so, It's become the default devstack job. I've also now created
some 'non-apache' jobs that basically are what the old jobs did, just
renamed.

Also, I've consolidated the job definitions (the original and the kombu) to
simplify and DRY out the jobs. You can see the infra review here.[2]

The list of jobs will be:
gate-mistral-devstack-dsvm-ubuntu-xenial-nv
gate-mistral-devstack-dsvm-non-apache-ubuntu-xenial-nv
gate-mistral-devstack-dsvm-kombu-ubuntu-xenial-nv

Note that the trusty jobs have been eliminated.

Essentially, I've added a '{special}' tag to the job definition, allowing
us to create special-cased devstack jobs. So, as you can see, I've migrated
the kombu job to be such a thing. It should also be possible to combine
them.

[1] https://review.openstack.org/#/c/454710/
[2] https://review.openstack.org/#/c/457106/
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
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] [all] Switching gate testing to use Ubuntu Cloud Archive

[Daniel P. Berrange]

On Tue, Apr 04, 2017 at 09:21:27AM -0700, Clark Boylan wrote:
> On Tue, Apr 4, 2017, at 06:36 AM, Daniel P. Berrange wrote:
> > On Mon, Apr 03, 2017 at 04:06:53PM -0700, Clark Boylan wrote:
> > > I have pushed a change to devstack [3] to enable using UCA which pulls
> > > in new Libvirt and mostly seems to work. I think we should consider
> > > switching to UCA as this may fix our Libvirt problems and if it doesn't,
> > > we will be closer to a version of Libvirt that upstream should be
> > > willing to fix.
> > > 
> > > This isn't the most straightfoward switch as UCA has a different repo
> > > for each OpenStack release. libvirt-python is sensitve to the underlying
> > > library changing; it is backward compatible but libvirt-python built
> > > against older libvirt won't work against new libvirt. The result is a
> > > libvirt-python wheel built on our wheel mirror does not work with UCA.
> > 
> > I'm surprised about that - could you elaborate on what's broken for you.
> > The libvirt.so provides a stable public API, and the standalone python
> > binding only uses public APIs from libvirt.so.  IOW you should be able
> > to build libvirt-python against 1.3.0 and then use it against 2.5.0 with
> > no problems.
> > 
> > NB, *before* libvirt-python lived on pypi, it used some non-public
> > libvirt.so symbols, so was tied to the exact libvirt.so it was built
> > against. Assuming you're using the pypi version this should no longer
> > apply.
> 
> The specific issue was "AttributeError: 'module' object has no attribute
> 'VIR_MIGRATE_POSTCOPY'" where module here is libvirt (full log and
> traceback at [0]). The libvirt-python module here was built against
> Libvirt 1.3.1 turned into a wheel and copied into our wheel mirror. Then
> when running against Libvirt 2.5.0 Nova seems to have detected that
> newer features should be present that are not reflected in the compiled
> libvirt-python resulting in the error. This crashed nova compute.
> 
> Problem was easily corrected by preventing devstack from using our wheel
> mirror for libvirt-python which resulted in a new installation built
> against Libvirt 2.5.0.
> 
> It seems like the API is stable enough for backward compatibility but
> not forward compatibility. Its also possible that Nova is doing version
> checking in a buggy way and should be checking what the libvirt-python
> version is and what it supports?

Ok, so yeah your last sentance is the correct interpretation. You've built
libvirt-python against libvirt v1.3.1, so it only includes support for
constants & methods that exist in that version. The VIR_MIGRATE_POSTCOPY
constant was introduced in v1.3.3, so it will not be included in the
libvirt-python you built.

When checking features Nova calls a libvirt API that returns the version
of the libvirtd daemon, which is v2.5.0, and then just blindly assumes
libvirt-python has the same version.

Unfortunately there is no way for Nova to determine what libvirt version
the python binding was built against, so it can't improve its version
check in this respect. To deal with this, Nova would two options:

 - Provide a nova.conf parameter to force it to assume an older libvirt
   version, thus disabling the features regardless of what libvirtd
   supports
 - Make nova check for existance of the python constants / APIs it is
   trying to use, in addition to checking the libvirt version

The first option is pretty trivial to do if needed. The second option would
be the more correct approach, but a much bigger maint burden, so I'm not
convinced it is worth it.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] Switching gate testing to use Ubuntu Cloud Archive

[Daniel P. Berrange]

On Tue, Apr 04, 2017 at 07:16:51AM -0400, Sean Dague wrote:
> This is definitely a trade off, I know the last time we tried UCA we had
> such a high failure rate we had to revert. But, that was a much younger
> libvirt that was only just starting to get heavy testing in OpenStack.
> So it feels like it's worth a shot. It will at least be interesting to
> see if it makes things better.
> 
> The libvirt bump will bring in libvirtd and live migration postcopy for
> testability on the Nova side, both of which would be good things.

NB, you'd need corresponding QEMU bump too for post-copy, but IIUC the
UCA contain that, so it'd be fine.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] Switching gate testing to use Ubuntu Cloud Archive

[Daniel P. Berrange]

On Mon, Apr 03, 2017 at 04:06:53PM -0700, Clark Boylan wrote:
> Hello,
> 
> One of the major sets of issues currently affecting gate testing is
> Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> and they happen frequently [0][1][2]. These issues appear to only affect
> Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> #openstack-nova it is clear that Libvirt isn't interested in debugging
> such an old version of Libvirt (1.3.1). And while it isn't entirely
> clear to me which exact version would be acceptable to them the Ubuntu
> Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).

If going to the libvirt upstream community for help, we'd generally want
to see the latest upstream release being used. Ideally along with willingness
to test git master if investigating a troublesome issue, but we understand
using git master is not practical for many people.

If using an old version provided by an OS distro, then we would generally
expect the OS distro maintainers to lead the investigation, and take the
responsibility for reproducing on latest upstream. Upstream libvirt simply
doesn't have bandwidth to do the OS distro maintainers job for them when
using old distro versions.

> I have pushed a change to devstack [3] to enable using UCA which pulls
> in new Libvirt and mostly seems to work. I think we should consider
> switching to UCA as this may fix our Libvirt problems and if it doesn't,
> we will be closer to a version of Libvirt that upstream should be
> willing to fix.
> 
> This isn't the most straightfoward switch as UCA has a different repo
> for each OpenStack release. libvirt-python is sensitve to the underlying
> library changing; it is backward compatible but libvirt-python built
> against older libvirt won't work against new libvirt. The result is a
> libvirt-python wheel built on our wheel mirror does not work with UCA.

I'm surprised about that - could you elaborate on what's broken for you.
The libvirt.so provides a stable public API, and the standalone python
binding only uses public APIs from libvirt.so.  IOW you should be able
to build libvirt-python against 1.3.0 and then use it against 2.5.0 with
no problems.

NB, *before* libvirt-python lived on pypi, it used some non-public
libvirt.so symbols, so was tied to the exact libvirt.so it was built
against. Assuming you're using the pypi version this should no longer
apply.

> Now its entirely possible that newer Libvirt will be worse than current
> (old) Libvirt; however, being closer to upstream should make getting
> fixes easier. Would be great if those with a better understanding of
> Libvirt could chime in on this if I am completely wrong here.

As a general rule your expectation is right - newer libvirt should
generally be better. There is always the chance of screwups, but we issue
maint releases where needed - the only question mark would be whether UCA
pulls in any maint releases. I would like to think that if such a problem
happened, openstack would be able to escalate it to a Canonical maintainer
to get a maint release / patch into UCA, since presumably any such bug
would be important to Canonical customers using OpenStack too.

> Finally it is worth noting that we will get newer packages of other
> software as well, most notably openvswitch will be version 2.6.1 instead
> of 2.5.0.

IIUC, you'd get newer QEMU/KVM too, which is arguably just as desirable
as getting newer libvirt.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [nova] Core team changes

[Daniel P. Berrange]

On Thu, Mar 09, 2017 at 05:14:08PM -0600, Matt Riedemann wrote:
> I wanted to let everyone know of some various core team changes within Nova.
> 
> nova-core
> -
> 
> I've discussed it with and removed Daniel Berrange (danpb) and Michael Still
> (mikal) from the nova-core team. Both are busy working on other projects and
> have been for awhile now, and I wanted to have the list reflect that
> reality. I'm sure both would have a short on-ramp to get back in should the
> situation change.
> 
> nova-specs-core
> ---
> 
> I've also removed Dan and Michael from nova-specs-core for the same reasons.
> 
> I've added Jay Pipes (jaypipes) and Sylvain Bauza (bauzas) to the
> nova-specs-core team. This was probably a long time coming. Both are very
> influential in the project and the direction and priorities from release to
> release.
> 
> nova-stable-maint
> -
> 
> During the PTG I added Sylvain to the nova-stable-maint core team. Sylvain
> knows the rules about the stable branch support phases and has a keen eye
> for what's appropriate and what's not for a backport.
> 
> --
> 
> Thank you to Daniel and Michael for everything they've done for Nova over
> the years and I hope them the best in their current work.  And thank you to
> Jay and Sylvain for the continuing work that you're doing to keep moving
> Nova forward.

FYI, I am also going to remove myself from os-vif core for the same reasons.
There are still seven other os-vif core members who are doing a fine job
at dealing with ongoing work there.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed: Removal of legacy per-project vanity domain redirects

[Daniel P. Berrange]

On Wed, Mar 08, 2017 at 09:12:59AM -0600, Monty Taylor wrote:
> Hey all,
> 
> We have a set of old vanity redirect URLs from back when we made a URL
> for each project:
> 
> cinder.openstack.org
> glance.openstack.org
> horizon.openstack.org
> keystone.openstack.org
> nova.openstack.org
> qa.openstack.org
> swift.openstack.org
> 
> They are being served from an old server we'd like to retire. Obviously,
> moving a set of http redirects is trivial, but these domains have been
> deprecated for about 4 now, so we figured we'd clean house if we can.
> 
> We know that the swift team has previously expressed that there are
> links out in the wild pointing to swift.o.o/content that still work and
> that they don't want to break anyone, which is fine. (although if the
> swift team has changed their minds, that's also welcome)
> 
> for the rest of you, can we kill these rather than transfer them?

Does the server have any access log that could provide stats on whether
any of the subdomains are a receiving a meaningful amount of traffic ?
Easy to justify removing them if they're not seeing any real traffic.

If there's any referrer logs present, that might highlight which places
still have outdated links that need updating to kill off remaining
traffic.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [third-party][ci] openstack CI VM template

[Daniel P. Berrange]

On Tue, Feb 28, 2017 at 07:49:01AM -0600, Mikhail Medvedev wrote:
> On Tue, Feb 28, 2017 at 2:52 AM, Guo, Ruijing  wrote:
> > Hi, CI Team,
> >
> >
> >
> > I’d like to know if openstack CI VM support nested virtualization.
> >
> 
> OpenStack CI infrastructure is using nested visualization inside of
> devstack VMs to perform tempest testing. But at the moment accel=tcg
> is used (emulation) for second level virt. IIRC it is done because
> some of the provider clouds had problems with KVM acceleration.

FYI, the QEMU & KVM maintainers still recommend *against* use of
nested-KVM in any production deployment, since they are not confident
of the security at this time. ie risk a level-2 guest could potentially
break out into either the level-1 guest or the physical host. This is
why the kvm kernel module requires an explicit opt-in to enable nested-KVM
on a host.

nested-KVM is improving, but there's no target date when it will
be considered ready for production use.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

[Daniel P. Berrange]

On Mon, Feb 27, 2017 at 10:30:33AM -0500, Artom Lifshitz wrote:
> >  - virtio-vsock - think of this as UNIX domain sockets between the host and
> >guest.  This is to deal with the valid use case of people wanting to use
> >a network protocol, but not wanting an real NIC exposed to the guest/host
> >for security concerns. As such I think it'd be useful to run the metadata
> >service over virtio-vsock as an option. It'd likely address at lesat some
> >people's security concerns wrt metadata service. It would also fix the
> >ability to use the metadat service in IPv6-only environments, as we would
> >not be using IP at all :-)
> 
> Is this currently exposed by libvirt? I had a look at [1] and couldn't
> find any mention of 'vsock' or anything that resembles what you've
> described.

Not yet. The basic QEMU feature merged in 2.8.0, but we're still wiring
up varous bits of userspace. eg selinux-policy, libvirt, nfs server, and
so on to understand vsock

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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 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] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

[Daniel P. Berrange]

On Mon, Feb 20, 2017 at 12:46:09PM -0500, Artom Lifshitz wrote:
> > But before doing that though, I think it'd be worth understanding whether
> > metadata-over-vsock support would be acceptable to people who refuse
> > to deploy metadata-over-TCPIP today.
> 
> Sure, although I'm still concerned that it'll effectively make tagged
> hotplug libvirt-only.

Well there's still the option of accessing the metadata server the
traditional way over IP which is fully portable.  If some deployments
choose to opt-out of this facility I don't neccessarily think we need
to continue to invent further mechanisms. At some point you have to
say what's there is good enough and if people choose to trade off
features against some other criteria so be it.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

[Daniel P. Berrange]

On Mon, Feb 20, 2017 at 05:07:53PM +, Tim Bell wrote:
> Is there cloud-init support for this mode or do we still need to mount
> as a config drive?

I don't think it particularly makes sense to expose the config drive
via NVDIMM - it wouldn't solve any of the problems that config drive
has today and it'd be less portable wrt guest OS.

Rather I was suggesting we should consider NVDIMM as a transport for
the role device tagging metadata standalone, as that could provide us
a way to live-update the metadata on the fly, which is impractical /
impossible when the metadata is hidden inside the config drive.

But before doing that though, I think it'd be worth understanding whether
metadata-over-vsock support would be acceptable to people who refuse
to deploy metadata-over-TCPIP today.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

[Daniel P. Berrange]

On Mon, Feb 20, 2017 at 10:46:09AM -0500, Artom Lifshitz wrote:
> I don't think we're trying to re-invent configuration management in
> Nova. We have this problem where we want to communicate to the guest,
> from the host, a bunch of dynamic metadata that can change throughout
> the guest's lifetime. We currently have two possible avenues for this
> already in place, and both have problems:
> 
> 1. The metadata service isn't universally deployed by operators for
> security and other reasons.
> 2. The config drive was never designed for dynamic metadata.
> 
> So far in this thread we've mostly been discussing ways to shoehorn a
> solution into the config drive avenue, but that's going to be ugly no
> matter what because it was never designed for what we're trying to do
> in the first place.
> 
> Some folks are saying that we admit that the config drive is only for
> static information and metadata that is known at boot time, and work
> on a third way to communicate dynamic metadata to the guest. I can get
> behind that 100%. I like the virtio-vsock option, but that's only
> supported by libvirt IIUC. We've got device tagging support in hyper-v
> as well, and xenapi hopefully on the way soon [1], so we need
> something a bit more universal. How about fixing up the metadata
> service to be more deployable, both in terms of security, and IPv6
> support?

FYI, virtio-vsock is not actually libvirt specific. the VSOCK sockets
transport was in fact invented by VMWare and first merged into Linux
in 2013 as a vmware guest driver.

A mapping of the VSOCK protocol over virtio was later defined to enable
VSOCK to be used with QEMU, KVM and Xen all of which support virtio.
The intention was explicitly that applications consuming VSOCK in the
guest would be portable between KVM & VMWare.

That said I don't think it is available via XenAPI, and doubt hyperv
will support it any time soon, but it is none the less a portable
standard if HVs decide they want such a feature.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

[Daniel P. Berrange]

On Mon, Feb 20, 2017 at 02:24:12PM +, Jeremy Stanley wrote:
> On 2017-02-20 13:38:31 + (+), Daniel P. Berrange wrote:
> [...]
> >Rather than mounting as a filesystem, you can also use NVDIMM directly
> >as a raw memory block, in which case it can contain whatever data format
> >you want - not merely a filesystem. With the right design, you could come
> >up with a format that let you store the role device metadata in a NVDIMM
> >and be able to update its contents on the fly for the guest during 
> > hotplug.
> [...]
> 
> Maybe it's just me, but this begs for a (likely fairly trivial?)
> kernel module exposing that data under /sys or /proc (at least for
> *nix guests).

The data is exposed either as a block device or as a character device
in Linux - which one depends on how the NVDIMM is configured. Once
opening the right device you can simply mmap() the FD and read the
data. So exposing it as a file under sysfs doesn't really buy you
anything better.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

[Daniel P. Berrange]

On Sat, Feb 18, 2017 at 01:54:11PM -0500, Artom Lifshitz wrote:
> A few good points were made:
> 
> * the config drive could be VFAT, in which case we can't trust what's
> on it because the guest has write access
> * if the config drive is ISO9660, we can't selectively write to it, we
> need to regenerate the whole thing - but in this case it's actually
> safe to read from (right?)
> * the point about the precedent being set that the config drive
> doesn't change... I'm not sure I 100% agree. There's definitely a
> precedent that information on the config drive will remain present for
> the entire instance lifetime (so the admin_pass won't disappear after
> a reboot, even if using that "feature" in a workflow seems ludicrous),
> but we've made no promises that the information itself will remain
> constant. For example, nothing says the device metadata must remain
> unchanged after a reboot.
> 
> Based on that here's what I propose:
> 
> If the config drive is vfat, we can just update the information on it
> that we need to update. In the device metadata case, we write a new
> JSON file, overwriting the old one.
> 
> If the config drive is ISO9660, we can safely read from it to fill in
> what information isn't persisted anywhere else, then update it with
> the new stuff we want to change. Then write out the new image.

Neither of these really cope with dynamically updating the role device
metdata for a *running* guest during a disk/nic hotplug for example.
You can't have the guest re-write the FS data that's in use by a running
guest.

For the CDROM based config drive, you would have to eject the virtual
media and insert new media.

IMHO, I'd just declare config drive readonly no matter what and anything
which requires dynamic data must use a different mechanism. Trying to
make config drive at all dynamic just opens a can of worms.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

[Daniel P. Berrange]

On Sat, Feb 18, 2017 at 08:11:10AM -0500, Artom Lifshitz wrote:
> In reply to Michael:
> 
> > We have had this discussion several times in the past for other reasons. The
> > reality is that some people will never deploy the metadata API, so I feel
> > like we need a better solution than what we have now.
> 
> Aha, that's definitely a good reason to continue making the config
> drive a first-class citizen.

FYI, there are a variety of other options available in QEMU for exposing
metadata from the host to the guest that may be a better option than either
config drive or network metadata service, that we should consider.

 - NVDIMM - this is an arbitrary block of data mapped into the guest OS
   memory space. As the name suggests, from a physical hardware POV this
   is non-volatile RAM, but in the virt space we have much more flexibilty.
   It is possible to back an NVDIMM in the guest with a plain file in the
   host, or with volatile ram in the host.

   In the guest, the NVDIMM can be mapped as a block device, and from there
   mounted as a filesystem. Now this isn't actually more useful that config
   drive really, since guest filesystem drivers get upset if the host changes
   the filesystem config behind its back. So this wouldn't magically make it
   possible to dynamically update role device metdata at hotplug time.

   Rather than mounting as a filesystem, you can also use NVDIMM directly
   as a raw memory block, in which case it can contain whatever data format
   you want - not merely a filesystem. With the right design, you could come
   up with a format that let you store the role device metadata in a NVDIMM
   and be able to update its contents on the fly for the guest during hotplug.

 - virtio-vsock - think of this as UNIX domain sockets between the host and
   guest.  This is to deal with the valid use case of people wanting to use
   a network protocol, but not wanting an real NIC exposed to the guest/host
   for security concerns. As such I think it'd be useful to run the metadata
   service over virtio-vsock as an option. It'd likely address at lesat some
   people's security concerns wrt metadata service. It would also fix the
   ability to use the metadat service in IPv6-only environments, as we would
   not be using IP at all :-)


Both of these are pretty new features only recently added to qemu/libvirt
so its not going to immediately obsolete the config drive / IPv4 metadata
service, but they're things to consider IMHO. It would be valid to say
the config drive role device tagging metadata will always be readonly,
and if you want dynamic data you must use the metdata service over IPv4
or virtio-vsock.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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-operators] [nova] Next minimum libvirt version

[Daniel P. Berrange]

On Thu, Feb 09, 2017 at 05:29:22PM -0600, Matt Riedemann wrote:
> Since danpb hasn't been around I've sort of forgotten about this, but we
> should talk about bumping the minimum required libvirt version in nova.
> 
> Currently it's 1.2.1 and the next was set to 1.2.9.
> 
> On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04 had
> 1.2.2).
> 
> If we move to require 1.2.9 that effectively kills 14.04 support for
> devstack + libvirt on master, which is probably OK.
> 
> There is also the distro support wiki [1] which hasn't been updated in
> awhile.
> 
> I'm wondering if 1.2.9 is a safe move for the next required minimum version
> and if so, does anyone have ideas on the next required version after that?

I think libvirt 1.2.9 is absolutely fine as a next version. It is still
ancient history comparatively speaking.

The more difficult question is what happens after that. To go further than
that effectively requires dropping Debian as a supportable platform since
AFAIK, they never rebase libvirt & next Debian major release is still
unannounced.  So the question is whether "stock" Debian is something the
project cares about targetting or will the answer be that Debian users
are required to pull in newer libvirt from elsewhere.

Also, it is just as important to consider minimum QEMU versions at the
same time, though it could just be set to the lowest common denominator
across distros that remain, after choosing the libvirt version.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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-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] [tacker] Tacker PTL Non-candidacy

[Sahdev P Zala]

Hi Sridhar, 

Thanks for your leadership in Tacker for last two years!! Great years for 
the project. I am glad that you will be continuing contributing to the 
project. I look forward to work with you for further collaboration between 
Tacker and TOSCA translator projects.

Regards, 
Sahdev Zala




From:   Sridhar Ramaswamy 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   01/18/2017 06:11 PM
Subject:[openstack-dev] [tacker] Tacker PTL Non-candidacy



As I announced in the last Tacker weekly meeting, I'm not planning to run 
for Pike PTL position. Having served in this role for the last three 
cycles (including for the periods before it was a big-tent project), I 
think it is time for someone else to step in and take this forward. I'll 
continue to contribute as a core-team member. I'll be available to help 
the new PTL in any ways needed.

Personally, it has been a such a rewarding experience. I would like to 
thank all the contributors - cores and non-core members - who supported 
this project and me. We had an incredible amount of cross-project 
collaboration in tacker, with the likes of tosca-parser / heat-translator, 
neutron networking-sfc, senlin, and mistral - my sincere thanks to all the 
PTLs and the members of those projects. 

Now going forward, we have tons to do in Tacker - towards making it a 
leading, community built TOSCA Orchestrator service. And that, not just 
for the current focus area of NFV but also expand into Enterprise and 
Container use-cases. Fun times!

thanks,
Sridhar
irc: sridhar_ram
__
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] [tosca-parser] [heat-translator] [heat] [tacker] [opnfv] heat-translator and tosca-parser 0.7.0

[Sahdev P Zala]

Hello Everyone, 

On behalf of the Heat Translator and TOSCA Parser team, I am pleased to 
announce the 0.7.0 PyPI release of heat-translator and tosca-parser which 
can be downloaded fromhttps://pypi.python.org/pypi/heat-translator and 
https://pypi.python.org/pypi/tosca-parser respectively. 

This release includes following enhancements, 
heat-translator:
  - new APIs to produce and access multiple translated templates
  - translation support for Heat SoftwareDeploymentGroup resource
  - new test templates
  - bug fixes
  - doc updates
tosca-parser:
  - support for parsing TOSCA qualified names
  - TOSCA substitution_mappings parsing and validation
  - support for get_operation_output function 
  - support for custom interfaces
  - enhanced template validation 
  - bug fixes
  - doc updates

Thanks!! 

Regards, 
Sahdev Zala


__
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-operators] [nova] Automatically disabling compute service on RBD EMFILE failures

[Daniel P. Berrange]

On Sat, Jan 07, 2017 at 12:04:25PM -0600, Matt Riedemann wrote:
> A few weeks ago someone in the operators channel was talking about issues
> with ceph-backed nova-compute and OSErrors for too many open files causing
> issues.
> 
> We have a bug reported that's very similar sounding:
> 
> https://bugs.launchpad.net/nova/+bug/1651526
> 
> During the periodic update_available_resource audit, the call to RBD to get
> disk usage fails with the EMFILE OSError. Since this is in a periodic it
> doesn't cause any direct operations to fail, but it will cause issues with
> scheduling as that host is really down, however, nothing sets the service to
> down (disabled).
> 
> I had proposed a solution in the bug report that we could automatically
> disable the service for that host when this happens, and then automatically
> enable the service again if/when the next periodic task run is successful.
> Disabling the service would take that host out of contention for scheduling
> and may also trigger an alarm for the operator to investigate the failure
> (although if there are EMFILE errors from the ceph cluster I'm guessing
> alarms should already be going off).
> 
> Anyway, I wanted to see how hacky of an idea this is. We already
> automatically enable/disable the service from the libvirt driver when the
> connection to libvirt itself drops via an event callback. This would be
> similar albeit less sophisticated as it's not using an event listening
> mechanism, we'd have to maintain some local state in memory to know if we
> need to enable/disable the service again. And it seems pretty
> hacky/one-offish to handle this just for the RBD failure, but maybe we just
> generically handle it for any EMFILE error when collecting disk usage in the
> resource audit?

Presumably this deployment was using the default Linux file limits
which are at a ridiculously low value of 1024. Ceph with 900 OSDs
will potentially need 900 files, not really leaving any slack for
Nova todo other work. I'd be willing to bet there are other scenarios
in which Nova would hit the 1024 FD limit under high usage, not merely
Ceph. So perhaps regardless of whether Ceph is used, we should just
recommend that you always run Nova with 4096 fds, and check that in
initialize() on startup and log a warning if the num files is lower
than this.

With pretty much all distros using systemd, it would be nice if Nova
shipped a standard systemd unit file, which could then also contain
the recommended higher FD limit so people get sane limits out of the
box.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] POC patch for using tripleo-repos for repo setup

[Brad P. Crochet]

On Wed, Nov 23, 2016 at 11:07 AM, Ben Nemec  wrote:
>
>
> On 11/22/2016 08:18 PM, Emilien Macchi wrote:
>>
>> Even if I was part of those who approved this feature, I still have
>> some comments, inline:
>>
>> On Tue, Nov 22, 2016 at 1:30 PM, Alex Schultz  wrote:
>>>
>>> On Tue, Nov 22, 2016 at 11:06 AM, Ben Nemec 
>>> wrote:



 On 11/21/2016 05:26 PM, Alex Schultz wrote:
>
>
> On Mon, Nov 21, 2016 at 2:57 PM, Ben Nemec 
> wrote:
>>
>>
>> Hi,
>>
>> I have a POC patch[1] up to demonstrate the use of the tripleo-repos
>> tool
>> [2] as a replacement for most of tripleo.sh --repo-setup.  It has now
>> passed
>> all of the CI jobs so I wanted to solicit some feedback.
>>
>> There are a few changes related to repo naming because the tool names
>> repo
>> files based on the repo name rather than always calling them something
>> generic like delorean.repo.  I think it's less confusing to have the
>> delorean-newton repo file named delorean-newton.repo, but I'm open to
>> discussion on that.
>>
>> If no one has any major objections to how the tool looks/works right
>> now,
>> I'll proceed with the work to get it imported into the openstack
>> namespace
>> as part of TripleO.  We can always iterate on it after import too, of
>> course, so this isn't a speak now or forever hold your peace
>> situation.
>> :-)
>>
>
> Why a python standalone application for the management of specifically
> (and only?) tripleo repositories.  It seems we should be trying to
> leverage existing tooling and not hiding the problem behind a python
> app.  It's not that I enjoy the current method described in the spec
> (3 curls, 1 sed, 1 bash thing, and a yum install) but it seems like to
> write 586 lines of python and tests might be the wrong approach.
> Would it be better to just devote some time to rpm generation for
> these and deliver it in discrete RPMs?  'yum install
> http://tripleo.org/repos-current.rpm' seems way more straight forward.



 That's essentially trading "curl ..." for "yum install ..." in the docs.
 The repo rpm would have to be part of the delorean build so you'd still
 have
 to be pointing people at a delorean repo.  It would also still require
 code
 changes somewhere to handle the mixed current/current-tripleo setup that
 we
 run for development and test. Given how specific to tripleo that is I'm
 not
 sure how much sense it makes to implement it elsewhere.

>>>
>>> I'm asking because essentially we're delivering basically static repo
>>> files.  Which should really be done via RPM. Upgrades and cleanups are
>>> already well established practices between RPMs.  I'm not seeing the
>>> reasoning why a python app.  I thought about this further and I'm not
>>> sure why this should be done on the client side via an app rather than
>>> at repository build/promotion time.  As long as we're including the
>>> repo rpm, we can always create simple 302 redirects from a webserver
>>> to get the latest version.  I don't see why we should introduce a
>>> client tool for this when the action is really on the repository
>>> packaging side.   This seems odd doing system configuration via a
>>> python script rather than a configuration management tool like
>>> ansible, puppet or even just packaging.
>>>
 There are also optional ceph and opstool repos and at least ceph needs
 to
 match the version of OpenStack being installed.  Sure, you could just
 document all that logic, but then the logic has to be reimplemented in
 CI
 anyway so you end up with code to maintain either way.  At least with
 one
 tool the logic is shared between the user and dev/test paths, which is
 one
 of the primary motivations behind it.  Pretty much every place that we
 have
 divergence between what users do and what developers do becomes a pain
 point
 for users because developers only fix the things they actually use.

>>>
>>> Yes we should not have a different path for dev/test vs operational
>>> deployments, but I'm not convinced we need to add a custom python tool
>>> to handle this only for tripleo.  There are already established
>>> patterns of repository rpm delivery and installation via existing
>>> tools.  What are we getting from this tool that can't already be done?
>>
>>
>> That is true, here are some of them:
>> - centos-release-ceph-(hammer|jewel) rpm that deploys repos.
>> - since we are moving TripleO CI to use tripleo-quickstart, we could
>> handle repository with Ansible, directly in the roles.
>
>
> This is exactly what I'm trying to avoid here.  I want us to be using the
> same thing for repo management in CI and dev and real user environments.
> Unless 

[openstack-dev] Recall: [nova] Nominating Stephen Finucane for nova-core

[P Kumaralingam]

P Kumaralingam would like to recall the message, "[openstack-dev] [nova] 
Nominating Stephen Finucane for nova-core".
__
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] [nova] Nominating Stephen Finucane for nova-core

[P Kumaralingam]

Hi Siva/Anusha,
What is the meaning of +1/-1 mentioned in below mail…

Also please subscribe to this mailing list… (on Monday).

Thanks & Regards,
P. Kumaralingam

From: Alex Xu [mailto:sou...@gmail.com]
Sent: Saturday, December 03, 2016 6:06 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [nova] Nominating Stephen Finucane for nova-core

+1

2016-12-02 23:22 GMT+08:00 Matt Riedemann 
<mrie...@linux.vnet.ibm.com<mailto:mrie...@linux.vnet.ibm.com>>:
I'm proposing that we add Stephen Finucane to the nova-core team. Stephen has 
been involved with nova for at least around a year now, maybe longer, my 
ability to tell time in nova has gotten fuzzy over the years. Regardless, he's 
always been eager to contribute and over the last several months has done a lot 
of reviews, as can be seen here:

https://review.openstack.org/#/q/reviewer:sfinucan%2540redhat.com

http://stackalytics.com/report/contribution/nova/180

Stephen has been a main contributor and mover for the config option cleanup 
series that last few cycles, and he's a go-to person for a lot of the 
NFV/performance features in Nova like NUMA, CPU pinning, huge pages, etc.

I think Stephen does quality reviews, leaves thoughtful comments, knows when to 
hold a +1 for a patch that needs work, and when to hold a -1 from a patch that 
just has some nits, and helps others in the project move their changes forward, 
which are all qualities I look for in a nova-core member.

I'd like to see Stephen get a bit more vocal / visible, but we all handle that 
differently and I think it's something Stephen can grow into the more involved 
he is.

So with all that said, I need a vote from the core team on this nomination. I 
honestly don't care to look up the rules too much on number of votes or 
timeline, I think it's pretty obvious once the replies roll in which way this 
goes.

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] [nova] Nominating Stephen Finucane for nova-core

[Daniel P. Berrange]

On Fri, Dec 02, 2016 at 09:22:54AM -0600, Matt Riedemann wrote:
> I'm proposing that we add Stephen Finucane to the nova-core team. Stephen
> has been involved with nova for at least around a year now, maybe longer, my
> ability to tell time in nova has gotten fuzzy over the years. Regardless,
> he's always been eager to contribute and over the last several months has
> done a lot of reviews, as can be seen here:
> 
> https://review.openstack.org/#/q/reviewer:sfinucan%2540redhat.com
> 
> http://stackalytics.com/report/contribution/nova/180
> 
> Stephen has been a main contributor and mover for the config option cleanup
> series that last few cycles, and he's a go-to person for a lot of the
> NFV/performance features in Nova like NUMA, CPU pinning, huge pages, etc.
> 
> I think Stephen does quality reviews, leaves thoughtful comments, knows when
> to hold a +1 for a patch that needs work, and when to hold a -1 from a patch
> that just has some nits, and helps others in the project move their changes
> forward, which are all qualities I look for in a nova-core member.
> 
> I'd like to see Stephen get a bit more vocal / visible, but we all handle
> that differently and I think it's something Stephen can grow into the more
> involved he is.
> 
> So with all that said, I need a vote from the core team on this nomination.
> I honestly don't care to look up the rules too much on number of votes or
> timeline, I think it's pretty obvious once the replies roll in which way
> this goes.

+1


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] Creating a new IRC meeting room ?

[Daniel P. Berrange]

On Fri, Dec 02, 2016 at 11:35:05AM +0100, Thierry Carrez wrote:
> Hi everyone,
> 
> There has been a bit of tension lately around creating IRC meetings.
> I've been busy[1] cleaning up unused slots and defragmenting biweekly
> ones to open up possibilities, but truth is, even with those changes
> approved, there will still be a number of time slots that are full:
> 
> Tuesday 14utc -- only biweekly available
> Tuesday 16utc -- full
> Wednesday 15utc -- only biweekly available
> Wednesday 16utc -- full
> Thursday 14utc -- only biweekly available
> Thursday 17utc -- only biweekly available
> 
> [1] https://review.openstack.org/#/q/topic:dec2016-cleanup
> 
> Historically, we maintained a limited number of meeting rooms in order
> to encourage teams to spread around and limit conflicts. This worked for
> a time, but those days I feel like team members don't have that much
> flexibility in picking a time that works for everyone. If the miracle
> slot that works for everyone is not available on the calendar, they tend
> to move the meeting elsewhere (private IRC channel, Slack, Hangouts)
> rather than change time to use a less-busy slot.
> 
> So I'm now wondering how much that artificial scarcity policy is hurting
> us more than it helps us. I'm still convinced it's very valuable to have
> a number of "meetings rooms" that you can lurk in and be available for
> pings, without having to join hundreds of channels where meetings might
> happen. But I'm not sure anymore that maintaining an artificial scarcity
> is helpful in limiting conflicts, and I can definitely see that it
> pushes some meetings away from the meeting channels, defeating their
> main purpose.
> TL;DR:
> - is it time for us to add #openstack-meeting-5 ?
> - should we more proactively add meeting channels in the future ?

Do we have any real data on just how many contributors really do
lurk in the meeting rooms permanently, as opposed to merely joining
rooms at start of the meeting & leaving immediately thereafter ?

Likewise any data on how many contributors are actively participate
in meetings across different projects, vs silod just in their own
one project ?

If the latter is in the clear majority, then you might as well just
have #openstack-meeting-$PROJECT and thus mostly avoid the problem
of conflicting demands for a limited set of channels.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [nova] away from Nova development for forseeable future

[Daniel P. Berrange]

Hi Folks,

I was recently tasked with spending some months working full time on
another project unrelated to OpenStack Nova. As such I am not likely
to be participating in any Nova related work for at least the Ocata
development cycle. At this time, I don't know whether I'll be returning
to Nova in the Pike cycle or not. I hope that other Red Hat folks will
be able to take over involvement in any work I was responsible for (eg in
particular os-vif related stuff or any libvirt driver work). Since I
won't be on IRC, if there's some show stopper that needs my help, I'd
encourage people to ping other Red Hat or Nova team members who should
have enough knowledge to help, or failing that, email me.

I've not resigned from Nova core, but realistically I'm not going to be
doing any reviews for 3-4 months at a minimum, so I'll leave it up to
PTL to decide what action to take, if any. Regardless I think that
Nova needs to look core membership more broadly given the recent loss of
Andrew from the team too.

Thus I'd encourage the project to either promote more community members
to the Nova core team to increase bandwidth, and/or consider alternative
strategies to reduce the core bottleneck, such as an intermediate layer
of people who have +2, but not +A.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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] [heat-translator][tosca-parser] No Weekly IRC meeting this week on Nov 24 - US holiday

[Sahdev P Zala]

Hello Team, 

A gentle reminder, as we discussed in the meeting last week, there will be 
no weekly meeting this week on Thursday Nov 24th due to Thanksgiving 
holiday in USA. 

Regards, 
Sahdev Zala

__
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] [nova] More file injection woes

[Daniel P. Berrange]

On Fri, Nov 11, 2016 at 07:11:51PM -0600, Matt Riedemann wrote:
> Chris Friesen reported a bug [1] where injected files on a server aren't in
> the guest after it's evacuated to another compute host. This is because the
> injected files aren't persisted in the nova database at all. Evacuate and
> rebuild use similar code paths, but rebuild is a user operation and the
> command line is similar to boot, but evacuate is an admin operation and the
> admin doesn't have the original injected files.
> 
> We've talked about issues with file injection before [2] - in that case not
> being able to tell if it can be honored and it just silently doesn't inject
> the files but the server build doesn't fail. We could eventually resolve
> that with capabilities discovery in the API.
> 
> There are other issues with file injection, like potential security issues,
> and we've talked about getting rid of it for years because you can use the
> config drive.
> 
> The metadata service is not a replacement, as noted in the code [3], because
> the files aren't persisted in nova so they can't be served up later.
> 
> I'm sure we've talked about this before, but if we were to seriously
> consider deprecating file injection, what does that look like?  Thoughts off
> the top of my head are:
> 
> 1. Add a microversion to the server create and rebuild REST APIs such that
> the personality files aren't accepted unless:
> 
> a) you're also building the server with a config drive
> b) or CONF.force_config_drive is True
> c) or the image has the 'img_config_drive=mandatory' property
> 
> 2. Deprecate VFSLocalFS in Ocata for removal in Pike. That means libguestfs
> is required. We'd do this because I think VFSLocalFS is the one with
> potential security issues.

Yes, VFSLocalFS is the dangerous one if used with untrustworthy disk images
(essentially all public cloud images are untrustworth) because malicious
images could be used to exploit bugs in the host kernels' filesystem drivers.
This isn't theoretical - we've seen bugs in popular linux filesystems (ie
ext3) lie mistakenly unfixed for years https://lwn.net/Articles/538898/

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
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