Re: [openstack-dev] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread Sergey Lukjanov
+2

On Thu, Aug 11, 2016 at 8:48 AM, Elise Gafford <egaff...@redhat.com> wrote:

> Hearty +2. Telles has been working on Sahara for years, and has been a
> consistent and incisive reviewer and code contributor.
>
> Congratulations Telles; very well deserved!
>
> - Elise
>
> On Thu, Aug 11, 2016 at 11:37 AM, Vitaly Gridnev <vgrid...@mirantis.com>
> wrote:
>
>> Hello core team,
>>
>> I'd like to nominate Telles Mota Vidal Nóbrega for core reviewer team.
>> Let's vote with +2/-2 for his candidacy. Review/Commits stats can be found
>> at [0].
>>
>> [0] http://stackalytics.com/?module=sahara-group_id=tellesmvn
>>
>> --
>> 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: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
>
>


-- 
Sincerely yours,
Sergey Lukjanov
Sr. Development Manager
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


Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-28 Thread Sergey Lukjanov
ssion statement change was needed
>> by Fuel if they wanted to proceed down this path, to which I was told K8S
>> support is not going into big tent.
>>
>> As a result of Mirantis's change in mind about fuel-ccp being NOT
>> experimental and being targeted for big tent, I'd like the record set
>> straight in the governance repository since the intentions are being
>> published in the press and the current intentions of this project are
>> public.
>>
>
> If I can be honest, I think this whole thread is not going anywhere
> because it
> just started based on the wrong assumption, the wrong tone and with poor
> wording. I'd have asked for clarifications before demanding changes from
> anyone.
> To me, the way this thread started violates one of principles of our
> community,
> which is assuming good faith. I'll assume good faith now and interpret this
> thread as a hope to clarify the goals and intentions of this projects and
> not as
> a way to bluntly point fingers, which is how some people might have
> perceived
> it.
>
> I could see how people could perceive many violations of the four opens in
>> all of the activities related to the fuel-ccp project.  We as a community
>> value open discourse because we are all intelligent human beings.  We
>> value honesty and integrity because trust is the foundation of how our
>> community operates.  I feel the best way for Fuel to repair the perceived
>> violations of the four opens going forward is to:
>>
>
> I honestly don't see the violation. The fuel team added these repos and
> explicitly said they are not planning to join the tent right now. Adding
> new
> repos called `fuel-blah` won't make those deliverables official. Whenever
> the
> team decides to make these deliverables part of Fuel, they'll have to send
> a
> patch to the governance repo.
>
> So, again, where's the lack of openess? Is it just based on the content of
> the
> press release? I'm mostly asking because I don't personally read press
> releases
> when reviewing patches for the governance repo. I do see the inconsistency
> between the press release and what's in the repos/reviews but I in those
> cases,
> the governance repository is the source of truth not the press release.
>
> 1. Alter the mission statement of fuel to match the reality being
>> published by the press and Mirantis's executive team
>> 2. Include these non-experimental repos in the projects.yaml governance
>> repository
>>
>
> What would have happened if the project names would've been
> "my-super-openstack-container-project"?
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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
>
>


-- 
Sincerely yours,
Sergey Lukjanov
Sr. Development Manager
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-dev] [fuel] Containerized OpenStack on Kubernetes experimental project proposal

2016-06-17 Thread Sergey Lukjanov
Hi,

I'd like to share proposal on running the experimental project under the
Fuel
umbrella for running OpenStack in containers on top of Kubernetes,
codename "Fuel CCP".

Here is a specification in Fuel: https://review.openstack.org/331139

CCP is the initiative to package OpenStack services in the containers and
use standard container management framework to run and manage them. It
includes following areas, but not limited to them:

* OpenStack containerization and container image building tooling
* CI/CD to produce properly layered and versioned containers for the
supported
  stable and current master branches of OpenStack projects
* OpenStack deployment in containers on top of Kubernetes with HA for
OpenStack
  services and their dependencies (e.g. MySQL, RabbitMQ, etc.)
* Tooling for deploying and operating OpenStack clusters with support for
the
  upgrades, patching, scaling and changing configuration

As for the governance - Fuel CCP will be just a separated experimental
project
under OpenStack namespace with own specs and core team. The nearest example
of
the same governance is 3rd party Fuel plugin done not by Mirantis.

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
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-dev] [kolla] Potential direction proposal - unified OpenStack containers

2016-06-16 Thread Sergey Lukjanov
Hi folks,

I'd like to share some thoughts about the OpenStack containerization in the
form of a specification for Kolla and have some discussion on the proposed
items in the review.

In general it's a meta spec to describe potential direction for Kolla to
provide Unified deployment tool agnostic containers for anyone to use.

We very much welcome your feedback on the following spec.

Link: https://review.openstack.org/330575

Thanks.


-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [kolla] kolla-mesos development being scaled back

2016-04-22 Thread Sergey Lukjanov
Hi folks, just posting a link to the email covering Mirantis position on it.

http://lists.openstack.org/pipermail/openstack-dev/2016-April/093143.html

On Wed, Apr 20, 2016 at 9:51 AM, Gerard Braad <m...@gbraad.nl> wrote:

> On Wed, Apr 20, 2016 at 2:40 PM, Steven Dake (stdake) <std...@cisco.com>
> wrote:
> > Unfortunately
> > the project implementors don't intend to continue its development in the
> > Open, but instead take it "internal" and work on it privately.  I
> disagree
> > with this approach, but as the PTL of Kolla I have done everything I can
> to
> > provide an inviting positive working environment
>
> Thanks for the information. Very unfortunate, I hope they will
> reconsider this choice.
>
> --
> Gerard Braad — 吉拉德
>F/OSS & IT Consultant in Beijing
>http://gbraad.nl  gpg: 0x592CFE75
>
> __
> 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
>



-- 
Sincerely yours,
Sergey Lukjanov
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-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes

2016-04-22 Thread Sergey Lukjanov
Hi folks,

I’ve been approached by multiple people asking questions about what is
happening with Mirantis engineers activity around the kolla-mesos project
we started and I do feel that I owe an explanation to the community.

Indeed during the last few months we significantly reduced the amount of
contribution. Jumping straight to the point, I would like to say right away
that we will have to abandon the kolla-mesos initiative. If anybody would
like to pick it up and continue moving forward, Mirantis will do everything
we can to help with the ownership transition including sharing what we
learned along the way.

Now please let me explain the reasons behind this decision which I hope
will turn into an active discussion in the OpenStack community. When we
started work on the containerization of OpenStack we did not have a clear
picture of the design choices and decisions that would need to be made.
What we knew there is a community project around the effort - Kolla, and we
decided to try and explore the opportunity to join these efforts.

First let me express my gratitude towards the Kolla community for their
willingness to help and support our efforts. The way the Kolla project
accepted and helped new people join the project is one of the fundamental
behaviours that makes me really proud to be a part of the OpenStack
community.

During the journey working in Kolla, we discovered that there are quite a
few fundamental mismatches between where we believe we need to arrive
running OpenStack containers inside orchestration framework like Mesos and
Kubernetes and the Kolla direction of running containers using Ansible.
While there is nothing wrong with either approach, there are some technical
difficulties which lead to conflicting requirements, for example:

* Containers definition should be easy readable and maintainable, it should
provide meta information such as list of the packages to be installed in
the container, etc (container image building DSL is one of the options to
implement it);
* It should be possible to implement containers layering, naming and
versioning in a way to support upgradability and patching, especially in
terms of shipping security updates and upgrades to the users;
* Containers implementation should be clear from the bootstrap and init
scripts;
* Repository per OpenStack and Infra component, e.g. one from nova, one for
neutron and etc. - to contain all needed container images for running
corresponding services in different topologies;
* It should be possible to use other containers, not just docker, for
example - rkt.

Since we believed Kolla would likely have to change direction to support
what we needed but we still were not sure in the exact technical direction
needed to take, Mirantis decided to take a pause to prevent unnecessary
churn to project and run a number of research initiative to experiment with
different concepts.

While the above work was happening, Mirantis was also tracking how the
Kubernetes project and community were developing. We were very glad to see
significant progress made over a short period of time and community
momentum build similar to how OpenStack grew in the early days. As part of
our exploration activities we decided to give Kubernetes a try to see if we
could make containerized OpenStack work on Kubernetes and better understand
what changes to OpenStack itself would be needed to best support this
approach.

At this point I’m glad to announce that I was able to do a very simple PoC
(~1.5 weeks) with the core OpenStack control plane services running on top
of Kubernetes. I’ve recorded a demo showing how it’s working [1].

Based on our research activities and rapid growth of the Kubernetes
community, which shares many parallels to the OpenStack community, we are
switching our efforts to focus on running OpenStack on Kubernetes. We are
going to do the development work upstream and as part of that share and
contribute results of prototyping and research work we have done so far.

We are considering multiple options on what is the right place in community
for this work to happen: re-join the work with the Kolla project, start a
new project or explore whether it would fit into one of OpenStack
deployment projects, like Fuel.

I’m going to have a conversation with Kolla and Fuel teams during the
summit and will keep the community posted on the progress.

[1] https://youtu.be/lUZuzrvlZrg

P.S. Kudos to Sergey Reshetnyak and other folks for helping me preparing
demo.

-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [i18n][horizon][sahara][trove][magnum][murano] dashboard plugin release schedule

2016-03-21 Thread Sergey Lukjanov
It sounds good for Sahara as well.

We already have RC1 in sahara, so, if there will be any translations after
- we'll include them into RC2.

Thanks for you efforts.

On Mon, Mar 21, 2016 at 9:05 AM, Hayes, Graham <graham.ha...@hpe.com> wrote:

> On 19/03/2016 17:47, Akihiro Motoki wrote:
> > Hi dashboard plugins team
> > (sahara-dashboard, trove-dashboard, magnum-ui, murano-dashboard)
> >
>
> There is also a designate-dashboard plugin - we have translation set up
> for Mitaka.
>
> We have string frozen as of RC1 - so if there is translations before
> RC2 we can release them as part of RC2
>
> - Graham
>
> > As Horizon i18n liaison, I would like to have a consensus on a rough
> schedule
> > of translation import for Horizon plugins.
> > Several plugins and horizon itself already released RC1.
> >
> > For Horizon translation, we use the following milestone:
> >Mitaka-3 : Soft string freeze
> >Mitaka-RC1: Hard string freeze
> >Mitaka-RC2: Final translation import
> >
> > Does this milestone sound good for sahara/trove/magnum/murano dashboard
> plugins?
> > This means that each dashboard plugin project needs to release RC2 (or
> some RC)
> > even only for translation import. Otherwise, translator efforts after
> > hard string freeze
> > will not be included in Mitaka release.
> >
> > If the above idea sounds good, I hope RC2 (or later RC) will be released
> > on early of the week Mar 28 for translation import.
> > This schedule allows translators to work on translations after "Hard
> > string freeze".
> >
> > Mitaka is the first release for Horizon plugins with translations,
> > so I hope this mail helps everyone around translations.
> >
> > Best Regards,
> > Akihiro
> >
> >
> __
> > 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
>



-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [release] Release countdown for week R-2, Mar 21-25

2016-03-19 Thread Sergey Lukjanov
Sahara Mitaka RC1 - https://review.openstack.org/294295

Regarding sahara-tests, I expect we'll have a final release for Mitaka as
well.

On Thu, Mar 17, 2016 at 12:23 PM, Doug Hellmann <d...@doughellmann.com>
wrote:

> We're almost to the finish line with Mitaka!
>
> Focus
> -
>
> Project teams following the cycle-with-milestone model should be
> testing their release candidates and fixing release-critical bugs.
>
> Project teams following the cycle-with-intermediary model should
> ensure they have at least one Mitaka release, and determine whether
> they will need another release before the end of the Mitaka cycle.
>
> All feature ongoing work should be retargeted to the Newton cycle.
>
> All project teams should be working on release-critical bugs.
>
> General Notes
> -
>
> The global requirements list is frozen. If you need to change a
> dependency, for example to include a bug fix in one of our libraries
> or an upstream library, please provide enough detail in the change
> request to allow the requirements review team to evaluate the change.
>
> User-facing strings are frozen to allow the translation team time
> to finish their work.
>
> Release Actions
> ---
>
> We still have quite a few managed cycle-with-milestones projects
> without a release candidate:
>
> aodh
> ceilometer
> barbican
> designate
> horizon
> manila
> sahara
> trove
> zaqar
>
> And there are a few managed cycle-with-intermediary projects without
> a clear indication if they have cut their final release:
>
> ironic
> ironic-python-agent
> python-manilaclient
> sahara-tests
> swift
>
> Please contact the release team, or submit a release request to the
> releases repository, to address these missing releases.
>
> Important Dates
> ---
>
> Final release candidates: R-1, Mar 28-1
> Mitaka final release: Apr 7
>
> Mitaka release schedule:
> http://releases.openstack.org/mitaka/schedule.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
>



-- 
Sincerely yours,
Sergey Lukjanov
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-dev] [sahara] Sahara Newton Summit

2016-03-19 Thread Sergey Lukjanov
Hey folks,

let's start collecting topics for the summit discussions.

https://etherpad.openstack.org/p/sahara-newton-summit

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [sahara]FFE Request for resume EDP job

2016-03-16 Thread Sergey Lukjanov
It wasn't get enough reviews, so, FFE rejected.

On Thu, Mar 10, 2016 at 2:09 PM, Sergey Lukjanov <slukja...@mirantis.com>
wrote:

> Yup,
>
> I'm expecting all FFEs to be merged by the EOW, otherwise we'll be
> revisiting case by case with reject by default.
>
> On Thu, Mar 10, 2016 at 1:38 PM, Doug Hellmann <d...@doughellmann.com>
> wrote:
>
>> Excerpts from lu jander's message of 2016-03-07 14:28:21 +0800:
>> > Hi folks,
>> >
>> > I would like to request a FFE for the feature “Resume EDP job”:
>> >
>> >
>> >
>> > BP:
>> >
>> https://blueprints.launchpad.net/sahara/+spec/add-suspend-resume-ability-for-edp-jobs
>> > <https://blueprints.launchpad.net/sahara/+spec/improving-anti-affinity>
>> >
>> >
>> > <https://blueprints.launchpad.net/sahara/+spec/improving-anti-affinity>
>> >
>> > Spec has been merged. https://review.openstack.org/#/c/198264/
>> >
>> >
>> > Suspend EDP patch has been merged.
>> > https://review.openstack.org/#/c/201448/
>> > <https://review.openstack.org/#/c/201448/>
>> >
>> >
>> > <https://review.openstack.org/#/c/210839/>
>> >
>> > Code Review: https://review.openstack.org/#/c/285839/
>> > <https://review.openstack.org/#/c/218638/>
>> >
>> >
>> >
>> > code is ready for review.
>> >
>> >
>> >
>> > The Benefits for this change: after suspend job, we can resume this job.
>> >
>> >
>> >
>> > The Risk: The risk would be low for this patch, since the code of
>> suspend
>> > patch has been long time reviewed.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > luhuichun
>>
>> Both https://review.openstack.org/#/c/285839/ and
>> https://review.openstack.org/#/c/218638/ have -1 votes on them. We will
>> be tagging RC1 next week, so if the team wants to include this feature
>> you should work on getting the patches into shape tomorrow to give you
>> time to test them before the release candidate is tagged.
>>
>> Doug
>>
>> __
>> 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
>>
>
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Principal Software Engineer
> Mirantis Inc.
>



-- 
Sincerely yours,
Sergey Lukjanov
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-dev] [sahara] PTL non-candidacy

2016-03-15 Thread Sergey Lukjanov
Hi folks,

the PTL self-nomination period is opened and I want to note that I won’t be
running again as the Data Processing PTL. I’ve been the Sahara PTL from the
beginning of the project (oh, already more then 3 years) and I’m very proud
of the things we’ve achieved over this time. The project community grown
from a few people working not always in open source way to the successfully
incubated and then integrated OpenStack project.

The main reason I’m stepping down is that I have another inter-company
priorities and don’t have enough time to continue being the good PTL.
Another reason - I've started thinking that it’s a healthy flow to change
PTLs each cycle and I’m going to propose this approach on the upcoming
summit for Sahara community.

I’m not planning to fully leave project, I’d like to keep reviewing
(especially specs) and helping with release management, so, I’ll be around
and will help the next PTLs make a transitions where it’ll be needed.

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [sahara]FFE Request for resume EDP job

2016-03-10 Thread Sergey Lukjanov
Yup,

I'm expecting all FFEs to be merged by the EOW, otherwise we'll be
revisiting case by case with reject by default.

On Thu, Mar 10, 2016 at 1:38 PM, Doug Hellmann <d...@doughellmann.com>
wrote:

> Excerpts from lu jander's message of 2016-03-07 14:28:21 +0800:
> > Hi folks,
> >
> > I would like to request a FFE for the feature “Resume EDP job”:
> >
> >
> >
> > BP:
> >
> https://blueprints.launchpad.net/sahara/+spec/add-suspend-resume-ability-for-edp-jobs
> > <https://blueprints.launchpad.net/sahara/+spec/improving-anti-affinity>
> >
> >
> > <https://blueprints.launchpad.net/sahara/+spec/improving-anti-affinity>
> >
> > Spec has been merged. https://review.openstack.org/#/c/198264/
> >
> >
> > Suspend EDP patch has been merged.
> > https://review.openstack.org/#/c/201448/
> > <https://review.openstack.org/#/c/201448/>
> >
> >
> > <https://review.openstack.org/#/c/210839/>
> >
> > Code Review: https://review.openstack.org/#/c/285839/
> > <https://review.openstack.org/#/c/218638/>
> >
> >
> >
> > code is ready for review.
> >
> >
> >
> > The Benefits for this change: after suspend job, we can resume this job.
> >
> >
> >
> > The Risk: The risk would be low for this patch, since the code of suspend
> > patch has been long time reviewed.
> >
> >
> >
> > Thanks,
> >
> > luhuichun
>
> Both https://review.openstack.org/#/c/285839/ and
> https://review.openstack.org/#/c/218638/ have -1 votes on them. We will
> be tagging RC1 next week, so if the team wants to include this feature
> you should work on getting the patches into shape tomorrow to give you
> time to test them before the release candidate is tagged.
>
> Doug
>
> __
> 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
>



-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [sahara] Feature Freeze Exception Request for blueprint

2016-03-10 Thread Sergey Lukjanov
Hi,

I agree with Doug,

if we'll be able to have green CI and no -1's it's ok to be merged, so FFE
granted.

On Thu, Mar 10, 2016 at 1:35 PM, Doug Hellmann <d...@doughellmann.com>
wrote:

> Excerpts from Grigoriy Roghkov's message of 2016-03-10 15:56:23 +0200:
> > Hi,
> >
> > Untill release of MapR 5.1.0 I couldn't have it added to sahara.
> > The release happened this day and 5.1.0 still can be add in Mitaka
> release.
> >
> > There are two patches to be merged:
> > https://review.openstack.org/#/c/286738/
> > https://review.openstack.org/#/c/286756/
> >
> > I want to request an FFE for these patches.
> >
> > Regards,
> > Grigoriy
>
> It looks like at least one of these patches is failing (the other
> is less clear, but I see a -1 there, too).  We will be tagging
> initial release candidates next week, so I suggest postponing the
> change if the jobs aren't passing by the end of the day Friday, to
> give you time to test them before prepping the release.
>
> Doug
>
> __
> 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
>



-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

2016-03-09 Thread Sergey Lukjanov
Hi,

from Sahara team side, we're okay with python-saharaclient 0.13.0, no fixes
expected.

Thanks.

On Wed, Mar 9, 2016 at 9:26 AM, Doug Hellmann <d...@doughellmann.com> wrote:

> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.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
>



-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [sahara]FFE Request for resume EDP job

2016-03-07 Thread Sergey Lukjanov
FFE granted. This feature seems to be low risk and part of already merged
feature.

Thanks.

On Mon, Mar 7, 2016 at 9:34 AM, Chad Roberts <crobe...@redhat.com> wrote:

> +1 to Trevor's $0.02.  Seems like low risk to break any existing
> functionality and it's a good feature that really makes sense.
>
> On Mon, Mar 7, 2016 at 9:42 AM, Trevor McKay <tmc...@redhat.com> wrote:
>
>> My 2 cents, I agree that it is low risk -- the impl for resume is
>> analogous/parallel to the impl for suspend. And, it makes little
>> sense to me to include suspend without resume.
>>
>> In my mind, these two operations are halves of the same feature,
>> and since it is already partially implemented and approved, I the
>> FFE should be granted.
>>
>> Best,
>>
>> Trev
>>
>> On Mon, 2016-03-07 at 09:07 -0500, Trevor McKay wrote:
>> > For some reason the link below is wrong for me, it goes to a different
>> > review. Here is a good one (I hope!):
>> >
>> > https://review.openstack.org/#/c/285839/
>> >
>> > Trev
>> >
>> > On Mon, 2016-03-07 at 14:28 +0800, lu jander wrote:
>> > > Hi folks,
>> > >
>> > > I would like to request a FFE for the feature “Resume EDP job”:
>> > >
>> > >
>> > >
>> > > BP:
>> > >
>> https://blueprints.launchpad.net/sahara/+spec/add-suspend-resume-ability-for-edp-jobs
>> > >
>> > >
>> > > Spec has been merged. https://review.openstack.org/#/c/198264/
>> > >
>> > >
>> > > Suspend EDP patch has been merged.
>> > >  https://review.openstack.org/#/c/201448/
>> > >
>> > >
>> > > Code Review: https://review.openstack.org/#/c/285839/
>> > >
>> > >
>> > >
>> > > code is ready for review.
>> > >
>> > >
>> > >
>> > > The Benefits for this change: after suspend job, we can resume this
>> > > job.
>> > >
>> > >
>> > >
>> > > The Risk: The risk would be low for this patch, since the code of
>> > > suspend patch has been long time reviewed.
>> > >
>> > >
>> > >
>> > > Thanks,
>> > >
>> > > luhuichun
>> > >
>> > >
>> > >
>> > >
>> __
>> > > 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
>
>


-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [sahara] FFE Request for Improving anti-affinity in Sahara

2016-03-03 Thread Sergey Lukjanov
Hi,

correct spec link is https://review.openstack.org/#/c/269202/

Spec isn't approved and so FFE isn't granted. It's very important to not
spread the team's efforts onto reviewing specs and additional features in
the pre-RC time frame, so, I'm considering non-merged spec as a blocker for
FFE.

Thanks.

On Thu, Mar 3, 2016 at 11:08 AM, Akanksha Agrawal <akanksha@gmail.com>
wrote:

> Hi folks,
>
> I would like to request a FFE for the feature “Improving anti-affinity in
> Sahara”:
>
>
> BP: https://blueprints.launchpad.net/sahara/+spec/improving-anti-affinity
>
>
> <https://blueprints.launchpad.net/sahara/+spec/improving-anti-affinity>
>
> Specification Review: https://review.openstack.org/#/c/269202/
> <https://review.openstack.org/#/c/210839/>
>
>
> <https://review.openstack.org/#/c/210839/>
>
> Code Review: https://review.openstack.org/#/c/282506/
> <https://review.openstack.org/#/c/218638/>
>
>
> Estimated Completion Time: The specification is complete and should not
> take more than 1-2 days to be approved.
>
> The code is under review and needs few more changes before it could be
> completed. Mostly pep8 related errors have to be fixed and the error for
> backward compatibility has to be thrown. This would not require more than a
> week.
>
>
> The Benefits for this change: Improved anti-affinity behaviour while
> cluster creation
>
>
> The Risk: The risk would be low for this patch, since the code would be
> completed in time.
>
>
>
> Thanks,
>
> Akanksha Agrawal
>



-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [sahara]FFE Request for nfs-as-a-data-source

2016-03-02 Thread Sergey Lukjanov
Hi,

FFE not approved.

tl;dr

Spec for this feature isn't yet approved, so, I couldn't grant FFE for it,
because it'll take much more time to get spec aligned and then code with it
and merged code finally. Regarding the support in all plugins - I more or
less agree with Vitaly that we it's bad to have support for the Data
Sources only in a single plugin, we can start with it in the beginning of
cycle, but I prefer to not go with a new limited to concrete plugin version
feature in release.

Thanks.

On Wed, Mar 2, 2016 at 8:46 AM, Chen, Weiting <weiting.c...@intel.com>
wrote:

> Hi,
>
>
>
> Currently, there is no plan for other plugin support in this feature.
>
> We would like to put this feature on the table at first and see if it can
> bring more customers who are interested in Big Data on Cloud and expecting
> to integrate Hadoop with different storage type support.
>
> However, it’s just a beginning and should be worth a shot to bring it in
> Mitaka. And to support any other plugin is also still open and on-demand in
> the future.
>
>
>
> *From:* Vitaly Gridnev [mailto:vgrid...@mirantis.com]
> *Sent:* Wednesday, March 2, 2016 3:31 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [sahara]FFE Request for
> nfs-as-a-data-source
>
>
>
> Hi,
>
>
>
> From my point of view, if we adding new type of the datasources (or
> configurations for that), it means that it should be supported in almost
> all plugins (at least in vanilla, spark, ambari, cdh I guess). Current
>  implementation is nice, but it looks like it touches only vanilla 2.7.1
> plugin which strange for me. Are there plans to add support for other
> plugins? If yes, then I think this feature should be done in Newton cycle
> to have complete picture of this support. If no, I think it's ok to land
> this code in RC with other improvements in validation.
>
>
>
> At conclusion I would like to say that from point of view we should
> collaborate actively to implement this support in early Newton-1 cycle,
> that would be a best choice.
>
>
>
> Thanks.
>
>
>
> On Wed, Mar 2, 2016 at 4:23 AM, Chen, Weiting <weiting.c...@intel.com>
> wrote:
>
> Hi all,
>
>
>
> I would like to request a FFE for the feature “nfs-as-a-data-source”:
>
> BP: https://blueprints.launchpad.net/sahara/+spec/nfs-as-a-data-source
>
> BP Review: https://review.openstack.org/#/c/210839/
>
> Sahara Code: https://review.openstack.org/#/c/218638/
>
> Sahara Image Elements Code: https://review.openstack.org/#/c/218637/
>
>
>
> Estimate Complete Time: The BP has been complete and the implementation
> has been complete as well. All the code is under code reviewing and since
> there is no big change or modify for the code we expect it can only take
> one weeks to be merged.
>
> The Benefits for this change: Provide NFS support in Sahara.
>
> The Risk: The risk would be low for this patch, since all the functions
> have been delivered.
>
>
>
> Thanks,
>
> Weiting(William) Chen
>
>
>
>
> __
> 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
>
>


-- 
Sincerely yours,
Sergey Lukjanov
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-dev] [sahara] Final client release for Mitaka

2016-02-24 Thread Sergey Lukjanov
Hi sahara folks,

if you have any idea on what should be merged into python-saharaclient
before the final client release for Mitaka, please, raise you hand till
EOW, we're planning to discuss it tomorrow on IRC meeting and try to
release client on Friday.

https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Agenda

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
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


Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Sergey Lukjanov
Hi,

IMO if you want to do the stylistic changes - make the hacking rule for it
first. Not all of this particular changes are useful and even correct. The
explicit comparison with zero in Python where we have number of implicit
casts to bool is much better in such cases.

Thanks.

On Tue, Jan 12, 2016 at 5:02 PM, Chris Dent <cdent...@anticdent.org> wrote:

> On Tue, 12 Jan 2016, Amrith Kumar wrote:
>
> if var > 0:
>> ... something ...
>>
>> To
>>
>> if var:
>> ... something ...
>>
>
> I may be missing something but the above is not a stylistic change
> if var can ever be negative. In one of the ceilometer changes[1] for
> example, this change will change the flow of the code. In this
> particular example if some caller do _do_test_iter_images sends
> page_size=-1 bad things will happen. Since it is test code the scope
> of the damage is limited, but I prefer the more explicit > 0.
>
> I've not checked all the reviews but if it is showing up in one
> place seems like it could in others.
>
> [1]
> https://review.openstack.org/#/c/266211/1/ceilometer/tests/unit/image/test_glance.py
>
> --
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> 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
>
>


-- 
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-dev] [sahara] no IRC meeting Dec 31 and Jan 7

2015-12-24 Thread Sergey Lukjanov
Hi folks,

due to the NY holidays there will be no IRC meeting Dec 31 and Jan 7.

Thanks.

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


Re: [openstack-dev] [sahara] no IRC meeting Dec 31 and Jan 7

2015-12-24 Thread Sergey Lukjanov
And no meeting today - Dec 24.

On Thu, Dec 24, 2015 at 8:45 PM, Sergey Lukjanov <slukja...@mirantis.com>
wrote:

> Hi folks,
>
> due to the NY holidays there will be no IRC meeting Dec 31 and Jan 7.
>
> Thanks.
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
>



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


Re: [openstack-dev] [Sahara] Instance customization for Bootstrapping the cluster nodes

2015-12-02 Thread Sergey Lukjanov
Hi,

we don't have such feature right now. It could be implemented by adding
support for defining user data on the templates level. We already passing
some user data to the VMs, so, it'll be really easy to implement it in
Sahara.

You can submit spec or blueprint for it.

Thanks.

On Wed, Nov 25, 2015 at 11:13 PM, Ashish Billore <ashish.bill...@gmail.com>
wrote:

> Hello Everyone,
>
> I am looking for a way to customize my Cluster nodes at cluster creation
> time. This is something like: AWS EMR BootStrap Action:
> http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-plan-bootstrap.html
>
> While creating an instance through nova boot command / UI, there is an
> option to pass user-data through with cloud-init or cloud-config scripts,
> that can customize the instance at creation time based on specific
> environment or user need. Is there a similar way to pass cloud-init /
> cloud-config scripts while creating cluster using Sahara?
>
> Please Note: I do not prefer to bake these customization in the Sahara
> image itself, I need to do these at the Cluster creation time, dynamically.
>
> Thanks for the help.
>
> --
> Thanks,
> Ashish
>
> __
> 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
>
>


-- 
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-dev] [sahara] no IRC meeting week after summit (Nov 5)

2015-11-01 Thread Sergey Lukjanov
Hi folks,

There will be no IRC meeting week after summit (November 5).

Thanks


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


Re: [openstack-dev] [fuel] PTL & Component Leads elections

2015-10-23 Thread Sergey Lukjanov
Hi folks,

component lead elections ended as well.

Congrats to Sergii Golovatiuk for becoming official Fuel-library component
lead!

Results: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_93a6886b38223ab3

Thanks.

On Tue, Oct 20, 2015 at 4:48 AM, Mike Scherbakov <mscherba...@mirantis.com>
wrote:

> Congrats Igor!
>
> Sergey - thanks for help.
>
> On Mon, Oct 19, 2015 at 2:48 AM Sergey Lukjanov <slukja...@mirantis.com>
> wrote:
>
>> Hi folks,
>>
>> it's time to start voting for the component leads.
>>
>> There was only one candidate for the Fuel Python Component Lead, so, no
>> need for voting. Congrats to Igor Kalnitsky!
>>
>> For the Fuel Library Component Lead we have two candidates and you should
>> receive an email with title "Poll: Fuel Library Component Lead Elections
>> Fall 2015" soon to vote for them. Please, don't share / forward this email,
>> it contains your personal unique token for the voting.
>>
>> The estimated date for the voting end is Oct 22.
>>
>> Thanks.
>>
>> On Tue, Oct 13, 2015 at 4:05 PM, Tomasz Napierala <
>> tnapier...@mirantis.com> wrote:
>>
>>> Congrats Dmitry! Well deserved.
>>>
>>>
>>> > On 09 Oct 2015, at 19:13, Mike Scherbakov <mscherba...@mirantis.com>
>>> wrote:
>>> >
>>> > Congratulations to Dmitry!
>>> > Now you are officially titled with PTL.
>>> > It won't be easy, but we will support you!
>>> >
>>> > 118 contributors voted. Thanks everyone! Thank you Sergey for
>>> organizing elections for us.
>>> >
>>> > On Thu, Oct 8, 2015 at 3:52 PM Sergey Lukjanov <slukja...@mirantis.com>
>>> wrote:
>>> > Voting period ended and so we have an officially selected Fuel PTL -
>>> DB. Congrats!
>>> >
>>> > Poll results & details -
>>> http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1=E_b79041aa56684ec0
>>> >
>>> > Let's start proposing candidates for the component lead positions!
>>> >
>>> > On Wed, Sep 30, 2015 at 8:47 PM, Sergey Lukjanov <
>>> slukja...@mirantis.com> wrote:
>>> > Hi folks,
>>> >
>>> > I've just setup the voting system and you should start receiving email
>>> with topic "Poll: Fuel PTL Elections Fall 2015".
>>> >
>>> > NOTE: Please, don't forward this email, it contains *personal* unique
>>> token for the voting.
>>> >
>>> > Thanks.
>>> >
>>> > On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin <vkuk...@mirantis.com>
>>> wrote:
>>> > +1 to Igor. Do we have voting system set up?
>>> >
>>> > On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky <
>>> ikalnit...@mirantis.com> wrote:
>>> > > * September 29 - October 8: PTL elections
>>> >
>>> > So, it's in progress. Where I can vote? I didn't receive any emails.
>>> >
>>> > On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala
>>> > <tnapier...@mirantis.com> wrote:
>>> > >> On 18 Sep 2015, at 04:39, Sergey Lukjanov <slukja...@mirantis.com>
>>> wrote:
>>> > >>
>>> > >>
>>> > >> Time line:
>>> > >>
>>> > >> PTL elections
>>> > >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL
>>> position
>>> > >> * September 29 - October 8: PTL elections
>>> > >
>>> > > Just a reminder that we have a deadline for candidates today.
>>> > >
>>> > > Regards,
>>> > > --
>>> > > Tomasz 'Zen' Napierala
>>> > > Product Engineering - Poland
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> __
>>> > > 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] [fuel] PTL & Component Leads elections

2015-10-19 Thread Sergey Lukjanov
Hi folks,

it's time to start voting for the component leads.

There was only one candidate for the Fuel Python Component Lead, so, no
need for voting. Congrats to Igor Kalnitsky!

For the Fuel Library Component Lead we have two candidates and you should
receive an email with title "Poll: Fuel Library Component Lead Elections
Fall 2015" soon to vote for them. Please, don't share / forward this email,
it contains your personal unique token for the voting.

The estimated date for the voting end is Oct 22.

Thanks.

On Tue, Oct 13, 2015 at 4:05 PM, Tomasz Napierala <tnapier...@mirantis.com>
wrote:

> Congrats Dmitry! Well deserved.
>
>
> > On 09 Oct 2015, at 19:13, Mike Scherbakov <mscherba...@mirantis.com>
> wrote:
> >
> > Congratulations to Dmitry!
> > Now you are officially titled with PTL.
> > It won't be easy, but we will support you!
> >
> > 118 contributors voted. Thanks everyone! Thank you Sergey for organizing
> elections for us.
> >
> > On Thu, Oct 8, 2015 at 3:52 PM Sergey Lukjanov <slukja...@mirantis.com>
> wrote:
> > Voting period ended and so we have an officially selected Fuel PTL - DB.
> Congrats!
> >
> > Poll results & details -
> http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1=E_b79041aa56684ec0
> >
> > Let's start proposing candidates for the component lead positions!
> >
> > On Wed, Sep 30, 2015 at 8:47 PM, Sergey Lukjanov <slukja...@mirantis.com>
> wrote:
> > Hi folks,
> >
> > I've just setup the voting system and you should start receiving email
> with topic "Poll: Fuel PTL Elections Fall 2015".
> >
> > NOTE: Please, don't forward this email, it contains *personal* unique
> token for the voting.
> >
> > Thanks.
> >
> > On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin <vkuk...@mirantis.com>
> wrote:
> > +1 to Igor. Do we have voting system set up?
> >
> > On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
> > > * September 29 - October 8: PTL elections
> >
> > So, it's in progress. Where I can vote? I didn't receive any emails.
> >
> > On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala
> > <tnapier...@mirantis.com> wrote:
> > >> On 18 Sep 2015, at 04:39, Sergey Lukjanov <slukja...@mirantis.com>
> wrote:
> > >>
> > >>
> > >> Time line:
> > >>
> > >> PTL elections
> > >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL
> position
> > >> * September 29 - October 8: PTL elections
> > >
> > > Just a reminder that we have a deadline for candidates today.
> > >
> > > Regards,
> > > --
> > > Tomasz 'Zen' Napierala
> > > Product Engineering - Poland
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> __
> > > 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
> >
> >
> >
> > --
> > Yours Faithfully,
> > Vladimir Kuklin,
> > Fuel Library Tech Lead,
> > Mirantis, Inc.
> > +7 (495) 640-49-04
> > +7 (926) 702-39-68
> > Skype kuklinvv
> > 35bk3, Vorontsovskaya Str.
> > Moscow, Russia,
> > www.mirantis.com
> > www.mirantis.ru
> > vkuk...@mirantis.com
> >
> >
> __
> > 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
> >
> >
> >
> >
> > --
> > Sincerely yours,
> > Sergey Lukjanov
> > Sahara Technical Lead
> > (OpenStack Data Processing)
> > Principal Software Engineer
> > Mirantis Inc.
> >
> >
> >
> > --
> > Sincerely yours,
> > Sergey Lukjanov
> > Sahara Technical Lead
> > (OpenStack Data Processing)
> > Principal

[openstack-dev] [sahara] Design summit schedule posted

2015-10-16 Thread Sergey Lukjanov
Hi folks,

you could find the schedule for Sahara part of design summit at
http://mitakadesignsummit.sched.org/overview/type/sahara

All etherpads -
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Sahara

Session chairs, please, fill the etherpads.

Thanks.

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


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

2015-10-15 Thread Sergey Lukjanov
I think we have a quorum.

Vitaly, congrats!

On Tue, Oct 13, 2015 at 6:39 PM, Matthew Farrellee <m...@redhat.com> wrote:

> +1!
>
> 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
>



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


Re: [openstack-dev] [release] establishing release liaisons for mitaka

2015-10-15 Thread Sergey Lukjanov
Doug, just to confirm - for Sahara I'll continue being release liaison.

On Thu, Oct 15, 2015 at 3:40 AM, Lana Brindley <openst...@lanabrindley.com>
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 15/10/15 01:25, Doug Hellmann wrote:
> > As with the other cross-project teams, the release management team
> > relies on liaisons from each project to be available for coordination of
> > work across all teams. It's the start of a new cycle, so it's time to
> > find those liaison volunteers.
> >
> > We are working on updating the release documentation as part of the
> > Project Team Guide. Release liaison responsibilities are documented in
> > [0], and we will update that page with more details over time.
> >
> > In the past we have defaulted to having the PTL act as liaison if no
> > alternate is specified, and we will continue to do that during Mitaka.
> > If you plan to delegate release work to a liaison, especially for
> > submitting release requests, please update the wiki [1] to provide their
> > contact information. If you plan to serve as your team's liaison, please
> > add your contact details to the page.
>
> While PTLs are considering this important role, (and editing the
> cross-project liaison wiki page!), please consider who you would like to be
> your documentation liaison as well[1]. The docs team relies on the docs
> CPLs to provide technical depth on the things we write, so having a subject
> matter expert means we are going to be providing better documentation for
> your project.
>
> Thanks,
> Lana
>
> 1: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation
>
>
> - --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCAAGBQJWHvYAAAoJELppzVb4+KUy9ysH/i/sksBb128N7uBfhOpHukDM
> 2Z1e8Dmx1rS5F2x4k4QIBqMPIpgAhtyryjCWTwi5rz/62bVG1rT/ArTJiqV+nQT0
> iLXBVVI++iZL5eAkaR3/VVyeOUUXoRIe/t+5MMrTZaVOB1nM1UkNLAWcoS6xaATf
> Y96dcv7EAhyw2Mmd8TlLL3/VBTZ4DYO1aQaQbAupGlNdkzOeHnLwU4kdH0T3ajKc
> ooSi5PYTY8blFTw/F1LfbPM8HkaCvV81YU8eSfRtLQeNg9WjgE5cMTXn7HIupKgA
> YmKCaQfE2rGGZpGF7d16C5A8UbGdKLnsZ6XjtjcVVbxB5diAMFSk3xMgjDfVdXM=
> =EZFY
> -END PGP SIGNATURE-
>
> __
> 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
>



-- 
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-dev] [sahara] Proposing Vitaly Gridnev to core reviewer team

2015-10-12 Thread Sergey Lukjanov
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


Re: [openstack-dev] [fuel] PTL & Component Leads elections

2015-10-08 Thread Sergey Lukjanov
Voting period ended and so we have an officially selected Fuel PTL - DB.
Congrats!

Poll results & details -
http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1=E_b79041aa56684ec0

Let's start proposing candidates for the component lead positions!

On Wed, Sep 30, 2015 at 8:47 PM, Sergey Lukjanov <slukja...@mirantis.com>
wrote:

> Hi folks,
>
> I've just setup the voting system and you should start receiving email
> with topic "Poll: Fuel PTL Elections Fall 2015".
>
> NOTE: Please, don't forward this email, it contains *personal* unique
> token for the voting.
>
> Thanks.
>
> On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin <vkuk...@mirantis.com>
> wrote:
>
>> +1 to Igor. Do we have voting system set up?
>>
>> On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
>> wrote:
>>
>>> > * September 29 - October 8: PTL elections
>>>
>>> So, it's in progress. Where I can vote? I didn't receive any emails.
>>>
>>> On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala
>>> <tnapier...@mirantis.com> wrote:
>>> >> On 18 Sep 2015, at 04:39, Sergey Lukjanov <slukja...@mirantis.com>
>>> wrote:
>>> >>
>>> >>
>>> >> Time line:
>>> >>
>>> >> PTL elections
>>> >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL
>>> position
>>> >> * September 29 - October 8: PTL elections
>>> >
>>> > Just a reminder that we have a deadline for candidates today.
>>> >
>>> > Regards,
>>> > --
>>> > Tomasz 'Zen' Napierala
>>> > Product Engineering - Poland
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> __
>>> > 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
>>>
>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com <http://www.mirantis.ru/>
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> __
>> 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
>>
>>
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
>



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


Re: [openstack-dev] [fuel] PTL & Component Leads elections

2015-09-30 Thread Sergey Lukjanov
Hi folks,

I've just setup the voting system and you should start receiving email with
topic "Poll: Fuel PTL Elections Fall 2015".

NOTE: Please, don't forward this email, it contains *personal* unique token
for the voting.

Thanks.

On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:

> +1 to Igor. Do we have voting system set up?
>
> On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>
>> > * September 29 - October 8: PTL elections
>>
>> So, it's in progress. Where I can vote? I didn't receive any emails.
>>
>> On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala
>> <tnapier...@mirantis.com> wrote:
>> >> On 18 Sep 2015, at 04:39, Sergey Lukjanov <slukja...@mirantis.com>
>> wrote:
>> >>
>> >>
>> >> Time line:
>> >>
>> >> PTL elections
>> >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL
>> position
>> >> * September 29 - October 8: PTL elections
>> >
>> > Just a reminder that we have a deadline for candidates today.
>> >
>> > Regards,
>> > --
>> > Tomasz 'Zen' Napierala
>> > Product Engineering - Poland
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> __
>> > 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
>>
>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> 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
>
>


-- 
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-dev] [fuel] PTL & Component Leads elections

2015-09-17 Thread Sergey Lukjanov
Hi folks,

I'd like to announce that we're running the PTL and Component Leads
elections. Detailed information available on wiki. [0]

Project Team Lead: Manages day-to-day operations, drives the project
team goals, resolves technical disputes within the project team. [1]

Component Lead: Defines architecture of a module or component in Fuel,
reviews design specs, merges majority of commits and resolves conflicts
between Maintainers or contributors in the area of responsibility. [2]

Fuel has two large sub-teams, with roughly comparable codebases, that
need dedicated component leads: fuel-library and fuel-python. [2]

Nominees propose their candidacy by sending an email to the
openstack-dev@lists.openstack.org mailing-list, which the subject:
"[fuel] PTL candidacy" or "[fuel]  lead candidacy"
(for example, "[fuel] fuel-library lead candidacy").

Time line:

PTL elections
* September 18 - September 28, 21:59 UTC: Open candidacy for PTL position
* September 29 - October 8: PTL elections

Component leads elections (fuel-library and fuel-python)
* October 9 - October 15: Open candidacy for Component leads positions
* October 16 - October 22: Component leads elections

[0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015
[1] https://wiki.openstack.org/wiki/Governance
[2]
http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
[3] https://lwn.net/Articles/648610/

-- 
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-dev] [sahara] PTL candidacy

2015-09-16 Thread Sergey Lukjanov
Hi,

I'd like to announce my intention to continue being PTL of the Data
Processing program (Sahara).

I’m working on Sahara (ex. Savanna) project from scratch, from the
initial proof of concept implementation and till now. I have been the
acting/elected PTL since Sahara was an idea. Additionally, I’m
contributing to other OpenStack projects, especially Infrastructure
for the last four releases where I’m core/root teams member now.

My high-level focus as PTL is to coordinate work of subteams, code
review, release management and general architecture/design tracking.

During the Liberty cycle we successfully continued using the specs system.
There were many new contributors during the cycle and we've renewed a lot
the core reviewer team as well. Tons of operability and supportability
improvements were done as well as number of interesting features.

For Mitaka cycle my focus is to keep going in the same direction and
to ensure that everything we're working on is related to the end users
needs. So, in a few words it's about continuing moving forward in
implementing scalable and flexible Data Processing aaS for OpenStack
ecosystem by investing in quality, usability and new features. I'd like
to highlight the following areas that I think very important for Sahara
project in the Mitaka cycle: security of Sahara and Hadoop as well,
scalability (first of all of Sahara itself) and EDP enhancements.

A few words about myself: I’m Principle Software Engineer in Mirantis.
I was working a lot with  Big Data projects and technologies (Hadoop,
HDFS, Cassandra, Twitter Storm, etc.) and enterprise-grade solutions
before (and partially in parallel) working on Sahara in OpenStack ecosystem.

Thanks.

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


Re: [openstack-dev] [all][ptl][release] final liberty cycle client library releases needed

2015-09-15 Thread Sergey Lukjanov
We're in a good shape with sahara client. 0.11.0 is the final minor release
for it. Constraints are up to date.

On Tue, Sep 15, 2015 at 5:45 PM, Doug Hellmann <d...@doughellmann.com>
wrote:

> Excerpts from Dmitry Tantsur's message of 2015-09-15 16:16:00 +0200:
> > On 09/14/2015 04:18 PM, Doug Hellmann wrote:
> > > Excerpts from Doug Hellmann's message of 2015-09-14 08:46:02 -0400:
> > >> PTLs and release liaisons,
> > >>
> > >> In order to keep the rest of our schedule for the end-of-cycle release
> > >> tasks, we need to have final releases for all client libraries in the
> > >> next day or two.
> > >>
> > >> If you have not already submitted your final release request for this
> > >> cycle, please do that as soon as possible.
> > >>
> > >> If you *have* already submitted your final release request for this
> > >> cycle, please reply to this email and let me know that you have so I
> can
> > >> create your stable/liberty branch.
> > >>
> > >> Thanks!
> > >> Doug
> > >
> > > I forgot to mention that we also need the constraints file in
> > > global-requirements updated for all of the releases, so we're actually
> > > testing with them in the gate. Please take a minute to check the
> version
> > > specified in openstack/requirements/upper-constraints.txt for your
> > > libraries and submit a patch to update it to the latest release if
> > > necessary. I'll do a review later in the week, too, but it's easier to
> > > identify the causes of test failures if we have one patch at a time.
> >
> > Hi Doug!
> >
> > When is the last and final deadline for doing all this for
> > not-so-important and non-release:managed projects like ironic-inspector?
> > We still lack some Liberty features covered in
> > python-ironic-inspector-client. Do we have time until end of week to
> > finish them?
>
> We would like for the schedule to be the same for everyone. We need the
> final versions for all libraries this week, so we can update
> requirements constraints by early next week before the RC1.
>
> https://wiki.openstack.org/wiki/Liberty_Release_Schedule
>
> Doug
>
> >
> > Sorry if you hear this question too often :)
> >
> > Thanks!
> >
> > >
> > > Doug
> > >
> > >
> __
> > > 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
>



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


Re: [openstack-dev] [sahara] FFE request for scheduler and suspend EDP job for sahara

2015-09-14 Thread Sergey Lukjanov
Hi,

Not approved.

Unfortunately it seems like dangerous patch, API changing and Liberty
client will not support it as well. Let's have it merged early in M cycle
(after Liberty RC published, master will be open for M).

Thanks.

On Fri, Sep 11, 2015 at 12:06 AM, Ethan Gafford <egaff...@redhat.com> wrote:

> 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" <juvenboy1...@gmail.com>
> >To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> >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 <vgrid...@mirantis.com>:
> >
> >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 <juvenboy1...@gmail.com>
> 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
>
>


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


Re: [openstack-dev] [sahara] mitaka summit session ideas

2015-09-14 Thread Sergey Lukjanov
Thank you for starting it ;)

On Fri, Sep 11, 2015 at 12:28 AM, michael mccune <m...@redhat.com> wrote:

> hey all,
>
> i started an etherpad for us to collect ideas about our session for the
> mitaka summit.
>
> https://etherpad.openstack.org/p/mitaka-sahara-session-plans
>
> please drop any thoughts or suggestions about the summit there.
>
> thanks,
> 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
>



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


Re: [openstack-dev] [sahara] FFE request for heat wait condition support

2015-09-14 Thread Sergey Lukjanov
Approved.

https://etherpad.openstack.org/p/sahara-liberty-ffes updated

On Thu, Sep 10, 2015 at 11:52 PM, Ethan Gafford <egaff...@redhat.com> wrote:

> Seems reasonable; +1.
>
> -Ethan
>
> >- Original Message -
> >From: "michael mccune" <m...@redhat.com>
> >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
> >> <sreshetn...@mirantis.com <mailto:sreshetn...@mirantis.com>> 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://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
>



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


Re: [openstack-dev] [sahara] FFE request for nfs-as-a-data-source

2015-09-14 Thread Sergey Lukjanov
Hi,

Not approved.

Unfortunately spec wasn't approved in time, so, it's too late for FFEs.
Patches seems not ready too and has unresolved comments for some time.

Thanks.

On Fri, Sep 11, 2015 at 12:15 AM, Ethan Gafford <egaff...@redhat.com> wrote:

> 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" <m...@redhat.com>
> >To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> >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" <m...@redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> 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
>



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


Re: [openstack-dev] [sahara] Request for Feature Freeze Exception

2015-09-14 Thread Sergey Lukjanov
Approved.

https://etherpad.openstack.org/p/sahara-liberty-ffes updated

On Fri, Sep 4, 2015 at 12:40 PM, Sergey Reshetnyak <sreshetn...@mirantis.com
> wrote:

> +1 from me.
>
> Thanks,
> Sergey R.
>
> 2015-09-03 23:27 GMT+03:00 Ethan Gafford <egaff...@redhat.com>:
>
>> Agreed. We've talked about this for a while, and it's very low risk.
>>
>> Thanks,
>> Ethan
>>
>> - Original Message -
>> From: "michael mccune" <m...@redhat.com>
>> 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
>>
>
>
> __
> 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
>
>


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


Re: [openstack-dev] [sahara] FFE for Ambari plugin

2015-09-14 Thread Sergey Lukjanov
Approved.

This code is scoped into the new Ambari plugin, so, no possible issues with
existing functionality.

https://etherpad.openstack.org/p/sahara-liberty-ffes updated.

On Mon, Sep 14, 2015 at 4:42 PM, Sergey Reshetnyak <sreshetn...@mirantis.com
> wrote:

> Hello
>
> I would like to request FFE for Ambari plugin.
>
> Core parts of Ambari plugin merged, but scaling and HA support on review.
>
> Patches:
> * Scaling: https://review.openstack.org/#/c/193081/
> * HA: https://review.openstack.org/#/c/197551/
>
> Blueprint: https://blueprints.launchpad.net/sahara/+spec/hdp-22-support
>
> Spec:
> https://github.com/openstack/sahara-specs/blob/master/specs/liberty/hdp-22-support.rst
>
> 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
>
>


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


Re: [openstack-dev] [Heat] convergence rally test results (so far)

2015-08-28 Thread Sergey Lukjanov
Hi,

great, it seems like migration to convergence could happen soon.

How many times you were running each test case? Does time changing with
number of iterations? Are you planning to test parallel stacks creation?

Thanks.

On Fri, Aug 28, 2015 at 10:17 AM, Sergey Kraynev skray...@mirantis.com
wrote:

 Angus!

 it's Awesome!  Thank you for the investigation.
 I had a talk with guys from Sahara team and we decided to start testing
 convergence with Sahara after L release.
 I suppose, that Murano can also join to this process.

 Also AFAIK Sahara team plan to create functional tests with Heat-engine.
 We may add it as a non-voting job for our gate.
 Probably it will be good to have two different type of this job: with
 convergence and with default Heat.

 On 28 August 2015 at 04:35, Angus Salkeld asalk...@mirantis.com wrote:

 Hi

 I have been running some rally tests against convergence and our existing
 implementation to compare.

 So far I have done the following:

1. defined a template with a resource group

 https://github.com/asalkeld/convergence-rally/blob/master/templates/resource_group_test_resource.yaml.template
2. the inner resource looks like this:

 https://github.com/asalkeld/convergence-rally/blob/master/templates/server_with_volume.yaml.template
  (it
uses TestResource to attempt to be a reasonable simulation of a
server+volume+floatingip)
3. defined a rally job:

 https://github.com/asalkeld/convergence-rally/blob/master/increasing_resources.yaml
  that
creates X resources then updates to X*2 then deletes.
4. I then ran the above with/without convergence and with 2,4,8
heat-engines

 Here are the results compared:

 https://docs.google.com/spreadsheets/d/12kRtPsmZBl_y78aw684PTBg3op1ftUYsAEqXBtT800A/edit?usp=sharing


 Results look pretty nice (especially for create) :)
 The strange thing for me: why on update 8 engines shows worse results
 then with 4 engines? (may be mistake in graph... ?)





 Some notes on the results so far:

-  convergence with only 2 engines does suffer from RPC overload (it
gets message timeouts on larger templates). I wonder if this is the 
 problem
in our convergence gate...

 Good spotting. If it's true, probably we should try to change  number of
 engines... (not sure, how gate hardware react on it).


- convergence does very well with a reasonable number of engines
running.
- delete is slightly slower on convergence


 Also about delete - may be we may to optimize it later, when convergence
 way get more feedback.


 Still to test:

- the above, but measure memory usage
- many small templates (run concurrently)
- we need to ask projects using Heat to try with convergence (Murano,
TripleO, Magnum, Sahara, etc..)

 Any feedback welcome (suggestions on what else to test).

 -Angus

 __
 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




 Regards,
 Sergey.



 __
 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




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


Re: [openstack-dev] [ceilometer] [rally] [sahara] [heat] [congress] [tripleo] ceilometer in gate jobs

2015-08-27 Thread Sergey Lukjanov
Hi,

I think filing the cross-project bug is ok. I've already uploaded patch for
sahara jobs - https://review.openstack.org/217751

Thanks.

On Wed, Aug 26, 2015 at 6:46 PM, Chris Dent chd...@redhat.com wrote:


 [If any of this is wrong I hope someone from infra or qa will
 correct me. Thanks. This feels a bit cumbersome so perhaps there is
 a way to do it in a more automagic fashion[1].]

 In the near future ceilometer will be removing itself from the core
 of devstack and using a plugin instead. This is to allow more
 independent control and flexibility.

 These are the related reviews:

 * remove from devstack: https://review.openstack.org/196383
 * updated jenkins jobs: https://review.openstack.org/196446

 If a project is using ceilometer in its gate jobs then before the
 above can merge adjustments need to be made to make sure that the
 ceilometer plugin is enabled. The usual change for this would be a
 form of:

   DEVSTACK_LOCAL_CONFIG+=$'\n'enable_plugin ceilometer git://
 git.openstack.org/openstack/ceilometer

 I'm not entirely clear on what we will need to do coordinate this,
 but it is clear some coordination will need to be done such that
 ceilometer remains in devstack until everything that is using
 ceilometer in devstack is ready to use the plugin.

 A grep through the jenkins jobs suggests that the projects in
 $SUBJECT (rally, sahara, heat, congress, tripleo) will need some
 changes.

 How shall we proceed with this?

 One option is for project team members[2] to make a stack of dependent
 patches that are dependent on 196446 above (which itself is dependent
 on 196383) so that it all happens in one fell swoop.

 What are the other options?

 Thanks for your input.

 [1] That is, is it worth considering adding functionality to
 devstack's sense of enabled such that if a service is enabled
 devstack knows how to look for a plugin if it doesn't find local
 support. With the destruction of the stackforge namespace we can
 perhaps guess the git URL for plugins?

 [2] Or me if that's better.

 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent

 __
 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




-- 
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-dev] [sahara] python-saharaclient release 0.11.0 planned for 8/31-9/1

2015-08-26 Thread Sergey Lukjanov
Hi folks,

due to the upcoming soft dependencies the 0.11.0 release of sahara client
is planned to early next week, so, please review not yet merged changes.

If there are any patches you that you think should definitely become part
of this release, please, ping me in IRC / mail.

Thanks.

P.S. it looks like this release will be the official Liberty sahara
client release.

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


Re: [openstack-dev] [sahara] Proposing Ethan Gafford for the core reviewer team

2015-08-20 Thread Sergey Lukjanov
As there no objections, I'm glad to congratulate us with a new core review
team member ;)

Ethan, congratulations!

On Mon, Aug 17, 2015 at 10:48 AM, Flavio Percoco fla...@redhat.com wrote:

 On 16/08/15 19:51 +, Telles Nobrega wrote:

   For what is worth I got that it was just a joke.


 That's great. However, not everyone did and this is a public mailing
 list with lots of newcomers.

 As I mentioned in my email, I know Trevor sent it with good intentions
 but not everyone read it that way (including me).

 I'm happy it was all clarified,
 Flavio

   On Fri, Aug 14, 2015 at 2:30 PM Trevor McKay tmc...@redhat.com wrote:

 Flavio,

 A  thanks, bad joke on my part. I work with Telles on Sahara, just
 poking
 him in jest.A  Apologies, didn't mean to create an issue on the list.

 Trev

 On Fri, 2015-08-14 at 17:30 +0200, Flavio Percoco wrote:
  On 14/08/15 09:29 -0400, Trevor McKay wrote:
  Hi Telles,
  
   you technically don't get a vote, but thanks anyway :)
 
  Hi Trevor,
 
  Technically, everyone gets to vote and speak up. Regardless of
 whether
  you're a core-reviewer or not. Most of the time, non-core
 contributors
  provide amazing feedback on what their experience has been while
  receiving reviews from the nominated person.
 
  Regardless of the comment, we as a community always welcome
  contributor's opinions and encourage folks to speak up.
 
  I knew your intentions are good but I thought it'd be a good time to
  share the above so that it would work as a reminder for others as
  well.
 
  Thank you both and +1 for Ethan ;)
  Flavio
 
  
  Trev
  
  On Fri, 2015-08-14 at 12:14 +, Telles Nobrega wrote:
   +1
  
   On Fri, Aug 14, 2015 at 7:11 AM Alexander Ignatov
   aigna...@mirantis.com wrote:
  
  A  A  A  A  A +1
  
  A  A  A  A  A Regards,
  A  A  A  A  A Alexander Ignatov
  
  
  
  
  
  A  A  A  A  A  On 13 Aug 2015, at 18:29, Sergey Reshetnyak
  A  A  A  A  A  sreshetn...@mirantis.com wrote:
  A  A  A  A  A 
  A  A  A  A  A  +2
  A  A  A  A  A 
  A  A  A  A  A  2015-08-13 18:07 GMT+03:00 Matthew Farrellee
  A  A  A  A  A  m...@redhat.com:
  A  A  A  A  A A  A  A  A  A On 08/13/2015 10:56 AM, Sergey
 Lukjanov
 wrote:
  A  A  A  A  A A  A  A  A  A  A  A  A  A Hi folks,
  A  A  A  A  A 
  A  A  A  A  A A  A  A  A  A  A  A  A  A I'd like to propose Ethan
 Gafford as a
  A  A  A  A  A A  A  A  A  A  A  A  A  A member of the Sahara core
  A  A  A  A  A A  A  A  A  A  A  A  A  A reviewer team.
  A  A  A  A  A 
  A  A  A  A  A A  A  A  A  A  A  A  A  A Ethan contributing to
 Sahara for a long time
  A  A  A  A  A A  A  A  A  A  A  A  A  A and doing a great job on
  A  A  A  A  A A  A  A  A  A  A  A  A  A reviewing and improving
 Sahara. Here are the
  A  A  A  A  A A  A  A  A  A  A  A  A  A statistics for reviews
  A  A  A  A  A A  A  A  A  A  A  A  A  A [0][1][2] and commits
 [3].
 BTW Ethan is
  A  A  A  A  A A  A  A  A  A  A  A  A  A already stable maint team
 core
  A  A  A  A  A A  A  A  A  A  A  A  A  A for Sahara.
  A  A  A  A  A 
  A  A  A  A  A A  A  A  A  A  A  A  A  A Existing Sahara core
 reviewers, please vote
  A  A  A  A  A A  A  A  A  A  A  A  A  A +1/-1 for the addition of
  A  A  A  A  A A  A  A  A  A  A  A  A  A Ethan to the core
 reviewer
 team.
  A  A  A  A  A 
  A  A  A  A  A A  A  A  A  A  A  A  A  A Thanks.
  A  A  A  A  A 
  A  A  A  A  A A  A  A  A  A  A  A  A  A [0]
  A  A  A  A  A A  A  A  A  A  A  A  A A
 https://review.openstack.org/#/q/reviewer:%
  A  A  A  A  A A  A  A  A  A  A  A  A A
 22Ethan+Gafford+%253Cegafford%2540redhat.com
  A  A  A  A  A A  A  A  A  A  A  A  A  A %253E%22,n,z
  A  A  A  A  A A  A  A  A  A  A  A  A  A [1]
  A  A  A  A  A A  A  A  A  A  A  A  A A
 http://stackalytics.com/report/contribution/sahara-group/90
  A  A  A  A  A A  A  A  A  A  A  A  A  A [2]
  A  A  A  A  A A  A  A  A  A  A  A  A A
 http://stackalytics.com/?user_id=egaffordmetric=marks
  A  A  A  A  A A  A  A  A  A  A  A  A  A [3]
  A  A  A  A  A A  A  A  A  A  A  A  A A
 https://review.openstack.org/#/q/owner:%
  A  A  A  A  A A  A  A  A  A  A  A  A A
 22Ethan+Gafford+%253Cegafford%2540redhat.com
  A  A  A  A  A A  A  A  A  A  A  A  A  A
 %253E%22+status:merged,n,z
  A  A  A  A  A 
  A  A  A  A  A A  A  A  A  A  A  A  A  A --
  A  A  A  A  A A  A  A  A  A  A  A  A  A Sincerely yours,
  A  A  A  A  A A  A  A  A  A  A  A  A  A Sergey Lukjanov
  A  A  A  A  A A  A  A  A  A  A  A  A  A Sahara Technical Lead
  A  A  A  A  A A  A  A  A  A  A  A  A  A (OpenStack Data
 Processing)
  A  A  A  A  A A  A  A  A  A  A  A  A  A Principal Software
 Engineer

[openstack-dev] [sahara] Bug triage/fix and doc update days in Liberty

2015-08-13 Thread Sergey Lukjanov
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-dev] [sahara] Proposing Ethan Gafford for the core reviewer team

2015-08-13 Thread Sergey Lukjanov
Hi folks,

I'd like to propose Ethan Gafford as a member of the Sahara core reviewer
team.

Ethan 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]. BTW Ethan is already stable maint team core for
Sahara.

Existing Sahara core reviewers, please vote +1/-1 for the addition of Ethan
to the core reviewer team.

Thanks.

[0]
https://review.openstack.org/#/q/reviewer:%22Ethan+Gafford+%253Cegafford%2540redhat.com%253E%22,n,z
[1] http://stackalytics.com/report/contribution/sahara-group/90
[2] http://stackalytics.com/?user_id=egaffordmetric=marks
[3]
https://review.openstack.org/#/q/owner:%22Ethan+Gafford+%253Cegafford%2540redhat.com%253E%22+status:merged,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


Re: [openstack-dev] [Sahara] [QA] [tests coverage] Can we add CI job to control the unit tests coverage?

2015-07-02 Thread Sergey Lukjanov
Hi Timur,

I absolutely disagree with this approach. IMO such checks just helps to
organize the unhealthy dev process when contributors will write tests only
to pass this check. We have a non-voting coverage job to track the unit
tests coverage in addition to the code review itself. It's the
responsibility of the core team to ask for additional unit tests if they
are missed. For Sahara project specifically there are tons of places where
unit tests will be just mocks testing and such tests are mostly useless.
For the places not covered by unit tests we have tons of integration tests.
Currently, we trying to force contributors to cover the new code with unit
tests if it's really applicable.

Let my add some numbers. We have ~ 55% total code coverage by unit tests
and ~70% by integration tests (significantly shifted in terms of code
blocks coverage comparing to the unit tests). If we'll ignore the plugins
dir that contains mostly deployment code fully tested by integration tests
we'll have ~70% unit tests coverage.

Thanks.

On Thu, Jul 2, 2015 at 8:55 PM, Timur Nurlygayanov 
tnurlygaya...@mirantis.com wrote:

 Hi all,

 I suggest to add CI job which will check the unit tests coverage for
 Sahara repository and will set -1 for commits with new code and without
 unit tests (if we have some degradation of tests coverage).
 This job successfully works for Rally project and it helps to organize the
 right code development process when developers write new unit tests for new
 functionality.

 we can just copy this job from Rally and start to use it for Sahara:
 Coverage control script:
 https://github.com/openstack/rally/blob/master/tests/ci/cover.sh
 Configuration file for coverage plugin (to exclude code which shouldn't be
 affected): https://github.com/openstack/rally/blob/master/.coveragerc
 Example of job in infra repository:
 https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L4088

 I expect that it will help to increase the tests coverage by unit tests.

 Do we have any objections?

 --

 Timur,
 Senior QA Engineer
 OpenStack Projects
 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




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


Re: [openstack-dev] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ?

2015-06-25 Thread Sergey Lukjanov
Hi,

Sahara doesn't have user's username and password, only user's token, that
could expire in some time. The simplest installation requires you to
specify credentials explicitly, but you could configure Sahara to access
Swift using proxy user and trusts, more info in docs -
http://docs.openstack.org/developer/sahara/userdoc/advanced.configuration.guide.html#object-storage-access-using-proxy-users

In this case, you don't need to specify credentials at all, Sahara will
create a trust for you and will use it to grant needed permissions to
automatically created user, that will be passed to Hadoop cluster to be
used to access data in Swift.

Thanks.

On Thu, Jun 25, 2015 at 12:10 PM, Li, Chen chen...@intel.com wrote:

  Hi Sahara,



 I’m working under UI.

 I have a tenant “demo”, with two users:  admin(role = admin)   demo.

 I’m working as user “demo”.



 When I try to create a datasource, it ask me to add username and password
 for swift.



 My question is:

 Why Sahara didn’t use current username(“demo”) and password to access
 swift directly ? Like it access keystone/Heat/Glance and other services ?



 And, how the proxy user works?

 I’m really confusing about this:
 http://docs.openstack.org/developer/sahara/userdoc/advanced.configuration.guide.html#object-storage-access-using-proxy-users



 Thanks.

 -chen



 __
 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




-- 
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-dev] [sahara] Liberty cycle client features releases planning

2015-06-18 Thread Sergey Lukjanov
Hi sahara folks,

I'd like to ask you to fill features you'd like to add to the sahara client
during the Liberty cycle. Please, add links to the specs / CRs, put your
name to have a contact. If you have an idea, when the patch will be ready,
put the date as well.

The main reason for doing it - to keep track of the needed changes and have
the official Liberty feature release of client in time (it should be done
before the Liberty-3).

Etherpad: https://etherpad.openstack.org/p/sahara-liberty-client

Thanks.

-- 
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-dev] [sahara] Removing Hadoop 1 support in Liberty

2015-06-18 Thread Sergey Lukjanov
Hi folks,

we were discussing the Hadoop 1 support drop on todays meeting [1] and so
I'd like to ensure that more people aware about it. So, it you are using
Hadoop 1 and would like us to keep it in Sahara, please, tell us about it
:) Spec on review [2] already.

[1]
http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-06-18-14.01.html
[2] https://review.openstack.org/#/c/192563/

Thanks.

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


Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

2015-06-16 Thread Sergey Lukjanov
I have a question regarding proposed release versions - are we starting to
count releases from zero? And 2015.1 (Kilo) missed in all projects in
etherpad. So, it means if we're starting from 0.0.0 then the proposed
versions are correct, but if we want to start from 1.0.0 (IMO it's better),
we should increment all proposed versions.

Re Sahara version I think it'll be more logical to count 0.X releases as a
single version 0.X and start from 1.0.0 for Icehose, 2.0.0 for Juno and
3.0.0 for Kilo, so, for Sahara I think anyway it'll be better to start
versioning from 4.0.0.

Thanks.

On Tue, Jun 16, 2015 at 12:04 PM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 06/16/2015 09:44 AM, Thierry Carrez wrote:
  Doug Hellmann wrote:
  [...] I still need to chat with Kyle about some of the neutron
  spin-out projects, since their repositories have the old neutron
  tags but I don't think it's appropriate to use the same version
  number as neutron for newer projects. [...] neutron 8.0.0
  neutron-fwaas neutron-lbaas neutron-vpnaas
 
  In Kilo (where they were introduced) those were released as a
  single deliverable made of 4 source code tarballs. They would do
  release candidates together, release together. My understanding is
  that they are not versioned separately, they are supposed to be
  used at the same version together.
 
  If that assumption is correct, I think we should still consider it
  a single deliverable with a single version scheme, and have the
  neutron-*aas all starting at 8.0.0.
 

 Yes, please don't assume they are independent, at least for now while
 *aas don't have their own API endpoints.

 Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVf+akAAoJEC5aWaUY1u57ryYH/30vflSJUTq8dseE4fL1Qv1u
 zLkq1bS39+AKRUihSqGQH+tNyq3tATBmqMDfMMzZ/WEYJfxsopiHnTJ4DMdpwNUo
 z31MmDO1CplG99PgK/9LE2jRagxeC18QpstnE5G4UkG/Ul/jzG+0os1pGjCi69i1
 9CQI1ZWUjRU8bbq8s7JISi54eCi0t5pzyoVqjh9MtJ5oOWhxFdD7bJg8jvjNzEb4
 5qT5ZSUk2iTI647sfap27fZS1DZ2KAmJwSFSE6jew+FVeepQh/UBPJmmNbcN1D3q
 uBg5+MDbnGXVhka/gB1m3k77JKglZI3DH4oI3wVsinRlyHsfh/gXNsOyPxHGHw0=
 =vQnQ
 -END PGP SIGNATURE-

 __
 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




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


Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

2015-06-16 Thread Sergey Lukjanov
Agree with Thierry, IMO it sounds more consistent

On Tue, Jun 16, 2015 at 12:45 PM, Thierry Carrez thie...@openstack.org
wrote:

 Doug Hellmann wrote:
  [...]
  I put together a little script [1] to try to count the previous
  releases for projects, to use that as the basis for their first
  SemVer-based version number. I pasted the output into an etherpad
  [2] and started making notes about proposed release numbers at the
  top. For now, I'm only working with the projects that have been
  managed by the release team (have the release:managed tag in the
  governance repository), but it should be easy enough for other projects
  to use the same idea to pick a version number.

 Your script missed 2015.1 tags for some reason...

 I still think we should count the number of integrated releases
 instead of the number of releases (basically considering pre-integration
 releases as 0.x releases). That would give:

 ceilometer 5.0.0
 cinder 7.0.0
 glance 11.0.0
 heat 5.0.0
 horizon 8.0.0
 ironic 2.0.0
 keystone 8.0.0
 neutron* 7.0.0
 nova 12.0.0
 sahara 3.0.0
 trove 4.0.0

 We also traditionally managed the previously-incubated projects. That
 would add the following to the mix:

 barbican 1.0.0
 designate 1.0.0
 manila 1.0.0
 zaqar 1.0.0

 --
 Thierry Carrez (ttx)

 __
 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




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


Re: [openstack-dev] [all][release] updating client requirements

2015-06-08 Thread Sergey Lukjanov
Re sahara client - I will release it today when requirements update CR
merged.

On Fri, Jun 5, 2015 at 6:40 PM, Doug Hellmann d...@doughellmann.com wrote:

 We have a bunch of client libraries with out-dated requirements to
 varying degrees [1], and some of them are causing dependency conflicts
 in gate jobs. It would be good if project teams could prioritize
 those reviews so we can release updates early next week.

 Thanks,
 Doug

 [1]
 https://review.openstack.org/#/q/owner:%22OpenStack+Proposal+Bot%22+status:open+branch:master+project:%255Eopenstack/python-.*client,n,z

 __
 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




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


Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a project to deliver Machine Learning as a Service for OpenStack

2015-05-22 Thread Sergey Lukjanov
So, in case if Cognitive will use Sahara to create big data clusters - then
it sounds ok.

On Fri, May 22, 2015 at 8:54 AM, Debojyoti Dutta ddu...@gmail.com wrote:

 One more thing and a typo in my mail  -  we would be happy to point folks
 to an very early version (in Django) we prototyped and opened up recently.

 thx
 debo



 On Fri, May 22, 2015 at 8:48 AM, Debojyoti Dutta ddu...@gmail.com wrote:

 Hi Sergey

 Thanks a lot for your interest. The bare bones API proposal is up on the
 wiki page http://wiki.openstack.org/Cognitive

 Sahara is about deploying and managing big data workloads like hadoop,
 spark etc. Cognitive is about a simple API to do predictive analytics,
 learning, data science workflow etc etc. Thus the goals are different. AWS
 has Elastic MapReduce (in the same space as Sahara) and also AWS Machine
 Learning (http://aws.amazon.com/machine-learning/) for which there is no
 parallel. Should we point them to our internal 1st version of Cognitive on
 our github which we opened.

 If it requires to use big data toolchains to do our job, we will
 definitely leverage Sahara for that, and not replicate the good work done
 in Sahara. Our primary goal is to build (within the community) a simple
 machine learning API (and a service) that abstracts the pain of data
 science for the app developer.


 thx

 debo


 PS: FWIW  I am at the summit till tonight so we could catch up here.



 On Tue, May 19, 2015 at 2:16 PM, Sergey Lukjanov slukja...@mirantis.com
 wrote:

 Hi,

 as there is no any details on the project yet done, if this project will
 deploy ML frameworks it'll be direct duplication of Sahara's functionality
 (we already support HDP and CDH deployments and they are provided tons of
 tools for ML). So, I think that it could be built on top of Sahara or even
 as part of Sahara probably. I'd like to propose you to take a deeper look
 on Sahara and avoid duplicating it.

 Thanks.

 On Thu, May 14, 2015 at 8:47 PM, Debojyoti Dutta ddu...@gmail.com
 wrote:

 Hi Salvatore

 Thanks a lot for your comments.

 Timing: Yes it is time to do this! The nature of applications running
 on clouds is indeed changing.

 Initial group: We asked around for folks interested and we got a lot
 more people than we expected. The idea is to get something out there in a
 stack forge project and build something good. This group already has people
 who have built things like this already in the past. Hence confident about
 the success.

 Participation: We want this to be inclusive from scratch independent of
 who is a PTL or a contributor or merely a curious individual to give us
 ideas :) The community will get it right. Maybe I should have clarified
 that these are the members interested in seeing this happen.

 Wiki page: The wiki page will be ready in 1-2 days. Also we would like
 to have a discussion during the summit to see what we should build in the
 community. Would be delighted to get your thoughts.

 Services: Some of the services this could provide:
 * create experiments: define data sources, train models, then perform
 classification, clustering, data cleaning etc.
 * have experiment templates that can be reused
 * have an editor (maybe a horizon plugin) to drag and drop the workflow
 and generate an API that when called from an app would provide results
 * ML primitives that could be targeted initially: 1) classification  2)
 clustering 3) Anomaly detection

 thx
 debo

 On Thu, May 14, 2015 at 5:02 PM, Salvatore Orlando sorla...@nicira.com
  wrote:


 On 15 May 2015 at 00:19, Debojyoti Dutta ddu...@gmail.com wrote:

 Hi!

 It is a great pleasure to announce the development of a new project
 called Cognitive.  Cognitive provides Machine Learning [1] as a Service
 that enables operators to offer next generation data science based 
 services
 on top of their OpenStack Clouds.


 I was indeed wondering when Machine Learning as a Service would come
 up...


 This project will begin as a StackForge project baed upon an empty
 cookiecutter [2] repo.  The repos to work in are:
 Server: https://github.com/stackforge/cognitive
 Client: https://github.com/stackforge/python-cognitiveclient

 Please join us via iRC on #openstack-cognitive on freenode.

 We will be holding a doodle poll to select times for our first
 meeting the week after summit.  This doodle poll will close May 24th and
 meeting times will be announced on the mailing list at that time.  At our
 first IRC meeting, we will draft additional core team members. We would
 like to invite interested individuals to join this exciting new 
 development
 effort!


 From my little experience, drafting core members before even
 actually having a code base has drawbacks. Also, it seems the initial
 starting team is already large enough for ensuring support for 1 or 2
 release cycle.





 Please commit your schedule in the doodle poll here:
 http://doodle.com/drrka5tgbwpbfbxy

 Initial core team: Steven Dake, Aparupa Das Gupa, Debo~ Dutta, Johnu
 George

Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a project to deliver Machine Learning as a Service for OpenStack

2015-05-19 Thread Sergey Lukjanov
 in designing a world class
 Machine Learning as a Service solution.

 We look forward to seeing you on IRC on #openstack-cognitive.

 Regards,
 Debo~ Dutta (on behalf of the initial team)

 [1] http://en.wikipedia.org/wiki/Machine_learning
 [2] https://github.com/openstack-dev/cookiecutter


 __
 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




 --
 -Debo~

 __
 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




-- 
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-dev] [sahara] no meetings May 21 and 28

2015-05-19 Thread Sergey Lukjanov
Hey,

on the meeting last week we agreed to skip IRC meetings on a summer week
and on a week after.

Thanks.

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


Re: [openstack-dev] [surge] Introducing Surge - rapid deploy/scale stream processing systems on OpenStack

2015-05-19 Thread Sergey Lukjanov
Actually the same as for the MLaaS - please, take a deeper look at Sahara
before starting duplicating already existing things.

On Tue, May 19, 2015 at 2:07 PM, Sergey Lukjanov slukja...@mirantis.com
wrote:

 Agreed with notes about the fact that mostly everything is already
 supported by Sahara. The question is there any hidden reason to not
 contribute it into Sahara?

 On Mon, May 18, 2015 at 4:38 PM, Andrew Lazarev alaza...@mirantis.com
 wrote:

 As I see Surge is pretty much replicating Sahara functionality running
 in one process per host mode. Sahara currently supports much more
 features.

 Andrew.

 On Fri, May 15, 2015 at 10:38 AM, Joe Gordon joe.gord...@gmail.com
 wrote:



 On Fri, May 15, 2015 at 10:13 AM, Debojyoti Dutta ddu...@gmail.com
 wrote:

 Hi,

 It gives me a great pleasure to introduce Surge - a system to rapidly
 deploy and scale a stream processing system on OpenStack. It leverages
 Vagrant and Ansible, and supports both OpenStack as well as the local mode
 (with VirtualBox).

 https://github.com/CiscoSystems/surge


 I see you support Storm and Kafka,

 How is this different then Sahara's Storm plugin?


 https://github.com/openstack/sahara/blob/45045d918f363fa5763cde700561434345017661/setup.cfg#L47

 And I See Sahara is exploring Kafka support:
 https://blueprints.launchpad.net/sahara/+spec/cdh-kafka-service


 Hope to see a lot of pull requests and comments.

 thx
 -Debo~


 __
 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




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




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


Re: [openstack-dev] [surge] Introducing Surge - rapid deploy/scale stream processing systems on OpenStack

2015-05-19 Thread Sergey Lukjanov
Agreed with notes about the fact that mostly everything is already
supported by Sahara. The question is there any hidden reason to not
contribute it into Sahara?

On Mon, May 18, 2015 at 4:38 PM, Andrew Lazarev alaza...@mirantis.com
wrote:

 As I see Surge is pretty much replicating Sahara functionality running in
 one process per host mode. Sahara currently supports much more features.

 Andrew.

 On Fri, May 15, 2015 at 10:38 AM, Joe Gordon joe.gord...@gmail.com
 wrote:



 On Fri, May 15, 2015 at 10:13 AM, Debojyoti Dutta ddu...@gmail.com
 wrote:

 Hi,

 It gives me a great pleasure to introduce Surge - a system to rapidly
 deploy and scale a stream processing system on OpenStack. It leverages
 Vagrant and Ansible, and supports both OpenStack as well as the local mode
 (with VirtualBox).

 https://github.com/CiscoSystems/surge


 I see you support Storm and Kafka,

 How is this different then Sahara's Storm plugin?


 https://github.com/openstack/sahara/blob/45045d918f363fa5763cde700561434345017661/setup.cfg#L47

 And I See Sahara is exploring Kafka support:
 https://blueprints.launchpad.net/sahara/+spec/cdh-kafka-service


 Hope to see a lot of pull requests and comments.

 thx
 -Debo~


 __
 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




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


Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration. Summit working session

2015-05-14 Thread Sergey Lukjanov
Hey,

in Sahara we're looking on using Zaqar as a transport for agent some day as
well. Unfortunately this section overlaps with Sahara sessions.

On Thu, May 14, 2015 at 12:19 AM, Flavio Percoco fla...@redhat.com wrote:

 On 13/05/15 18:06 +, Fox, Kevin M wrote:

 Sahara also has the same problem, but worse, since they currently only
 support ssh with their agent, so its either assign floating ip's to all
 nodes, or your sahara controller must be on your one and only network node
 so it can tunnel. :/

 Should we have a chat with them too?


 We've scheduled a discussion with Trove's team on Thursday at 5pm.
 It'd be great to have this discussion once and together to know what
 the common issues are and what things need to be done.

 I'll ping folks from both teams to invite them to this session. If
 they can't make it, I'm happy to use another working session slot.

 Cheers,
 Flavio


 http://libertydesignsummit.sched.org/event/59dc6ec910a732cdbf5970b6792e1cef#.VVRL0PYU9hE



 Thanks,
 Kevin
 
 From: Zane Bitter [zbit...@redhat.com]
 Sent: Wednesday, May 13, 2015 10:26 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration.
 Summit working session

 On 11/05/15 05:49, Flavio Percoco wrote:

 On 08/05/15 00:45 -0700, Nikhil Manchanda wrote:

3)  The trove-guest-agent is in vm. it is connected by taskmanager
by rabbitmq. We designed it. But is there some prectise to do this?
 how to make the vm be connected in vm-network and management
 network?


 Most deployments of Trove that I am familiar with set up a separate
 RabbitMQ server in cloud that is used by Trove. It is not recommended to
 use the same infrastructure RabbitMQ server for Trove for security
 reasons. Also most deployments of Trove set up a private (neutron)
 network that the RabbitMQ server and guests are connected to, and all
 RPC messages are sent over this network.


 We've discussed trove+zaqar in the past and I believe some folks from the
 Trove team have been in contact with Fei Long lately about this. Since
 one of the projects goal's for this cycle is to provide support to
 other projects and contribute to the adoption, I'm wondering if any of
 the members of the trove team would be willing to participate in a
 Zaqar working session completely dedicated to this integration?


 +1

 I learned from a concurrent thread ([Murano] [Mistral] SSH workflow
 action) that Murano are doing exactly the same thing with a separate
 RabbitMQ server to communicate with guest agents. It's a real waste of
 energy when multiple OpenStack projects all have to solve the same
 problem from scratch, so a single answer to this would be great.

 In that thread I suggested (and Murano developers agreed with) making
 the transport pluggable so that operators could choose Zaqar instead. I
 would strongly support doing the same here.


 +1 :)

 Flavio



 cheers,
 Zane.

  It'd be a great opportunity to figure out what's really needed, edge
 cases and get some work done on this specific case.

 Thanks,
 Flavio




 __
 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


 --
 @flaper87
 Flavio Percoco

 __
 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




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


Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration. Summit working session

2015-05-14 Thread Sergey Lukjanov
Flavio, it would be great if we could chat about Sahara-Zaqar at Thu 9am

On Thu, May 14, 2015 at 1:13 PM, Fox, Kevin M kevin@pnnl.gov wrote:

 If there's a free session, can we dedicate a session specifically to the
 zaqar, barbican, sahara, heat, trove, guestagent, keystone auth thingy so
 everyone's all together?

 Thanks,
 Kevin
 
 From: Flavio Percoco [fla...@redhat.com]
 Sent: Thursday, May 14, 2015 12:15 PM
 To: Sergey Lukjanov
 Cc: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration.
 Summit working session

 On 14/05/15 10:07 -0700, Sergey Lukjanov wrote:
 Hey,
 
 in Sahara we're looking on using Zaqar as a transport for agent some day
 as
 well. Unfortunately this section overlaps with Sahara sessions.

 Sergey,

 We still have some free sessions, we'd be happy to dedicate one to
 Sahara. Any slot that looks good for you?


 http://libertydesignsummit.sched.org/overview/type/design+summit/Zaqar#.VVT0CvYU9hE

 Thanks,
 Flavio

 
 On Thu, May 14, 2015 at 12:19 AM, Flavio Percoco fla...@redhat.com
 wrote:
 
 On 13/05/15 18:06 +, Fox, Kevin M wrote:
 
 Sahara also has the same problem, but worse, since they currently
 only
 support ssh with their agent, so its either assign floating ip's
 to all
 nodes, or your sahara controller must be on your one and only
 network
 node so it can tunnel. :/
 
 Should we have a chat with them too?
 
 
 We've scheduled a discussion with Trove's team on Thursday at 5pm.
 It'd be great to have this discussion once and together to know what
 the common issues are and what things need to be done.
 
 I'll ping folks from both teams to invite them to this session. If
 they can't make it, I'm happy to use another working session slot.
 
 Cheers,
 Flavio
 
 
 http://libertydesignsummit.sched.org/event/59dc6ec910a732cdbf5970b6792e1cef
 #.VVRL0PYU9hE
 
 
 
 
 Thanks,
 Kevin
 
 From: Zane Bitter [zbit...@redhat.com]
 Sent: Wednesday, May 13, 2015 10:26 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [trove][zaqar] Trove and Zaqar
 integration. Summit working session
 
 On 11/05/15 05:49, Flavio Percoco wrote:
 
 On 08/05/15 00:45 -0700, Nikhil Manchanda wrote:
 
3)  The trove-guest-agent is in vm. it is
 connected by
 taskmanager
by rabbitmq. We designed it. But is there some
 prectise
 to do this?
 how to make the vm be connected in vm-network
 and
 management
 network?
 
 
 Most deployments of Trove that I am familiar with set up a
 separate
 RabbitMQ server in cloud that is used by Trove. It is not
 recommended to
 use the same infrastructure RabbitMQ server for Trove for
 security
 reasons. Also most deployments of Trove set up a private
 (neutron)
 network that the RabbitMQ server and guests are connected
 to,
 and all
 RPC messages are sent over this network.
 
 
 We've discussed trove+zaqar in the past and I believe some
 folks
 from the
 Trove team have been in contact with Fei Long lately about
 this.
 Since
 one of the projects goal's for this cycle is to provide
 support to
 other projects and contribute to the adoption, I'm wondering
 if any
 of
 the members of the trove team would be willing to participate
 in a
 Zaqar working session completely dedicated to this
 integration?
 
 
 +1
 
 I learned from a concurrent thread ([Murano] [Mistral] SSH
 workflow
 action) that Murano are doing exactly the same thing with a
 separate
 RabbitMQ server to communicate with guest agents. It's a real
 waste of
 energy when multiple OpenStack projects all have to solve the same
 problem from scratch, so a single answer to this would be great.
 
 In that thread I suggested (and Murano developers agreed with)
 making
 the transport pluggable so that operators could choose Zaqar
 instead. I
 would strongly support doing the same here.
 
 
 +1 :)
 
 Flavio
 
 
 
 
 cheers,
 Zane.
 
 
 It'd be a great opportunity to figure out what's really
 needed,
 edge
 cases and get some work done on this specific case.
 
 Thanks,
 Flavio
 
 
 
 
 __
 OpenStack Development

[openstack-dev] [sahara] etherpads for design summit

2015-05-11 Thread Sergey Lukjanov
Hey folks,

I've ensured that all threads created and added them to
https://wiki.openstack.org/wiki/Summit/Liberty/Etherpads#Sahara and
http://libertydesignsummit.sched.org/type/design+summit/Sahara

Session drivers, please, fill the etherpads with info.

Thanks.

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


Re: [openstack-dev] [api] Proposing Michael McCune as an API Working Group core

2015-05-11 Thread Sergey Lukjanov
Hi,

I'm not an API WG core or active participant (unfortunately), but from
Sahara in-project API discussions Michael is very active and he's now
driving our next API design as well as being Sahara liaison in API WG.

Thanks.

On Mon, May 11, 2015 at 11:18 PM, Everett Toews everett.to...@rackspace.com
 wrote:

 I would like to propose Michael McCune (elmiko) as an API Working Group
 core.

 Among Michael’s many fine qualities:

   * Active from the start
   * Highly available
   * Very knowledgable about APIs
   * Committed the guideline template
   * Working on moving the API Guidelines wiki page
   * Lots of solid review work

 Cheers,
 Everett


 __
 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




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


Re: [openstack-dev] [Sahara] improve oozie engine for common lib management

2015-05-11 Thread Sergey Lukjanov
Hi,

do you think it could be implemented based on job binaries? It sounds like
it's a type of job binary that should be always uploaded to Oozie for the
tenant where it lives. (A bit crazy, but could useful).

Thanks.

On Mon, May 11, 2015 at 6:39 PM, lu jander juvenboy1...@gmail.com wrote:

 Hi, All
 Currently, oozie share lib is not well known and can be hardly used by the
 users, so I think we can  make it less oozieness and more friendly for the
 users, it can be used for running jobs which are using third party libs. If
 many jobs use the same libs, oozie share lib can make it as a common share
 lib.

 here is the bp,
 https://blueprints.launchpad.net/sahara/+spec/improve-oozie-share-lib
 I will write a spec soon after scheduled edp jobs bp.

 __
 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




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


Re: [openstack-dev] [sahara][CDH] Is it possible to add CDH5.4 into Kilo release now?

2015-04-29 Thread Sergey Lukjanov
Trevor, yup, that's correct.

Adding new plugin version support is the new feature and there is no way to
backport it to stable/kilo branch (Kilo release).

Thanks.

On Wed, Apr 29, 2015 at 4:04 PM, Trevor McKay tmc...@redhat.com wrote:

 Kilo is closed to everything but critical bugs at this point.

 Going forward, this change probably counts as a new feature and is
 forbidden as a backport to Kilo too. So Liberty is the earliest
 opportunity.

 https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes

 Trev

 On Wed, 2015-04-29 at 04:49 +, Chen, Ken wrote:
  Hi all,
 
  Currently Cloudera has already release CDH5.4.0 version. I have
  already registered a bp and submitted two patches for it
  (https://blueprints.launchpad.net/sahara/+spec/cdh-5-4-support) .
  However, they are for master stream, and Cloudera hope it can be added
  to the latest release version of Sahara (Kilo release) so that they
  can give better support to their customers. I am not sure whether it
  is possible to do this at this stage?
 
 
 
  -Ken
 
 
 
 __
  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




-- 
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-dev] [all] Gerrit restarted due to the internal issues

2015-04-27 Thread Sergey Lukjanov
Hi folks,

I've just restarted review.openstack.org gerrit to fix issue with sending
events. It means that some of your patches needs to be rechecked to receive
votes from CI.

3rd party CIs maintainers, you probably should restart your Zuul service to
ensure it reconnected after gerrit restart.

Thanks.

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


Re: [openstack-dev] [OpenStack-Infra] [all] Gerrit currently down

2015-04-27 Thread Sergey Lukjanov
Gerrit has been restarted and it works ok now.

On Mon, Apr 27, 2015 at 8:25 AM, Andreas Jaeger a...@suse.com wrote:

 Our CI system is currently not processing any events. This means that no
 new check or gate jobs get started.

 Uploading new patches and reviewing is working fine.

 But new patches uploaded will not get checked and patches approved will
 not get gated and merge - and recheck will not help either.

 We have to wait until somebody with root access to the CI systems can fix
 the problem. Somebody from the infra team will tell you once the systems is
 up and what needs to be done with any changes changed during the downtime,

 Andreas
 --
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
 GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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




-- 
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-dev] TC Candidacy

2015-04-22 Thread Sergey Lukjanov
Hi folks,

I’d like to announce my candidacy for the TC elections.

Here is a list of the main directions I would like to concentrate on as a
TC member:

* Continue to grow the OpenStack long-term vision and inclusive approach
that comes with The Big Tent. We should not just be more inclusive, but
also provide new OpenStack projects with fine-grained directions for
improvements, recommendations and cross-project coordination.

* Strengthen the voice of the platform projects (Heat, Sahara, Murano, etc)
on the Technical Committee.

* Bring additional focus and attention to OpenStack end users of all
levels, especially application developers who are the most active cloud
users.

* Help OpenStack community newcomers better understand the process of
contributing, learning the upstream tooling, and finding answers to their
common questions.

* Allow more self-governance and automation of common tasks like adding new
source repositories without TC pre-approval.

A few words about me. I have been actively involved in OpenStack community
for the last 2.5 years. I’m PTL of OpenStack Data Processing service
(“Sahara”) from its very beginning and a core team member of the OpenStack
Infrastructure team. Before OpenStack, I was involved in other open source
projects including Apache/Twitter Storm, Kotlin and Big Data solutions. I’m
currently leading the Sahara team and an internal OpenStack Infra clone
initiative at Mirantis.

Thanks.


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


Re: [openstack-dev] Global Cluster Template in Sahara

2015-04-16 Thread Sergey Lukjanov
Hi,

first of all - yes, we've implemented mechanism for default templates
addition in Kilo, please, take a look on this spec and related changes:
http://specs.openstack.org/openstack/sahara-specs/specs/kilo/default-templates.html


Regarding to your case, it's in fact about the admin-only writable
templates shared between all tenants. We have a blueprint for implementing
ACL for all Sahara resources -
https://blueprints.launchpad.net/sahara/+spec/resources-acl . It's about
implementing extended and flexible way to configure ACLs for resources and
to provide end-users an ability to have the following types of resources:

* default - tenant specific, anyone in tenant could edit or delete
* public - shared between tenants in read-only mode, writable for users in
tenant where it was created
* protected - if True than could not be removed before updated to False
using the resource update operation
* admin or protected=Admin - to make only admin users able to write/delete
resource

during the Kilo cycle we've been discussing this idea and initially agreed
on it, because it sounds like the most OpenStackish way to provide such
functionality. I have a draft spec for it (not yet published), I will
publish it today/tomorrow and send a link to it to this thread.

Yanchao, does this ACL mechanism covers your use case? Any feedback
appreciated.

Thanks.

On Thu, Apr 16, 2015 at 3:19 AM, lu jander juvenboy1...@gmail.com wrote:

 We have already implement the default template for sahara

 https://blueprints.launchpad.net/sahara/+spec/default-templates

 2015-04-16 5:22 GMT+08:00 Liang, Yanchao yanli...@ebay.com:

  Dear Openstack Developers,

  My name is Yanchao Liang. I am a software engineer in eBay, working on
 Hadoop as a Service on top of Openstack cloud.

  Right now we are using Sahara, Juno version. We want to stay current
 and introduce global template into sahara.

  In order to simplify the cluster creation process for user, we would
 like to create some cluster templates available for all users. User can
 just go to the horizon webUI, select one of the pre-popluated templates and
 create a hadoop cluster, in just a few clicks.

  Here is how I would implement this feature:

- In the database, Create a new column in “cluster_templates table
called “is_global”, which is a boolean value indicating whether the
template is available for all users or not.
- When user getting the cluster template from database,  add another
function similar to “cluster_template_get”, which query the database for
global templates.
- When creating cluster, put the user’s tenant id in
the “merged_values” config variable, instead of the tenant id from cluster
template.
- Use an admin account create and manage global cluster templates

 Since I don’t know the code base as well as you do, what do you think
 about the global template idea? How would you implement this new feature?

  We would like to contribute this feature back to the Openstack
 community. Any feedback would be greatly appreciated. Thank you.

  Best,
 Yanchao


 __
 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




-- 
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-dev] [sahara] PTL Candidacy

2015-04-08 Thread Sergey Lukjanov
Hey folks,

I'd like to announce my intention to continue being PTL of the Data
Processing program (Sahara).

I’m working on Sahara (ex. Savanna) project from scratch, from the
initial proof of concept implementation and till now. I have been the
acting/elected PTL since Sahara was an idea. Additionally, I’m
contributing to other OpenStack projects, especially Infrastructure
for the last three releases where I’m core/root teams member now.

My high-level focus as PTL is to coordinate work of subteams, code
review, release management and general architecture/design tracking.

During the Kilo cycle we successfully adopted specs and czars systems.
Tons of operability and supportability improvements were done as well
as number of interesting features.

For Liberty cycle my focus is to keep going in the same direction and
to ensure that everything we're working on is related to the end users
needs. So, in a few words it's about continuing moving forward in
implementing scalable and flexible Data Processing aaS for OpenStack
ecosystem by investing in quality, usability and new features.

A few words about myself: I’m Principle Software Engineer in Mirantis.
I was working a lot with  Big Data projects and technologies (Hadoop,
HDFS, Cassandra, Twitter Storm, etc.) and enterprise-grade solutions
before (and partially in parallel) working on Sahara in OpenStack ecosystem.

-- 
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-dev] [sahara] Last client release in Kilo

2015-03-30 Thread Sergey Lukjanov
Hi Sahara folks,

please, share your thoughts about about which changes should be included
into the last sahara client release in Kilo to add this version to global
requirements and use it in Heat, Horizon, etc.

Here is an etherpad: https://etherpad.openstack.org/p/sahara-kilo-client

Thanks.

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


Re: [openstack-dev] [Sahara] Question about Sahara API v2

2015-03-30 Thread Sergey Lukjanov
Hi,

in a few words - we're finding out some places that were designed not very
well (or our vision changed) and so we'd like to update the API to have a
much better interface to work with Sahara. The blueprint you've listed was
created in Atlanta summit timeframe and so it's not actual now.

My personal opinion for API 2.0 - we should discuss design of all object
and endpoint, review how they are used from Horizon or python-saharaclient
and improve them as much as possible. For example, it includes:

* get rid of tons of extra optional fields
* rename Job - Job Template, Job Execution - Job
* better support for Horizon needs
* hrefs

If you have any ideas ideas about 2.0 - please write them up, there is a
99% chance that we'll discuss an API 2.0 a lot on Vancouver summit.

Thanks.

On Mon, Mar 30, 2015 at 5:34 AM, Chen, Ken ken.c...@intel.com wrote:

  Hi all,

 Recently I have read some contents about Sahara API v2 propose, but I am
 still a bit confused why we are doing so at this stage. I read the bp
 https://blueprints.launchpad.net/sahara/+spec/v2-api-impl and the
 involved gerrit reviews (although already abandoned). However, I did not
 find anything new than current v1+v1.1 APIs. So why do we want v2 API? Just
 to combine v1 and v1.1 APIs? Is there any deeper requirement or background
 needs us to do so? Please let me know that if yes.

 Btw, I also see some comments that we may want to introduce PECAN to
 implement Sahara APIs. Will that be soon in Liberty, or not decided yet?



 Thanks a lot.

 -Ken

 __
 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




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


Re: [openstack-dev] [Sahara] Question about Sahara API v2

2015-03-30 Thread Sergey Lukjanov
Agree with Mike, thx for the link.

On Mon, Mar 30, 2015 at 4:55 PM, michael mccune m...@redhat.com wrote:

 On 03/30/2015 07:02 AM, Sergey Lukjanov wrote:

 My personal opinion for API 2.0 - we should discuss design of all object
 and endpoint, review how they are used from Horizon or
 python-saharaclient and improve them as much as possible. For example,
 it includes:

 * get rid of tons of extra optional fields
 * rename Job - Job Template, Job Execution - Job
 * better support for Horizon needs
 * hrefs

 If you have any ideas ideas about 2.0 - please write them up, there is a
 99% chance that we'll discuss an API 2.0 a lot on Vancouver summit.


 +1

 i've started a pad that we can use to collect ideas for the discussion:
 https://etherpad.openstack.org/p/sahara-liberty-api-v2

 things that i'd like to see from the v2 discussion

 * a full endpoint review, some of the endpoints might need to be
 deprecated or adjusted slightly (for example, job-binary-internals)

 * a technology review, should we consider Pecan or stay with Flask?

 * proposals for more radical changes to the api; use of micro-versions
 akin to nova's plan, migrating the project id into the headers, possible
 use of swagger to aid in auto-generation of api definitions.

 i think we will have a good amount to discuss and i will be migrating some
 of my local notes into the pad over this week and the next. i invite
 everyone to add their thoughts to the pad for ideas.

 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




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


Re: [openstack-dev] [murano] PTL elections

2015-03-20 Thread Sergey Lukjanov
Hi John,

Murano isn't official project and so we've started the election process
earlier, you could see dates in the first email in this thread. There was
only one candidate, so, voting itself was bypassed.

till 05:59 UTC March 17, 2015: Open candidacy to PTL positions
March 17, 2015 - 1300 UTC March 24, 2015: PTL elections

The link [1] was an example of how it was going a year ago (April 2014),
probably I've used bad wording :(

The another link in my initial mail specifies the time frame for current
Murano PTL election:

https://wiki.openstack.org/wiki/Murano/PTL_Elections_Kilo_Liberty

Thanks.

On Fri, Mar 20, 2015 at 7:01 AM, John Griffith john.griffi...@gmail.com
wrote:



 On Wed, Mar 18, 2015 at 6:59 AM, Serg Melikyan smelik...@mirantis.com
 wrote:

 Thank you!

 On Wed, Mar 18, 2015 at 8:28 AM, Sergey Lukjanov slukja...@mirantis.com
 wrote:

 The PTL candidacy proposal time frame ended and we have only one
 candidate.

 So, Serg Melikyan, my congratulations!

 Results documented in
 https://wiki.openstack.org/wiki/Murano/PTL_Elections_Kilo_Liberty#PTL

 On Wed, Mar 11, 2015 at 2:04 AM, Sergey Lukjanov slukja...@mirantis.com
  wrote:

 Hi folks,

 due to the requirement to have officially elected PTL, we're running
 elections for the Murano PTL for Kilo and Liberty cycles. Schedule
 and policies are fully aligned with official OpenStack PTLs elections.

 You can find more info in official elections wiki page [0] and the same
 page for Murano elections [1], additionally some more info in the past
 official nominations opening email [2].

 Timeline:

 till 05:59 UTC March 17, 2015: Open candidacy to PTL positions
 March 17, 2015 - 1300 UTC March 24, 2015: PTL elections

 To announce your candidacy please start a new openstack-dev at
 lists.openstack.org mailing list thread with the following subject:
 [murano] PTL Candidacy.

 [0] https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014
 [1] https://wiki.openstack.org/wiki/Murano/PTL_Elections_Kilo_Liberty
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-March/031239.html

 Thank you.

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




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




 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 __
 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

 ​
 Certainly not disputing/challenging this, but I'm slightly confused; isn't
 the proposal deadline April 4?  You referenced it yourself in the link
 here: [1].  Or is there some special process unique to Murano?


 [1] https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014
 ​


 __
 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




-- 
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-dev] [sahara] team meeting Mar 19 1800 UTC

2015-03-18 Thread Sergey Lukjanov
Hi folks,

We'll be having the Sahara team meeting in #openstack-meeting-alt channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150319T18

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


Re: [openstack-dev] [murano] PTL elections

2015-03-17 Thread Sergey Lukjanov
The PTL candidacy proposal time frame ended and we have only one candidate.

So, Serg Melikyan, my congratulations!

Results documented in
https://wiki.openstack.org/wiki/Murano/PTL_Elections_Kilo_Liberty#PTL

On Wed, Mar 11, 2015 at 2:04 AM, Sergey Lukjanov slukja...@mirantis.com
wrote:

 Hi folks,

 due to the requirement to have officially elected PTL, we're running
 elections for the Murano PTL for Kilo and Liberty cycles. Schedule
 and policies are fully aligned with official OpenStack PTLs elections.

 You can find more info in official elections wiki page [0] and the same
 page for Murano elections [1], additionally some more info in the past
 official nominations opening email [2].

 Timeline:

 till 05:59 UTC March 17, 2015: Open candidacy to PTL positions
 March 17, 2015 - 1300 UTC March 24, 2015: PTL elections

 To announce your candidacy please start a new openstack-dev at
 lists.openstack.org mailing list thread with the following subject:
 [murano] PTL Candidacy.

 [0] https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014
 [1] https://wiki.openstack.org/wiki/Murano/PTL_Elections_Kilo_Liberty
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-March/031239.html

 Thank you.

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




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


Re: [openstack-dev] [Murano] PTL Candidacy

2015-03-13 Thread Sergey Lukjanov
Ack -
https://wiki.openstack.org/wiki/Murano/PTL_Elections_Kilo_Liberty#Candidates

On Wed, Mar 11, 2015 at 1:01 PM, Serg Melikyan smelik...@mirantis.com
wrote:

 Hi folks,

 I'd like to announce my candidacy as PTL for Murano [1].

 I was handling PTL responsibilities in this release cycle so far,
 after Ruslan Kamaldinov (who was handling them in Juno cycle) hand
 over them to me on OpenStack Summit in Paris. I am working on Murano
 since it's kick-off two years ago [2][3].

 As a PTL of Murano I'll continue my work on making Murano better with
 each day and become project of choice for building own Application
 Catalogs  Marketplaces for private  public clouds on OpenStack. I
 will focus on building great environment for contributors and work on
 relationships built around the project itself not only around the
 features needed by contributors.

 [1] http://wiki.openstack.org/wiki/Murano
 [2] http://stackalytics.com/report/contribution/murano/90
 [3] http://stackalytics.com/?
 release=kilometric=commitsproject_type=stackforgemodule=murano-group

 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 __
 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




-- 
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-dev] [sahara] Design summit proposals for Liberty Summit

2015-03-13 Thread Sergey Lukjanov
Hi folks,

I've created an etherpad to start submitting design summit talks proposals:

https://etherpad.openstack.org/p/sahara-liberty-proposed-sessions

On April 16th, we will have an initial discussion for the approved topics
and on April 23rd we should have finally ready list of topics to fill the
official summit schedule.

-- 
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-dev] [sahara] team meeting Mar 12 1400 UTC

2015-03-11 Thread Sergey Lukjanov
Hi sahara folks,

We'll be having the Sahara team meeting tomorrow at #openstack-meeting-3
channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150312T14

P.S. I'll be unavailable at this time unfortunately, so, Andrew Lazarev
will chair the meeting.

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


Re: [openstack-dev] [sahara] team meeting Mar 12 1400 UTC

2015-03-11 Thread Sergey Lukjanov
Correction, Michael McCune (elmiko) will chair the meeting.

On Wed, Mar 11, 2015 at 3:57 PM, Sergey Lukjanov slukja...@mirantis.com
wrote:

 Hi sahara folks,

 We'll be having the Sahara team meeting tomorrow at #openstack-meeting-3
 channel.

 Agenda:
 https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings


 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150312T14

 P.S. I'll be unavailable at this time unfortunately, so, Andrew Lazarev
 will chair the meeting.

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




-- 
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-dev] [murano] PTL elections

2015-03-10 Thread Sergey Lukjanov
Hi folks,

due to the requirement to have officially elected PTL, we're running
elections for the Murano PTL for Kilo and Liberty cycles. Schedule
and policies are fully aligned with official OpenStack PTLs elections.

You can find more info in official elections wiki page [0] and the same
page for Murano elections [1], additionally some more info in the past
official nominations opening email [2].

Timeline:

till 05:59 UTC March 17, 2015: Open candidacy to PTL positions
March 17, 2015 - 1300 UTC March 24, 2015: PTL elections

To announce your candidacy please start a new openstack-dev at
lists.openstack.org mailing list thread with the following subject:
[murano] PTL Candidacy.

[0] https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014
[1] https://wiki.openstack.org/wiki/Murano/PTL_Elections_Kilo_Liberty
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-March/031239.html

Thank you.

-- 
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-dev] [sahara] team meeting Mar 5 1800 UTC

2015-03-04 Thread Sergey Lukjanov
Hi folks,

We'll be having the Sahara team meeting in #openstack-meeting-alt channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150305T18

-- 
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-dev] [sahara] Reminder: FPF at Mar 5

2015-03-03 Thread Sergey Lukjanov
Hi Sahara folks,

FPF [1] will be at Mar 5 and it means that all CRs should be proposed for
features and all new features related CRs will need FPF exception to be
merged.

[1] https://wiki.openstack.org/wiki/FeatureProposalFreeze

-- 
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-dev] [sahara] team meeting Feb 26 1400 UTC

2015-02-25 Thread Sergey Lukjanov
Hi sahara folks,

We'll be having the Sahara team meeting tomorrow at #openstack-meeting-3
channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150226T14


-- 
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-dev] [sahara] team meeting Feb 19 1800 UTC

2015-02-18 Thread Sergey Lukjanov
Hi folks,

We'll be having the Sahara team meeting in #openstack-meeting-alt channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150219T18

P.S. I'll be on plane at this time, so, Andrew Lazarev will chair this
meeting.

-- 
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-dev] [sahara] client release 0.7.7

2015-02-13 Thread Sergey Lukjanov
Hi folks,

we have a new python-saharaclient release with SSL and indirect access
support, as well as bunch of bug fixes.

https://launchpad.net/python-saharaclient/+milestone/0.7.7

Bump in global requirements: https://review.openstack.org/#/c/155428/

Thanks.

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


Re: [openstack-dev] [sahara] team meeting Feb 12 1400 UTC

2015-02-12 Thread Sergey Lukjanov
Log:
http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-02-12-14.00.txt
Minutes:
http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-02-12-14.00.html

On Thu, Feb 12, 2015 at 1:26 AM, Andrew Lazarev alaza...@mirantis.com
wrote:

 Hi guys,

 We'll be having the Sahara team meeting tomorrow at #openstack-meeting-3
 channel.

 Agenda: https://wiki.openstack.org/wiki/Meetings
 /SaharaAgenda#Next_meetings


 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150212T14

 Thanks,
 Andrew

 __
 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




-- 
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-dev] [stable] expanding sahara maint team

2015-02-12 Thread Sergey Lukjanov
Hi stable maint folks,

I'd like to propose to add the following folks to the sahara stable maint
team:

* Trevor McKay (tmckay)
* Ethan Gafford (egafford)
* Andrew Lazarev (alazarev)
* Sergey Reshetnyak (sreshetniak)

Thanks.

-- 
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-dev] [sahara] team meeting Feb 5 1800 UTC

2015-02-04 Thread Sergey Lukjanov
Hi folks,

We'll be having the Sahara team meeting in #openstack-meeting-alt channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150205T18

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


Re: [openstack-dev] [sahara] team meeting Jan 29 1400 UTC

2015-01-29 Thread Sergey Lukjanov
Log:
http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-01-29-14.04.html
Minutes:
http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-01-29-14.04.log.html

On Wed, Jan 28, 2015 at 6:46 PM, Sergey Lukjanov slukja...@mirantis.com
wrote:

 Hi folks,

 We'll be having the Sahara team meeting in #openstack-meeting-3 channel.

 Agenda:
 https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings


 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150129T14

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




-- 
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-dev] [sahara] team meeting Jan 29 1400 UTC

2015-01-28 Thread Sergey Lukjanov
Hi folks,

We'll be having the Sahara team meeting in #openstack-meeting-3 channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150129T14

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


Re: [openstack-dev] [sahara] Bug fix day Jan 26

2015-01-25 Thread Sergey Lukjanov
Reminder

On Monday, January 19, 2015, Sergey Lukjanov slukja...@mirantis.com wrote:

 Hi Sahara folks,

 we'll have a bug fixing day at Jan 26 starting approximately at 14:00 UTC.
 Let's meet in the #openstack-sahara.

 Thanks.

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



-- 
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-dev] [sahara] team meeting Jan 22 1800 UTC

2015-01-21 Thread Sergey Lukjanov
Hi folks,

We'll be having the Sahara team meeting as usual in
#openstack-meeting-alt channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150122T18

-- 
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-dev] [sahara] Bug fix day Jan 26

2015-01-19 Thread Sergey Lukjanov
Hi Sahara folks,

we'll have a bug fixing day at Jan 26 starting approximately at 14:00 UTC.
Let's meet in the #openstack-sahara.

Thanks.

-- 
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-dev] [sahara] Bug triage day - today, Jan 19

2015-01-19 Thread Sergey Lukjanov
Hey sahara folks,

today (Jan 19) is the bug triage day, starting approximately from 14:00
UTC. Let's meet in the #openstack-sahara channel.

Thanks.

-- 
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-dev] [sahara] team meeting Jan 15 1400 UTC

2015-01-14 Thread Sergey Lukjanov
Hi folks,

We'll be having the Sahara team meeting as usual in
#openstack-meeting-3 channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150115T14

-- 
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-dev] [infra] Infrastrucutre Puppet module split sprint, Jan 28

2015-01-13 Thread Sergey Lukjanov
Hi openstackers,

The OpenStack Infrastructure team will be hosting a virtual sprint in
#openstack-sprint channel at Freenode for the OpenStack Infrastructure
Puppet Module split on January 28th starting at 15:00 UTC and going for 24
hours.
The main goal of this sprint is to work on splitting the rest of the
openstack-infra/system-config puppet modules by proposing new split changes
and review existing ones.

Event info:
https://wiki.openstack.org/wiki/VirtualSprints#OpenStack_puppet_module_split
Specification:
http://specs.openstack.org/openstack-infra/infra-specs/specs/puppet-modules.html
Etherpad: https://etherpad.openstack.org/p/puppet-module-split-sprint

If you're interested in participating this event, please, add yourself to
the etherpad.

Thanks.


-- 
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-dev] [sahara] team meeting Jan 8 1800 UTC

2015-01-08 Thread Sergey Lukjanov
Hi folks,

We'll be having the Sahara team meeting as usual in
#openstack-meeting-alt channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150108T18

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [sahara] no meetings next 2 weeks

2014-12-24 Thread Sergey Lukjanov
Hi sahara folks,

Lets cancel the next two weekly meetings because of Christmas and new years
day.

Thanks

P.S. Happy holidays!

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [sahara] team meeting Dec 18 1400 UTC

2014-12-17 Thread Sergey Lukjanov
Hi folks,

We'll be having the Sahara team meeting in
#openstack-meeting-3 channel.

Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20141218T14

NOTE: It's a new alternate time slot.

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [sahara] team meeting Dec 11 1800 UTC

2014-12-11 Thread Sergey Lukjanov
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-12-11-17.59.html
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-12-11-17.59.log.html

On Wed, Dec 10, 2014 at 6:21 PM, Sergey Lukjanov slukja...@mirantis.com
wrote:

 Hi folks,

 We'll be having the Sahara team meeting as usual in
 #openstack-meeting-alt channel.

 Agenda:
 https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings


 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20141211T18

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




-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


  1   2   3   4   5   6   >