Re: [openstack-dev] [sahara] Nominating new members to Sahara Core

[Ethan Gafford]

On Fri, May 13, 2016 at 11:33 AM, Vitaly Gridnev 
wrote:

> Hello Sahara core folks!
>
> I'd like to bring the following folks to Sahara Core:
>
> 1. Lu Huichun
> 2. Nikita Konovalov
> 3. Chad Roberts
>
> Let's vote with +2/-2 for additions above.
>
> [0] http://stackalytics.com/?module=sahara-group
> [1] http://stackalytics.com/?module=sahara-group=mitaka
>
> --
> Best Regards,
> Vitaly Gridnev,
> Project Technical Lead of OpenStack DataProcessing Program (Sahara)
> Mirantis, Inc
>
> __
> 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
>
>
Lu Huichin: +2
Nikita Konovalov: +2
Chad Roberts: +2

All deeply well deserved after a great deal of work. Thanks!

- egafford
__
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] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Ethan Gafford]

On Wed, May 4, 2016 at 11:55 AM, Flavio Percoco  wrote:

> On 04/05/16 15:05 +, Amrith Kumar wrote:
>
>> I'm emailing the ML on the subject of a review ongoing in the Trove
>> project regarding image building[1].
>>
>> TL;DR
>>
>> One of the most frequent questions that new users of Trove ask is how and
>> where to get guest images with which to experiment with Trove, and how to
>> build these images for themselves. While documentation about this exists in
>> multiple places (including [2], [3]) this is still something that can do
>> with some improvement.
>>
>> Trove currently uses diskimage-builder for building images used in
>> testing the product and these can serve as a good basis for anyone wishing
>> to build an image for their own use of Trove. The review [1] makes the
>> argument for the libguestfs based approach to building images and advocates
>> that Trove should use this instead of diskimage-builder.
>>
>
> At the summit we discussed the possibility of providing an implementation
> that
> would allow for both DIB and libguestfs to be used but to give priority to
> DIB.
> Since there's no real intention of just switching tools at this point, I
> believe
> it'd be good to amend the spec so that it doesn't mention libguestfs
> should be
> used instead of DiB.
>
> The goal at this stage is to provide both and help these move forward.
>
> I believe that a broader discussion of this is required and I appreciate
>> Greg Haynes' proposal at the design summit to have this discussion on the
>> ML. I took the action item to bring this discussion to the ML.
>>
>> Details follow ...
>>
>> Before going further, I will state my views on these matters.
>>
>> 1. It is important for the Trove project to do things quickly to make it
>> easier for end users who wish to use Trove and who wish to build their own
>> images. I am not concerned what tool or tools a person will use to build
>> these images.
>>
>> 2. If we provide multiple alternatives to image building as part of the
>> Trove project, we should make sure that images built with all sets of tools
>> are equivalent and usable interchangeably. Failing to do this will make it
>> harder for users to use Trove because we will be providing them with a
>> false choice (i.e. the alternatives aren't really alternatives). This is
>> harder than it sounds given the combination of tools, operating systems,
>> and the source(s) from which you can get database software.
>>
>
> Maintaining both in the long run will be harder especially because, as you
> mentioned, the output must be usable interchangeably. However, I think
> we're at
> a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano
> and
> some other folks that it'd be beneficial for us to have this discussion
> and to
> also experiment/test other options.
>
> The Sahara team seems to be going in a direction that differs with the one
> used
> by the infra team and the one we're headed to (although they overlap in
> some
> areas).
>

Sahara has support for several image generation-related cases:
1) Packing an image pre-cluster spawn in Nova.
2) Building clusters from a "clean" OS image post-Nova spawn, by
downloading and installing Hadoop/Spark/Storm/WhatHaveYou.
3) Validating images after Nova spawn (to ensure that they're up to spec
for the plugin in question.)

Because of this, we are pulling image generation logic into the plugins
themselves, from a monolithic sahara-image-elements repository. This will
aid us in our eventual hope to pull plugins out of the Sahara tree
entirely; more immediately, it will allow us to define logic for all of
these cases in one place, written eventually in Python. In our Sahara
session at summit, which was also attended by several members of the Ironic
team (thanks all), we discussed our current plan to use libguestfs rather
than DIB as our toolchain; our intent to define a linear, idempotent set of
steps to pack images for any plugin lends itself much more neatly to
libguestfs' API than to DIB's.


> 3. Trove already has elements for all supported databases using DIB in the
>> trove-integration project but these elements are not packaged for customer
>> use. Making them usable by customers is a relatively small effort including
>> providing a wrapper script (derived from redstack[4]) and providing an
>> element to install the guest agent software from a fixed location in
>> addition to the development and testing version that is better suited to
>> Trove development [5] and [6].
>>
>> 4. My comments on various patch sets in the review[1].
>>
>> I agree with Monty and Greg Haynes that we should understand the
>> deficiencies if any in DIB, and if it is in fact the case that they are
>> "intractable/unsolvable", we should switch toolchains. This discussion
>> should include issues faced by the Trove team as well as other teams that
>> may have faced problems with DIB (such as the sahara team who described
>> some of them in the past).

Re: [openstack-dev] [sahara] Proposing Vitaly Gridnev to core reviewer team

[Ethan Gafford]

I'm a very hearty +1 to this; Vitaly's a critical driver of both reviews and 
features in Sahara.

Cheers,
Ethan

- Original Message -
From: "michael mccune" 
To: openstack-dev@lists.openstack.org
Sent: Monday, October 12, 2015 8:49:18 AM
Subject: Re: [openstack-dev] [sahara] Proposing Vitaly Gridnev to core reviewer 
team

i'm +1 for this, Vitaly has been doing a great job contributing code and 
reviews to the project.

mike

On 10/12/2015 07:19 AM, Sergey Lukjanov wrote:
> Hi folks,
>
> I'd like to propose Vitaly Gridnev as a member of the Sahara core
> reviewer team.
>
> Vitaly contributing to Sahara for a long time and doing a great job on
> reviewing and improving Sahara. Here are the statistics for reviews
> [0][1][2] and commits [3].
>
> Existing Sahara core reviewers, please vote +1/-1 for the addition of
> Vitaly to the core reviewer team.
>
> Thanks.
>
> [0]
> https://review.openstack.org/#/q/reviewer:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z
> [1] http://stackalytics.com/report/contribution/sahara-group/180
> [2] http://stackalytics.com/?metric=marks_id=vgridnev
> [3]
> https://review.openstack.org/#/q/status:merged+owner:%22Vitaly+Gridnev+%253Cvgridnev%2540mirantis.com%253E%22,n,z
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
>
>
> __
> 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] [sahara] FFE request for heat wait condition support

[Ethan Gafford]

Seems reasonable; +1.

-Ethan

>- Original Message -
>From: "michael mccune" 
>To: openstack-dev@lists.openstack.org
>Sent: Friday, September 4, 2015 12:16:24 PM
>Subject: Re: [openstack-dev] [sahara] FFE request for heat wait condition 
>support
>
>makes sense to me, +1
>
>mike
>
>On 09/04/2015 06:37 AM, Vitaly Gridnev wrote:
>> +1 for FFE, because of
>>   1. Low risk of issues, fully covered with current scenario tests;
>>   2. Implementation already on review
>>
>> On Fri, Sep 4, 2015 at 12:54 PM, Sergey Reshetnyak
>> > wrote:
>>
>> Hi,
>>
>> I would like to request FFE for wait condition support for Heat engine.
>> Wait condition reports signal about booting instance.
>>
>> Blueprint:
>> https://blueprints.launchpad.net/sahara/+spec/sahara-heat-wait-conditions
>>
>> Spec:
>> 
>> https://github.com/openstack/sahara-specs/blob/master/specs/liberty/sahara-heat-wait-conditions.rst
>>
>> Patch:
>> https://review.openstack.org/#/c/169338/
>>
>> Thanks,
>> Sergey Reshetnyak
>>
>> 
>> __
>> 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
>>
>>
>>
>>
>> --
>> Best Regards,
>> Vitaly Gridnev
>> Mirantis, Inc
>>
>>
>> __
>> 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] [sahara] FFE request for scheduler and suspend EDP job for sahara

[Ethan Gafford]

Sadly, in reviewing the client code, Vitaly is right; the current client will 
not support this feature, which would make it direct REST call only. Given 
that, I am uncertain it is worth the risk. I'd really love to have seen this go 
in; it's a great feature and a lot of work has gone into it, but perhaps it 
should be a great feature in M. 

If we agree to cut a new client point release, I could see this, but for now I 
fear I'm -1. 

Thanks, 
Ethan 

>From: "lu jander"  
>To: "OpenStack Development Mailing List (not for usage questions)" 
> 
>Sent: Monday, September 7, 2015 1:26:49 PM 
>Subject: Re: [openstack-dev] [sahara] FFE request for scheduler and suspend 
>EDP job for sahara 
> 
>Hi Vitaly, 
>enable-scheduled-edp-jobs patch has 34 patch sets review. 
>https://review.openstack.org/#/c/182310/ , it has no impact with another 
>working in process patch. 
> 
>2015-09-07 18:48 GMT+08:00 Vitaly Gridnev : 
> 
> Hey! 
> 
> From my point of view, we definetly should not give FFE for 
> add-suspend-resume-ability-for-edp-jobs spec, because client side for this 
> change is not included in official liberty release. 
> 
> By the way, I am not sure about FFE for enable-scheduled-edp-jobs, because 
> it's not clear which progress of these blueprint. Implementation of that 
> consists with 2 patch-sets, and one of that marked as Work In Progress. 
> 
> 
> On Sun, Sep 6, 2015 at 7:18 PM, lu jander  wrote: 
> 
> Hi, Guys 
> 
> I would like to request FFE for scheduler EDP job and suspend EDP job for 
> sahara. these patches has been reviewed for a long time with lots of patch 
> sets. 
> 
> Blueprint: 
> 
> (1) https://blueprints.launchpad.net/sahara/+spec/enable-scheduled-edp-jobs 
> (2) 
> https://blueprints.launchpad.net/sahara/+spec/add-suspend-resume-ability-for-edp-jobs
>  
> 
> Spec: 
> 
> (1) https://review.openstack.org/#/c/175719/ 
> (2) https://review.openstack.org/#/c/198264/ 
> 
> 
> Patch: 
> 
> (1) https://review.openstack.org/#/c/182310/ 
> (2) https://review.openstack.org/#/c/201448/ 
> 
> __ 
> 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 
> 
> 
> 
> 
> -- 
> Best Regards, 
> Vitaly Gridnev 
> Mirantis, Inc 
> 
> __ 
> 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] [sahara] FFE request for nfs-as-a-data-source

[Ethan Gafford]

This seems like a sanely scoped exception, and wholly agreed about
spinning off the UI into a separate bp. +1.

-Ethan

>- Original Message -
>From: "michael mccune" 
>To: "OpenStack Development Mailing List (not for usage questions)" 
>
>Sent: Wednesday, September 9, 2015 5:33:01 PM
>Subject: Re: [openstack-dev] [sahara] FFE request for nfs-as-a-data-source
>
>i'm +1 for this feature as long as we talking about just the sahara
>controller and saharaclient. i agree we probably cannot get the horizon
>changes in before the final release.
>
>mike
>
>On 09/09/2015 03:33 AM, Chen, Weiting wrote:
>> Hi, all.
>>
>> I would like to request FFE for nfs as a data source for sahara.
>>
>> This bp originally should include a dashboard change to create nfs as a
>> data source.
>>
>> I will register it as another bp and implement it in next version.
>>
>> However, these patches have already done to put nfs-driver into
>> sahara-image-elements and enable it in the cluster.
>>
>> By using this way, the user can use nfs protocol via command line in
>> Liberty release.
>>
>> Blueprint:
>>
>> https://blueprints.launchpad.net/sahara/+spec/nfs-as-a-data-source
>>
>> Spec:
>>
>> https://review.openstack.org/#/c/210839/
>>
>> Patch:
>>
>> https://review.openstack.org/#/c/218637/
>>
>> https://review.openstack.org/#/c/218638/
>>
>>
>>
>> __
>> 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
>

- Original Message -
From: "michael mccune" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, September 9, 2015 5:33:01 PM
Subject: Re: [openstack-dev] [sahara] FFE request for nfs-as-a-data-source

i'm +1 for this feature as long as we talking about just the sahara 
controller and saharaclient. i agree we probably cannot get the horizon 
changes in before the final release.

mike

On 09/09/2015 03:33 AM, Chen, Weiting wrote:
> Hi, all.
>
> I would like to request FFE for nfs as a data source for sahara.
>
> This bp originally should include a dashboard change to create nfs as a
> data source.
>
> I will register it as another bp and implement it in next version.
>
> However, these patches have already done to put nfs-driver into
> sahara-image-elements and enable it in the cluster.
>
> By using this way, the user can use nfs protocol via command line in
> Liberty release.
>
> Blueprint:
>
> https://blueprints.launchpad.net/sahara/+spec/nfs-as-a-data-source
>
> Spec:
>
> https://review.openstack.org/#/c/210839/
>
> Patch:
>
> https://review.openstack.org/#/c/218637/
>
> https://review.openstack.org/#/c/218638/
>
>
>
> __
> 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] [Openstack] [Horizon] [Sahara] FFE request for Sahara unified job interface map UI

[Ethan Gafford]

Hello all,

I request a FFE for the change at: https://review.openstack.org/#/c/209683/

This change enables a significant improvement to UX in Sahara's elastic data 
processing flow which is already in the server and client layers of Sahara. 
Because it specifically aims at improving ease of use and comprehensibility, 
Horizon integration is critical to the success of the feature. The change 
itself is reasonably modular and thus low-risk; it will have no impact outside 
Sahara's job template creation and launch flow, and (failing unforseen issues) 
no impact to users of the existing flow who choose not to use this feature.

Thank you,
Ethan

__
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] [sahara] Request for Feature Freeze Exception

[Ethan Gafford]

Agreed. We've talked about this for a while, and it's very low risk.

Thanks,
Ethan

- Original Message -
From: "michael mccune" 
To: openstack-dev@lists.openstack.org
Sent: Thursday, September 3, 2015 3:53:41 PM
Subject: Re: [openstack-dev] [sahara] Request for Feature Freeze Exception

On 09/03/2015 02:49 PM, Vitaly Gridnev wrote:
> Hey folks!
>
> I would like to propose to add to list of FFE's following blueprint:
> https://blueprints.launchpad.net/sahara/+spec/drop-hadoop-1
>
> Reasoning of that is following:
>
>   1. HDP 1.3.2 and Vanilla 1.2.1 are not gated for a whole release
> cycle, so it can be reason of several bugs in these versions;
>   2. Minimal risk of removal: it doesn't touch versions that we already
> have.
>   3. All required changes was already uploaded to the review:
> https://review.openstack.org/#/q/status:open+project:openstack/sahara+branch:master+topic:bp/drop-hadoop-1,n,z

this sounds reasonable to me

mike


__
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] [sahara] Bug triage/fix and doc update days in Liberty

[Ethan Gafford]

Hello all,

Bugfix days for Liberty's Sahara release have begun! Please sign up for bug 
fixes at: 
https://etherpad.openstack.org/p/sahara-liberty-bug-fix-day

Cheers,
Ethan Gafford
Senior Software Engineer
OpenStack Sahara
Red Hat, Inc.

- Original Message -
From: Sergey Lukjanov slukja...@mirantis.com
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Sent: Thursday, August 13, 2015 11:12:33 AM
Subject: [openstack-dev] [sahara] Bug triage/fix and doc update days in Liberty

Hi folks, 

on todays IRC meeting [0] we've agreed to have: 

1) Bug triage day on Aug 17 
We're looking for the volunteer to coordinate it ;) If someone wants to do it, 
please, reply to this email. 
http://etherpad.openstack.org/p/sahara-liberty-bug-triage-day 


2) Bug fix day on Aug 24 
Ethan (egafford) volunteered to coordinate it. 
http://etherpad.openstack.org/p/sahara-liberty-bug-fix-day 


3) Doc update day on Aug 31 
Mike (elmiko) volunteered to coordinate it. 
http://etherpad.openstack.org/p/sahara-liberty-doc-update-day 


Coordinators, please, add some initial notes to the ether pads and ensure that 
folks will be using them to sync efforts. For communication let's use 
#openstack-sahara IRC channel as always. 

Thanks. 

[0] 
http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-08-13-14.00.html
 

-- 
Sincerely yours, 
Sergey Lukjanov 
Sahara Technical Lead 
(OpenStack Data Processing) 
Principal Software Engineer 
Mirantis Inc. 

__
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] [Horizon][Sahara] FFE Request for bp/sahara-shell-action-form

[Ethan Gafford]

I'm requesting a FFE for a Data Processing (Sahara) feature.

The job type that this form supports is merged for Kilo on the backend.

The patch (which has no unmerged dependencies) is here: 
https://review.openstack.org/#/c/160510/

Thank you,
Ethan

__
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