Re: [openstack-dev] [sahara] Nominate Telles Mota Vidal Nóbrega for core team
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
[openstack-dev] [sahara] Bug triage/fix and doc update days in Liberty
Hi folks, on todays IRC meeting [0] we've agreed to have: 1) Bug triage day on Aug 17 We're looking for the volunteer to coordinate it ;) If someone wants to do it, please, reply to this email. http://etherpad.openstack.org/p/sahara-liberty-bug-triage-day 2) Bug fix day on Aug 24 Ethan (egafford) volunteered to coordinate it. http://etherpad.openstack.org/p/sahara-liberty-bug-fix-day 3) Doc update day on Aug 31 Mike (elmiko) volunteered to coordinate it. http://etherpad.openstack.org/p/sahara-liberty-doc-update-day Coordinators, please, add some initial notes to the ether pads and ensure that folks will be using them to sync efforts. For communication let's use #openstack-sahara IRC channel as always. Thanks. [0] http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-08-13-14.00.html -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] Proposing Ethan Gafford for the core reviewer team
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?
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 ?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[openstack-dev] [sahara] HDP2 testing in Sahara CI
Hi folks, we have some issues with testing HDP2 in Sahara CI starting from the weekend, so, please, consider the HDP2 job unstable, but do not approve changes that could directly affect HDP2 plugin with failed job. We're now trying to make it working. Thanks. -- 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
