Re: [openstack-dev] [depfreeze] Dependency freeze coming up (EOD Tuesday March 25)
RE Sahara, we'll need one more version bump to remove all backward compat code added for smooth transition. What's the deadline for doing it? Personally, I'd like to do it next week. Is it ok? Thanks. On Mon, Mar 24, 2014 at 10:41 PM, Doug Hellmann wrote: > > > > On Mon, Mar 24, 2014 at 2:28 PM, Sean Dague wrote: >> >> On 03/24/2014 02:20 PM, Doug Hellmann wrote: >> > >> > >> > >> > On Mon, Mar 24, 2014 at 5:33 AM, Thierry Carrez > > <mailto:thie...@openstack.org>> wrote: >> > >> > Joe Gordon wrote: >> > > There are still two outstanding trove dependencies that are >> > currently >> > > used in trove but not in global requirements. It would be nice to >> > get >> > > this sorted out before the freeze so we can >> > > turn https://review.openstack.org/#/c/80690/ on. >> > > >> > > mockito https://review.openstack.org/#/c/80850/ >> > >> > This one was abandoned. Trove team is "looking to move away from >> > mockito >> > to mock. Timeline is in the next 4-5 days". >> > >> > >> > I was one of several people who objected to that. I would be happy to >> > change my -1 to a +2 if the Trove team needs more time to change. >> > Perhaps as a J1 goal? >> >> The Trove team said last week they could probably land the remove in >> trove this week for mockito (it was on their roadmap anyway). So unless >> they feel that's not doable, I think we're good. > > > Sounds good. > > Doug > > >> >> >> -Sean >> >> -- >> Sean Dague >> Samsung Research America >> s...@dague.net / sean.da...@samsung.com >> http://dague.net >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] We need a new version of hacking for Icehouse, or provide compatibility with oslo.sphinx in oslosphinx
I've created change request to bump min hacking version to 0.8.1 - https://review.openstack.org/82339 On Sat, Mar 22, 2014 at 10:52 AM, Thomas Goirand wrote: > On 03/22/2014 12:58 AM, Joe Gordon wrote: >> >> So it sounds like we need: >> >> * Hacking 0.8.1 to fix the oslo.sphinx oslosphinx issue for Icehouse. >> Since we cap hacking versions at 0.9 [1] this will get used in icehouse. >> * Hacking 0.9 to release all the new hacking goodness. This will be >> targeted for use in Juno. > > I agree with this plan. > > Thomas > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] We need a new version of hacking for Icehouse, or provide compatibility with oslo.sphinx in oslosphinx
++ for having 0.8.1 with oslospinx del fixed. P.S. The 0.9.0 release will find some style issues in mostly all projects I think, so, it's better to release it after Icehouse release or at least RC1. On Fri, Mar 21, 2014 at 8:58 PM, Joe Gordon wrote: > > > > On Fri, Mar 21, 2014 at 8:36 AM, Doug Hellmann > wrote: >> >> There is quite a list of un-released changes to hacking: >> >> * Make H202 check honor pep8 #noqa comment >> * Updated from global requirements >> * Updated from global requirements >> * Switch over to oslosphinx >> * HACKING.rst: Fix odd indentation in an example code >> * Remove tox locale overrides >> * Updated from global requirements >> * Clarify H403 message >> * More portable way to detect modules for H302 >> * Fix python 3 incompatibility in _get_import_type >> * Trigger warnings for raw and unicode docstrings >> * Enhance H233 rule >> * Add check for removed modules in Python 3 >> * Add Python3 deprecated assert* to HACKING.rst >> * Turn Python3 section into a list >> * Re-Add section on assertRaises(Exception >> * Cleanup HACKING.rst >> * Move hacking guide to root directory >> * Fix typo in package summary >> * Add H904: don't wrap lines using a backslash >> * checking for metaclass to be Python 3.x compatible >> * Remove unnecessary headers >> * Add -U to pip install command in tox.ini >> * Fix typos of comment in module core >> * Updated from global requirements >> * Add a check for file with only comments >> * Enforce grouping like imports together >> * Add noqa support for H201 (bare except) >> * Enforce import grouping >> * Clean up how test env variables are parsed >> * Fix the escape character >> * Remove vim modeline sample >> * Add a check for newline after docstring summary >> >> It looks like it might be time for a new release anyway, especially if it >> resolves the packaging issue you describe. > > > > I think two new releases are needed. I have been holding off cutting the > next hacking release until we are closer to Juno. Since the next release > will include new rules I didn't want to distract anyone from focusing on > stabilizing Icehouse. > > So it sounds like we need: > > * Hacking 0.8.1 to fix the oslo.sphinx oslosphinx issue for Icehouse. Since > we cap hacking versions at 0.9 [1] this will get used in icehouse. > * Hacking 0.9 to release all the new hacking goodness. This will be targeted > for use in Juno. > > [1] https://review.openstack.org/#/c/81356/ > > > If this sounds good, I will cut 0.8.1 this afternoon. > >> >> As far as the symlink, I think that's a potentially bad idea. It's only >> going to encourage the continued use of oslo.sphinx. Since the package is >> only needed to build the documentation, and not to actually use the tool, I >> don't think we need the symlink in place, do we? >> >> Doug >> >> >> On Fri, Mar 21, 2014 at 6:17 AM, Thomas Goirand wrote: >>> >>> Hi, >>> >>> The current version of python-hacking wants python-oslo.sphinx, but >>> we're moving to python-oslosphinx. In Debian, I made python-oslo.sphinx >>> as a transition empty package that only depends on python-oslosphinx. As >>> a consequence, python-hacking needs to be updated to use >>> python-oslosphinx, otherwise it wont have available build-dependencies. >>> > > > Thank you for bringing this to our attention, I wonder how we can detect > this in our CI system in the future to prevent this. > >>> >>> I was also thinking about providing a symlink from oslo/sphinx to >>> oslosphinx. Maybe it'd be nice to have this directly in oslosphinx? >>> >>> Thoughts anyone? >>> >>> Cheers, >>> >>> Thomas >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] Canceling team meeting Mar 20 [savanna]
Hi team, I'm canceling team meeting tomorrow, Mar 20, because there will be no quorum - Mirantis team will be unavailable due to the internal company event, Matt F. said that he'll be unavailable too. Thanks. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] Successfully graduated from incubation! [savanna]
Hey folks, I'm glad to announce that we've successfully graduated from incubation and we'll be part of the integrated Juno release! There are no raised issues and concerns while review and it's really important too. You can find graduation review meeting logs [0] and voting [1]. Thank you. [0] http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-03-11-20.03.html [1] https://review.openstack.org/#/c/79766/ -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) 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] python-saharaclient 0.6.0 release [savanna]
python-saharaclient addition change request is under review - https://review.openstack.org/#/c/81083/ On Tue, Mar 18, 2014 at 1:45 PM, Sergey Lukjanov wrote: > Hi folks, > > the first version ofpython-saharaclient has been released. > > The main change is renaming all stuff from savanna to sahara. This > release contains backward compatibility for using it as savanna > client. > > https://launchpad.net/python-saharaclient/0.6.x/0.6.0 > https://pypi.python.org/pypi/python-saharaclient/0.6.0 > http://tarballs.openstack.org/python-saharaclient/python-saharaclient-0.6.0.tar.gz > > Thanks. > > -- > Sincerely yours, > Sergey Lukjanov > Sahara Technical Lead > (OpenStack Data Processing) > Mirantis Inc. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] python-saharaclient 0.6.0 release [savanna]
Hi folks, the first version ofpython-saharaclient has been released. The main change is renaming all stuff from savanna to sahara. This release contains backward compatibility for using it as savanna client. https://launchpad.net/python-saharaclient/0.6.x/0.6.0 https://pypi.python.org/pypi/python-saharaclient/0.6.0 http://tarballs.openstack.org/python-saharaclient/python-saharaclient-0.6.0.tar.gz Thanks. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] Savanna 2014.1.b3 (Icehouse-3) dev milestone available
Thank you! Heh, looking forward for sahara packages for rc1 :) On Sat, Mar 15, 2014 at 12:42 AM, Matthew Farrellee wrote: > On 03/06/2014 04:00 PM, Sergey Lukjanov wrote: >> >> Hi folks, >> >> the third development milestone of Icehouse cycle is now available for >> Savanna. >> >> Here is a list of new features and fixed bug: >> >> https://launchpad.net/savanna/+milestone/icehouse-3 >> >> and here you can find tarballs to download it: >> >> http://tarballs.openstack.org/savanna/savanna-2014.1.b3.tar.gz >> >> http://tarballs.openstack.org/savanna-dashboard/savanna-dashboard-2014.1.b3.tar.gz >> >> http://tarballs.openstack.org/savanna-image-elements/savanna-image-elements-2014.1.b3.tar.gz >> http://tarballs.openstack.org/savanna-extra/savanna-extra-2014.1.b3.tar.gz >> >> There are 20 blueprint implemented, 45 bugs fixed during the >> milestone. It includes savanna, savanna-dashboard, >> savanna-image-element and savanna-extra sub-projects. In addition >> python-savannaclient 0.5.0 that was released early this week supports >> all new features introduced in this savanna release. >> >> Thanks. >> > > rdo packages - > > f21 - savanna - http://koji.fedoraproject.org/koji/taskinfo?taskID=6634141 > el6 - savanna - http://koji.fedoraproject.org/koji/taskinfo?taskID=6634119 > > f21 - python-django-savanna - > http://koji.fedoraproject.org/koji/taskinfo?taskID=6634139 > el6 - python-django-savanna - > http://koji.fedoraproject.org/koji/taskinfo?taskID=6634116 > > best, > > > matt > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) 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 minutes March 13 [savanna]
Heh, we should have a fathomless jar for it :( On Thu, Mar 13, 2014 at 11:30 PM, Matthew Farrellee wrote: > On 03/13/2014 03:24 PM, Jay Pipes wrote: >> >> On Thu, 2014-03-13 at 23:13 +0400, Sergey Lukjanov wrote: >>> >>> Thanks everyone who have joined Savanna meeting. >> >> >> You mean Sahara? :P >> >> -jay > > > sergey now has to put some bitcoins in the jar... > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) 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 minutes March 13 [savanna]
Thanks everyone who have joined Savanna meeting. Here are the logs from the meeting: Minutes: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-03-13-18.04.html Log: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-03-13-18.04.log.html It was decided to not keep backward compatibility for renaming due to the a lot of additional effort needed. We'll discuss the starting date for the full backward compatibility on the next meeting. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead 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 Mar 13 1800 UTC [savanna]
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#Agenda_for_March.2C_13 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20140313T18 The main topic is "Do we need backward compat for renaming?" -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead 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] Sahara (ex. Savanna) project renaming process [savanna]
Blueprint for renaming in docs has been added - https://blueprints.launchpad.net/sahara/+spec/savanna-renaming-docs Erik B. volunteered to cover it, thanks for him. On Wed, Mar 12, 2014 at 6:09 PM, Sergey Lukjanov wrote: > All repos has been renamed, all launchpad projects too, bps/issues > mappings updated too. Additionally, we're ready to start moving to the > new irc channel, I'll make separated announcements for both events. > > On Tue, Mar 11, 2014 at 5:38 PM, Sergey Lukjanov > wrote: >> RE blueprints assignments - it looks like all bps have initial assignments. >> >> On the renaming the main service code side Alex I. is contact person, >> I'll help him with some setup stuff. >> >> Additionally, you can find a bunch of my patches for external renaming >> related changes - >> https://review.openstack.org/#/q/status:open+topic:savanna-sahara+-savanna,n,z >> and internal changes - >> https://review.openstack.org/#/q/status:open+topic:savanna-sahara+savanna,n,z >> (only open changes). >> >> Thanks. >> >> On Tue, Mar 11, 2014 at 5:33 PM, Sergey Lukjanov >> wrote: >>> All launchpad projects has been renamed keeping full path redirects. >>> It means that you can still reference to the bugs and blueprints under >>> the savanna launchpad project and it'll be redirected to the new >>> sahara project. >>> >>> All savanna repositories will be renamed to sahara ones on Wednesday, >>> March 12 between 12:00 to 12:30 UTC [0] >>> >>> >>> [0] >>> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140312T12&am=30 >>> >>> On Sun, Mar 9, 2014 at 3:08 PM, Sergey Lukjanov >>> wrote: >>>> Matt, >>>> >>>> thanks for moving etherpad notes to the blueprints. I've added some >>>> notes and details to them and add some assignments to the blueprints >>>> where we have no choice. >>>> >>>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci - >>>> Sergey Kolekonov >>>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-guestagent >>>> - Dmitry Mescheryakov >>>> >>>> Thanks. >>>> >>>> On Sat, Mar 8, 2014 at 5:08 PM, Matthew Farrellee wrote: >>>>> On 03/07/2014 04:50 PM, Sergey Lukjanov wrote: >>>>>> >>>>>> Hey folks, >>>>>> >>>>>> we're now starting working on the project renaming. You can find >>>>>> details in the etherpad [0]. We'll move all work items to the >>>>>> blueprints, one blueprint per sub-project to well track progress and >>>>>> work items. The general blueprint is [1], it'll depend on all other >>>>>> blueprints and it's currently consists of general renaming tasks. >>>>>> >>>>>> Current plan is to assign each subproject blueprint to volunteer. >>>>>> Please, contact me and Matthew Farrellee if you'd like to take the >>>>>> renaming bp. >>>>>> >>>>>> Please, share your ideas/suggestions in ML or etherpad. >>>>>> >>>>>> [0] https://etherpad.openstack.org/p/savanna-renaming-process >>>>>> [1] >>>>>> https://blueprints.launchpad.net/openstack?searchtext=savanna-renaming >>>>>> >>>>>> Thanks. >>>>>> >>>>>> P.S. Please, prepend email topics with [sahara] and append [savanna] >>>>>> to the end of topic (like in this email) for the transition period. >>>>> >>>>> >>>>> savann^wsahara team, >>>>> >>>>> i've separated out most of the activities that can happen in parallel, >>>>> aligned them on repository boundaries, and filed blueprints for the >>>>> efforts. >>>>> now we need community members to take ownership (be the assignee) of the >>>>> blueprints. taking ownership means you'll be responsible for the renaming >>>>> in >>>>> the repository, coordinating with other owners and getting feedback from >>>>> the >>>>> community about important questions (such as compatibility requirements). >>>>> >>>>> to take ownership, just go to the blueprint and assign it to yourself. if >>>>> there is already an assignee, reach out to that person and offer them
[openstack-dev] [sahara] moving to the #openstack-sahara channel [savanna]
Hi folks, let's start using new IRC channel #openstack-sahara at freenode (let's do it right now). Channel logs are available at eavesdrop [0] and git bot already works ok. **Sahara core team, please, keep looking into the obsolete #savanna channel to help folks moving to the right place.** Thanks. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-sahara/ -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] all git repos / lp projects has been renamed to sahara [savanna]
Hi folks, please, note that all repos has been renamed. You should update your git remotes and gerrit queries. .gitreview updates are on the go. Devstack/Tempest jobs aren't working now waiting to the update in DevStack, I'll make a note when it'll start working. Savanna-ci will be updated soon too. BTW we have redirects from old name to the new one for both github repos and launchpad projects. The same with wiki pages. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead 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] Sahara (ex. Savanna) project renaming process [savanna]
All repos has been renamed, all launchpad projects too, bps/issues mappings updated too. Additionally, we're ready to start moving to the new irc channel, I'll make separated announcements for both events. On Tue, Mar 11, 2014 at 5:38 PM, Sergey Lukjanov wrote: > RE blueprints assignments - it looks like all bps have initial assignments. > > On the renaming the main service code side Alex I. is contact person, > I'll help him with some setup stuff. > > Additionally, you can find a bunch of my patches for external renaming > related changes - > https://review.openstack.org/#/q/status:open+topic:savanna-sahara+-savanna,n,z > and internal changes - > https://review.openstack.org/#/q/status:open+topic:savanna-sahara+savanna,n,z > (only open changes). > > Thanks. > > On Tue, Mar 11, 2014 at 5:33 PM, Sergey Lukjanov > wrote: >> All launchpad projects has been renamed keeping full path redirects. >> It means that you can still reference to the bugs and blueprints under >> the savanna launchpad project and it'll be redirected to the new >> sahara project. >> >> All savanna repositories will be renamed to sahara ones on Wednesday, >> March 12 between 12:00 to 12:30 UTC [0] >> >> >> [0] >> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140312T12&am=30 >> >> On Sun, Mar 9, 2014 at 3:08 PM, Sergey Lukjanov >> wrote: >>> Matt, >>> >>> thanks for moving etherpad notes to the blueprints. I've added some >>> notes and details to them and add some assignments to the blueprints >>> where we have no choice. >>> >>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci - >>> Sergey Kolekonov >>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-guestagent >>> - Dmitry Mescheryakov >>> >>> Thanks. >>> >>> On Sat, Mar 8, 2014 at 5:08 PM, Matthew Farrellee wrote: >>>> On 03/07/2014 04:50 PM, Sergey Lukjanov wrote: >>>>> >>>>> Hey folks, >>>>> >>>>> we're now starting working on the project renaming. You can find >>>>> details in the etherpad [0]. We'll move all work items to the >>>>> blueprints, one blueprint per sub-project to well track progress and >>>>> work items. The general blueprint is [1], it'll depend on all other >>>>> blueprints and it's currently consists of general renaming tasks. >>>>> >>>>> Current plan is to assign each subproject blueprint to volunteer. >>>>> Please, contact me and Matthew Farrellee if you'd like to take the >>>>> renaming bp. >>>>> >>>>> Please, share your ideas/suggestions in ML or etherpad. >>>>> >>>>> [0] https://etherpad.openstack.org/p/savanna-renaming-process >>>>> [1] https://blueprints.launchpad.net/openstack?searchtext=savanna-renaming >>>>> >>>>> Thanks. >>>>> >>>>> P.S. Please, prepend email topics with [sahara] and append [savanna] >>>>> to the end of topic (like in this email) for the transition period. >>>> >>>> >>>> savann^wsahara team, >>>> >>>> i've separated out most of the activities that can happen in parallel, >>>> aligned them on repository boundaries, and filed blueprints for the >>>> efforts. >>>> now we need community members to take ownership (be the assignee) of the >>>> blueprints. taking ownership means you'll be responsible for the renaming >>>> in >>>> the repository, coordinating with other owners and getting feedback from >>>> the >>>> community about important questions (such as compatibility requirements). >>>> >>>> to take ownership, just go to the blueprint and assign it to yourself. if >>>> there is already an assignee, reach out to that person and offer them >>>> assistance. >>>> >>>> blueprints up for grabs - >>>> >>>> what: savanna^wsahara ci >>>> blueprint: >>>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci >>>> comments: this should be taken by someone already familiar with the ci. i'd >>>> nominate skolekonov >>>> >>>> what: saraha puppet modules >>>> blueprint: >>>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-puppet >>>> comments: this should be
[openstack-dev] [sahara] savanna/sahara graduation review [savanna]
Hey folks, please, note that today will be our project graduation review on TC meeting - https://wiki.openstack.org/wiki/Governance/TechnicalCommittee#Meeting Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead 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] Sahara (ex. Savanna) project renaming process [savanna]
RE blueprints assignments - it looks like all bps have initial assignments. On the renaming the main service code side Alex I. is contact person, I'll help him with some setup stuff. Additionally, you can find a bunch of my patches for external renaming related changes - https://review.openstack.org/#/q/status:open+topic:savanna-sahara+-savanna,n,z and internal changes - https://review.openstack.org/#/q/status:open+topic:savanna-sahara+savanna,n,z (only open changes). Thanks. On Tue, Mar 11, 2014 at 5:33 PM, Sergey Lukjanov wrote: > All launchpad projects has been renamed keeping full path redirects. > It means that you can still reference to the bugs and blueprints under > the savanna launchpad project and it'll be redirected to the new > sahara project. > > All savanna repositories will be renamed to sahara ones on Wednesday, > March 12 between 12:00 to 12:30 UTC [0] > > > [0] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140312T12&am=30 > > On Sun, Mar 9, 2014 at 3:08 PM, Sergey Lukjanov > wrote: >> Matt, >> >> thanks for moving etherpad notes to the blueprints. I've added some >> notes and details to them and add some assignments to the blueprints >> where we have no choice. >> >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci - >> Sergey Kolekonov >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-guestagent >> - Dmitry Mescheryakov >> >> Thanks. >> >> On Sat, Mar 8, 2014 at 5:08 PM, Matthew Farrellee wrote: >>> On 03/07/2014 04:50 PM, Sergey Lukjanov wrote: >>>> >>>> Hey folks, >>>> >>>> we're now starting working on the project renaming. You can find >>>> details in the etherpad [0]. We'll move all work items to the >>>> blueprints, one blueprint per sub-project to well track progress and >>>> work items. The general blueprint is [1], it'll depend on all other >>>> blueprints and it's currently consists of general renaming tasks. >>>> >>>> Current plan is to assign each subproject blueprint to volunteer. >>>> Please, contact me and Matthew Farrellee if you'd like to take the >>>> renaming bp. >>>> >>>> Please, share your ideas/suggestions in ML or etherpad. >>>> >>>> [0] https://etherpad.openstack.org/p/savanna-renaming-process >>>> [1] https://blueprints.launchpad.net/openstack?searchtext=savanna-renaming >>>> >>>> Thanks. >>>> >>>> P.S. Please, prepend email topics with [sahara] and append [savanna] >>>> to the end of topic (like in this email) for the transition period. >>> >>> >>> savann^wsahara team, >>> >>> i've separated out most of the activities that can happen in parallel, >>> aligned them on repository boundaries, and filed blueprints for the efforts. >>> now we need community members to take ownership (be the assignee) of the >>> blueprints. taking ownership means you'll be responsible for the renaming in >>> the repository, coordinating with other owners and getting feedback from the >>> community about important questions (such as compatibility requirements). >>> >>> to take ownership, just go to the blueprint and assign it to yourself. if >>> there is already an assignee, reach out to that person and offer them >>> assistance. >>> >>> blueprints up for grabs - >>> >>> what: savanna^wsahara ci >>> blueprint: >>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci >>> comments: this should be taken by someone already familiar with the ci. i'd >>> nominate skolekonov >>> >>> what: saraha puppet modules >>> blueprint: >>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-puppet >>> comments: this should be taken by someone who can validate the changes. i'd >>> nominate sbadia or dizz >>> >>> what: sahara extras >>> blueprint: >>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-extra >>> comments: this could be taken by anyone >>> >>> what: sahara dib image elements >>> blueprint: >>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-image-elements >>> comments: this could be taken by anyone >>> >>> what: sahara python client >>> blueprint: >>> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-client >>> comments: this should b
Re: [openstack-dev] [sahara] Sahara (ex. Savanna) project renaming process [savanna]
All launchpad projects has been renamed keeping full path redirects. It means that you can still reference to the bugs and blueprints under the savanna launchpad project and it'll be redirected to the new sahara project. All savanna repositories will be renamed to sahara ones on Wednesday, March 12 between 12:00 to 12:30 UTC [0] [0] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140312T12&am=30 On Sun, Mar 9, 2014 at 3:08 PM, Sergey Lukjanov wrote: > Matt, > > thanks for moving etherpad notes to the blueprints. I've added some > notes and details to them and add some assignments to the blueprints > where we have no choice. > > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci - > Sergey Kolekonov > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-guestagent > - Dmitry Mescheryakov > > Thanks. > > On Sat, Mar 8, 2014 at 5:08 PM, Matthew Farrellee wrote: >> On 03/07/2014 04:50 PM, Sergey Lukjanov wrote: >>> >>> Hey folks, >>> >>> we're now starting working on the project renaming. You can find >>> details in the etherpad [0]. We'll move all work items to the >>> blueprints, one blueprint per sub-project to well track progress and >>> work items. The general blueprint is [1], it'll depend on all other >>> blueprints and it's currently consists of general renaming tasks. >>> >>> Current plan is to assign each subproject blueprint to volunteer. >>> Please, contact me and Matthew Farrellee if you'd like to take the >>> renaming bp. >>> >>> Please, share your ideas/suggestions in ML or etherpad. >>> >>> [0] https://etherpad.openstack.org/p/savanna-renaming-process >>> [1] https://blueprints.launchpad.net/openstack?searchtext=savanna-renaming >>> >>> Thanks. >>> >>> P.S. Please, prepend email topics with [sahara] and append [savanna] >>> to the end of topic (like in this email) for the transition period. >> >> >> savann^wsahara team, >> >> i've separated out most of the activities that can happen in parallel, >> aligned them on repository boundaries, and filed blueprints for the efforts. >> now we need community members to take ownership (be the assignee) of the >> blueprints. taking ownership means you'll be responsible for the renaming in >> the repository, coordinating with other owners and getting feedback from the >> community about important questions (such as compatibility requirements). >> >> to take ownership, just go to the blueprint and assign it to yourself. if >> there is already an assignee, reach out to that person and offer them >> assistance. >> >> blueprints up for grabs - >> >> what: savanna^wsahara ci >> blueprint: >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci >> comments: this should be taken by someone already familiar with the ci. i'd >> nominate skolekonov >> >> what: saraha puppet modules >> blueprint: >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-puppet >> comments: this should be taken by someone who can validate the changes. i'd >> nominate sbadia or dizz >> >> what: sahara extras >> blueprint: >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-extra >> comments: this could be taken by anyone >> >> what: sahara dib image elements >> blueprint: >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-image-elements >> comments: this could be taken by anyone >> >> what: sahara python client >> blueprint: >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-client >> comments: this should be done by someone w/ experience in the client. i'd >> nominate tmckay >> >> what: sahara horizon plugin >> blueprint: >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-dashboard >> comments: this will require experience and care. i'd nominate croberts >> >> what: sahara guestagent >> blueprint: >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-guestagent >> comments: i'd nominate dmitrymex >> >> what: sahara section of openstack wiki >> blueprint: >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-wiki >> comments: this could be taken by anyone >> >> what: sahara service >> blueprint: >> https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-service >> comments: this requires experience, care and is a lot of work. i'd nominate >> alazarev & aignatov to tag team it >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead 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] Prefix for -dev mailing list [savanna]
NOTE. We have a mailman topic for Sahara that accepts both sahara and savanna, so people interested only in receiving messages with "[sahara]" and/or "[savanna]" in the subject line can subscribe to the topic only. How to use Mailman topics: http://www.gnu.org/software/mailman/mailman-member/node31.html http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev/YOUR-EMAIL to edit topics subscriptions. Thanks for Stef for updating mailman topic. On Sun, Mar 9, 2014 at 3:05 PM, Sergey Lukjanov wrote: > Hey folks, > > please, note, that we should prepend mail subject with "[sahara]" and > append "[savanna]" to the end for transition period. > > Thanks. > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] Rename Hortonworks hosted resources [savanna]
Hey Erik, John, Due to the project renaming, could you, please, rename all resources hosted on Hortonworks CDN? Thanks. P.S. Looks like we have such urls in main savanna repo and dib elements at least. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead 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] Sahara (ex. Savanna) project renaming process [savanna]
Hey Swapnil, thanks for the note. This name was checked by the OpenStack Foundation lawyers, so, I think that they decided that there's no potential issues with this company. FYI we're renaming Savanna because they find http://thetus.com/savanna that's Hadoop-backed analytics on cloud (the same area as our project). I'll ask lawyers about this to be sure. Thanks. On Sun, Mar 9, 2014 at 4:16 AM, Swapnil Kulkarni wrote: > Hey guys, > > Sahara is a known corporate group in India, wanted to bring it up before > renaming starts. > > [1] https://www.google.co.in/search?q=sahara+group > [2] http://www.sahara.in/ > [3] http://www.sahara-group.com/ > > Best Regards, > Swapnil Kulkarni > irc : coolsvap > > > On Sat, Mar 8, 2014 at 3:20 AM, Sergey Lukjanov > wrote: >> >> Hey folks, >> >> we're now starting working on the project renaming. You can find >> details in the etherpad [0]. We'll move all work items to the >> blueprints, one blueprint per sub-project to well track progress and >> work items. The general blueprint is [1], it'll depend on all other >> blueprints and it's currently consists of general renaming tasks. >> >> Current plan is to assign each subproject blueprint to volunteer. >> Please, contact me and Matthew Farrellee if you'd like to take the >> renaming bp. >> >> Please, share your ideas/suggestions in ML or etherpad. >> >> [0] https://etherpad.openstack.org/p/savanna-renaming-process >> [1] https://blueprints.launchpad.net/openstack?searchtext=savanna-renaming >> >> Thanks. >> >> P.S. Please, prepend email topics with [sahara] and append [savanna] >> to the end of topic (like in this email) for the transition period. >> >> -- >> Sincerely yours, >> Sergey Lukjanov >> Savanna Technical Lead >> Mirantis Inc. >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead 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] Sahara (ex. Savanna) project renaming process [savanna]
Matt, thanks for moving etherpad notes to the blueprints. I've added some notes and details to them and add some assignments to the blueprints where we have no choice. https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci - Sergey Kolekonov https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-guestagent - Dmitry Mescheryakov Thanks. On Sat, Mar 8, 2014 at 5:08 PM, Matthew Farrellee wrote: > On 03/07/2014 04:50 PM, Sergey Lukjanov wrote: >> >> Hey folks, >> >> we're now starting working on the project renaming. You can find >> details in the etherpad [0]. We'll move all work items to the >> blueprints, one blueprint per sub-project to well track progress and >> work items. The general blueprint is [1], it'll depend on all other >> blueprints and it's currently consists of general renaming tasks. >> >> Current plan is to assign each subproject blueprint to volunteer. >> Please, contact me and Matthew Farrellee if you'd like to take the >> renaming bp. >> >> Please, share your ideas/suggestions in ML or etherpad. >> >> [0] https://etherpad.openstack.org/p/savanna-renaming-process >> [1] https://blueprints.launchpad.net/openstack?searchtext=savanna-renaming >> >> Thanks. >> >> P.S. Please, prepend email topics with [sahara] and append [savanna] >> to the end of topic (like in this email) for the transition period. > > > savann^wsahara team, > > i've separated out most of the activities that can happen in parallel, > aligned them on repository boundaries, and filed blueprints for the efforts. > now we need community members to take ownership (be the assignee) of the > blueprints. taking ownership means you'll be responsible for the renaming in > the repository, coordinating with other owners and getting feedback from the > community about important questions (such as compatibility requirements). > > to take ownership, just go to the blueprint and assign it to yourself. if > there is already an assignee, reach out to that person and offer them > assistance. > > blueprints up for grabs - > > what: savanna^wsahara ci > blueprint: > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-ci > comments: this should be taken by someone already familiar with the ci. i'd > nominate skolekonov > > what: saraha puppet modules > blueprint: > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-puppet > comments: this should be taken by someone who can validate the changes. i'd > nominate sbadia or dizz > > what: sahara extras > blueprint: > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-extra > comments: this could be taken by anyone > > what: sahara dib image elements > blueprint: > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-image-elements > comments: this could be taken by anyone > > what: sahara python client > blueprint: > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-client > comments: this should be done by someone w/ experience in the client. i'd > nominate tmckay > > what: sahara horizon plugin > blueprint: > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-dashboard > comments: this will require experience and care. i'd nominate croberts > > what: sahara guestagent > blueprint: > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-guestagent > comments: i'd nominate dmitrymex > > what: sahara section of openstack wiki > blueprint: > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-wiki > comments: this could be taken by anyone > > what: sahara service > blueprint: > https://blueprints.launchpad.net/savanna/+spec/savanna-renaming-service > comments: this requires experience, care and is a lot of work. i'd nominate > alazarev & aignatov to tag team it > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] Prefix for -dev mailing list [savanna]
Hey folks, please, note, that we should prepend mail subject with "[sahara]" and append "[savanna]" to the end for transition period. Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] Sahara (ex. Savanna) project renaming process [savanna]
Hey folks, we're now starting working on the project renaming. You can find details in the etherpad [0]. We'll move all work items to the blueprints, one blueprint per sub-project to well track progress and work items. The general blueprint is [1], it'll depend on all other blueprints and it's currently consists of general renaming tasks. Current plan is to assign each subproject blueprint to volunteer. Please, contact me and Matthew Farrellee if you'd like to take the renaming bp. Please, share your ideas/suggestions in ML or etherpad. [0] https://etherpad.openstack.org/p/savanna-renaming-process [1] https://blueprints.launchpad.net/openstack?searchtext=savanna-renaming Thanks. P.S. Please, prepend email topics with [sahara] and append [savanna] to the end of topic (like in this email) for the transition period. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting minutes March 6
Thanks everyone who have joined Savanna meeting. Here are the logs from the meeting: Minutes: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-03-06-18.02.html Log: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-03-06-18.02.log.html It was decided to rename project to Sahara due to the potential trademark issues. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] asymmetric gating and stable vs unstable tests
Hey Deva, It really could be a huge issue for incubated projects. I have now good ideas about how to solve it... One of the bad ideas is that we could extend jenkins success message to include note that will be visible even if comment isn't expanded. Or post separated comment like "Please, note that following jobs marked as stable and, please, treat their failure"... On Fri, Feb 28, 2014 at 12:52 AM, Devananda van der Veen wrote: > Hi all, > > I'd like to point out how asymmetric gating is challenging for incubated > projects, and propose that there may be a way to make it less so. > > For reference, incubated projects aren't allowed to have symmetric gating > with integrated projects. This is why our devstack and tempest tests are > "*-check-nv" in devstack and tempest, but "*-check" and "*-gate" in our > pipeline. So, these jobs are stable from Ironic's point of view because > we've been gating on them for the last month. > > Cut forward to this morning. A devstack patch [1] was merged and broke > Ironic's gate because of a one-line issue in devstack/lib/ironic which I've > since proposed a fix for [2]. This issue was visible in the non-voting check > results before the patch was approved -- but those non-voting checks got > ignored because of an assumption of instability (they must be non-voting for > a reason, right?). > > I'm not suggesting we gate integrated projects on incubated projects, but I > would like to point out that not all non-voting checks are non-voting > *because they're unstable*. It would be great if there were a way to > indicate that certain tests are voting for someone else and a failure > actually matters to them. > > Thanks for listening, > -Deva > > > [1] https://review.openstack.org/#/c/71996/ > > [2] https://review.openstack.org/#/c/76943/ -- It's been approved already, > just waiting in the merge queue ... > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [[savanna] Design Summit session suggestions
Hey Sahara (Savanna) folks , Design Summit session suggestions now open, so, please, add topics you'd like to discuss on summit. More info [0]. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-March/029319.html -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Session suggestions for the Juno Design Summit now open
Hi Thierry, thanks for opening sessions suggestions for Design Summit. Could you, please, rename Savanna topic to "Sahara (ex. Savanna)"? On Fri, Mar 7, 2014 at 1:17 PM, Thierry Carrez wrote: > Hi everyone, > > TL;DR: > The session suggestion website for the Juno Design Summit (which will > happen at the OpenStack Summit in Atlanta) is now open at: > http://summit.openstack.org/ > > Long version: > > The "Juno Design Summit" is a specific event part of the overall > "OpenStack Summit" in Atlanta. It is different from classic tracks in > a number of ways. > > * It starts on Tuesday morning and ends on Friday evening. > > * There are *no formal presentations or speakers*. The sessions at the > design summit are open discussions between contributors on a specific > development topic for the upcoming development cycle, generally > moderated by the PTL or the person who proposed the session. While it is > possible to prepare a few slides to introduce the current status and > kick-off the discussion, these should never be formal > speaker-to-audience presentations. If that's what you're after, the > presentations in the other tracks of the OpenStack Summit are for you. > > * There is no community voting on the content. The Juno Design Summit is > split into multiple topics (one for each official OpenStack Program), > and the elected program PTL will be ultimately responsible for selecting > the content he deems important for the upcoming cycle. If you want to be > PTL in place of the PTL, we'll be holding elections for that in the > coming weeks :) > > With all this in mind, please feel free to suggest topics of discussion > for this event. The website to do this is open at: > > http://summit.openstack.org/ > > You'll need to go through Launchpad SSO to log on that site (same auth > we use for review.openstack.org and all our core development > infrastructure). If you're lost, try the Help link at the bottom of the > page. If all else fails, send me an email. > > Please take extra care when selecting the topic your suggestion belongs > in. You can see the complete list of topics at: > > https://wiki.openstack.org/wiki/Summit/Juno > > We have two *new* categories this time around: > > "Cross-project workshops" > Those will be used to discuss topics which affect all OpenStack > projects, and therefore increase convergence and collaboration across > program barriers. > > "Other projects" > Those will let unofficial, OpenStack-related, open source projects to > have a design discussion within the Design Summit area. We'll limit this > to one session per project to give room to as many projects as possible. > > You have until *April 20* to suggest sessions. Proposed session topics > will be reviewed by PTLs afterwards, potentially merged with other > suggestions before being scheduled. > > You can also comment on proposed sessions to suggest scheduling > constraints or sessions it could be merged with. > > More information about the Juno Design Summit can be found at: > https://wiki.openstack.org/wiki/Summit > > Cheers, > > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] Feature Freeze and end of the I cycle
I'd like to add that we should concentrate on testing and bug fixing for the next several weeks. This period will include project renaming too... The release-critical bugs will be tracked on the icehouse-rc1 [0] milestone pages. When all such issues will be fixed the first release candidate will be released and development (master branch) will be open for Juno dev. Final coordinated release is expected on April 17th. You can find more details about OpenStack devcycle in [1]. [0] https://launchpad.net/savanna/+milestone/icehouse-rc1 [1] https://wiki.openstack.org/wiki/Release_Cycle Thanks. On Fri, Mar 7, 2014 at 2:00 AM, Sergey Lukjanov wrote: > Hi Savanna folks, > > Feature Freeze (FF) for Savanna is now in effect. Feature Freeze > Exceptions (FFE) allowed and could be approved by me as the PTL. So, > for now there are several things that we could land till the RC1: > > * project rename; > * unit / integration tests addition; > * docs addition / improvement; > * fixes / improvements for Hadoop 2 support in all three plugins - > Vanilla, HDP and IDH due to the fact that this changes are > self-contained, it doesn't include any refactoring of code outside of > the plugins. > > Re plans for the end of cycle - we should rename our project till the > first RC. Here is schedule - > https://wiki.openstack.org/wiki/Icehouse_Release_Schedule. Due to the > some potential issues with renaming, we'll probably postpone first RC > for one week. > > P.S. Note for the savanna-core team: please, don't approve changes > that aren't fits FFE'd features. > P.P.S. There is an awesome explanation of why and how we're FF - > http://fnords.wordpress.com/2014/03/06/why-we-do-feature-freeze/. > > Thanks. > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] renaming: final decision
Hi, I'm glad to announce that we select the new name for project - Sahara. It was checked by Foundation Lawyers and we've voted for it on the last team meeting[0]. The first Release Candidate for Savanna in Icehouse should be already named Sahara. We're planning to start renaming in this weekend. I'll share more detailed doc with renaming plan later. [0] http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-03-06-18.02.html Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] Feature Freeze and end of the I cycle
Hi Savanna folks, Feature Freeze (FF) for Savanna is now in effect. Feature Freeze Exceptions (FFE) allowed and could be approved by me as the PTL. So, for now there are several things that we could land till the RC1: * project rename; * unit / integration tests addition; * docs addition / improvement; * fixes / improvements for Hadoop 2 support in all three plugins - Vanilla, HDP and IDH due to the fact that this changes are self-contained, it doesn't include any refactoring of code outside of the plugins. Re plans for the end of cycle - we should rename our project till the first RC. Here is schedule - https://wiki.openstack.org/wiki/Icehouse_Release_Schedule. Due to the some potential issues with renaming, we'll probably postpone first RC for one week. P.S. Note for the savanna-core team: please, don't approve changes that aren't fits FFE'd features. P.P.S. There is an awesome explanation of why and how we're FF - http://fnords.wordpress.com/2014/03/06/why-we-do-feature-freeze/. Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] Savanna 2014.1.b3 (Icehouse-3) dev milestone available
Hi folks, the third development milestone of Icehouse cycle is now available for Savanna. Here is a list of new features and fixed bug: https://launchpad.net/savanna/+milestone/icehouse-3 and here you can find tarballs to download it: http://tarballs.openstack.org/savanna/savanna-2014.1.b3.tar.gz http://tarballs.openstack.org/savanna-dashboard/savanna-dashboard-2014.1.b3.tar.gz http://tarballs.openstack.org/savanna-image-elements/savanna-image-elements-2014.1.b3.tar.gz http://tarballs.openstack.org/savanna-extra/savanna-extra-2014.1.b3.tar.gz There are 20 blueprint implemented, 45 bugs fixed during the milestone. It includes savanna, savanna-dashboard, savanna-image-element and savanna-extra sub-projects. In addition python-savannaclient 0.5.0 that was released early this week supports all new features introduced in this savanna release. Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Feature freeze + Icehouse-3 milestone candidates available
Savanna milestone cut: http://tarballs.openstack.org/savanna/savanna-milestone-proposed.tar.gz https://git.openstack.org/cgit/openstack/savanna/log/?h=milestone-proposed On Thu, Mar 6, 2014 at 1:19 PM, Thierry Carrez wrote: > Thierry Carrez wrote: >> We just hit feature freeze, so please do not approve changes that add >> features or new configuration options unless those have been granted a >> feature freeze exception. >> >> This is also string freeze, so you should avoid changing translatable >> strings. If you have to modify a translatable string, you should give a >> heads-up to the I18N team. >> [...] > > And a shameless plug, for those asking what Feature freeze is about and > how Feature freeze exceptions are granted: > > http://fnords.wordpress.com/2014/03/06/why-we-do-feature-freeze/ > > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting Mar 6 1800 UTC
Hi folks, We'll be having the Savanna team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_March.2C_6 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20140306T18 -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal to move from Freenode to OFTC
++, OFTC looks nice. On Tue, Mar 4, 2014 at 3:31 PM, Daniel P. Berrange wrote: > On Tue, Mar 04, 2014 at 11:12:13AM +, Stephen Gran wrote: >> On 04/03/14 11:01, Thierry Carrez wrote: >> >James E. Blair wrote: >> >>Freenode has been having a rough time lately due to a series of DDoS >> >>attacks which have been increasingly disruptive to collaboration. >> >>Fortunately there's an alternative. >> >> >> >>OFTC http://www.oftc.net/> is a robust and established alternative >> >>to Freenode. It is a smaller network whose mission statement makes it a >> >>less attractive target. It's significantly more stable than Freenode >> >>and has friendly and responsive operators. The infrastructure team has >> >>been exploring this area and we think OpenStack should move to using >> >>OFTC. >> > >> >There is quite a bit of literature out there pointing to Freenode, like >> >presentation slides from old conferences. We should expect people to >> >continue to join Freenode's channels forever. I don't think staying a >> >few weeks on those channels to redirect misled people will be nearly >> >enough. Could we have a longer plan ? Like advertisement bots that would >> >advise every n hours to join the right servers ? >> >> Why not just set /topic to tell people to connect to OFTC and join there? > > That's certainly something you want todo, but IME of moving IRC channels > in the past, plenty of people will never look at the #topic :-( You want > to be more aggressive like setting channel permissions to block anyone > except admins from speaking in the channel. Then set a bot with admin > rights to spam the channel once an hour telling people to go elsewhere. > > Regards, > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] support tracker moved to ask.o.o (ex. answers@launchpad)
Hi Savanna folks, All answers moved to the https://ask.openstack.org (thanks for Stef!) and ask.launchpad.net is now disabled. So, all new questions should be placed to the new site. Please, subscribe to the new support tracker. Savanna-related questions: https://ask.openstack.org/en/questions/tags:savanna/ Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][swift] Importing Launchpad Answers in Ask OpenStack
Stef, thank you! LP answers closed for Savanna too. On Tue, Mar 4, 2014 at 4:22 AM, John Dickinson wrote: > Thanks for doing this, Stef. I've closed LP answers for Swift. All new > questions should go to ask.openstack.org > > --John > > > > On Mar 3, 2014, at 3:26 PM, Stefano Maffulli wrote: > >> And we're done! >> >> All questions and answers on Launchpad Answers have been imported in Ask >> OpenStack >> >> Check it out, there are now almost 6,000 questions on >> https://ask.openstack.org/en/questions/ >> >> I realized that contrary to what I thought, I can't edit most of the >> Launchpad projects to close Answers. I'll contact the PTLs to edit the >> projects. >> >> Cheers, >> stef >> >> >> On 01/28/2014 04:38 PM, Stefano Maffulli wrote: >>> Hello folks >>> >>> we're almost ready to import all questions and asnwers from LP Answers >>> into Ask OpenStack. You can see the result of the import from Nova on >>> the staging server http://ask-staging.openstack.org/ >>> >>> There are some formatting issues for the imported questions and I'm >>> trying to evaluate how bad these are. The questions I see are mostly >>> readable and definitely pop up in search results, with their answers so >>> they are valuable already as is. Some parts, especially the logs, may >>> not look as good though. Fixing the parsers and get a better rendering >>> for all imported questions would take an extra 3-5 days of work (maybe >>> more) and I'm not sure it's worth it. >>> >>> Please go ahead and browse the staging site and let me know what you think. >>> >>> Cheers, >>> stef >>> >> >> -- >> Ask and answer questions on https://ask.openstack.org >> >> _______ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] client 0.5.0 release
Hey Matt,
that's awesome, thank you!
Heh, we need someone how'd like to setup packages for Ubuntu ;)
On Sat, Mar 1, 2014 at 7:23 PM, Matthew Farrellee wrote:
> builds for fedora rawhide and epel6 -
>
> rawhide - http://koji.fedoraproject.org/koji/taskinfo?taskID=6582748
> epel6 - http://koji.fedoraproject.org/koji/taskinfo?taskID=6582798
>
>
> On 02/25/2014 03:50 PM, Sergey Lukjanov wrote:
>>
>> Hi folks,
>>
>> I'm glad to announce that python-savannaclient v0.5.0 released!
>>
>> pypi: https://pypi.python.org/pypi/python-savannaclient/0.5.0
>> tarball:
>> http://tarballs.openstack.org/python-savannaclient/python-savannaclient-0.5.0.tar.gz
>> launchpad: https://launchpad.net/python-savannaclient/0.5.x/0.5.0
>>
>> Notes:
>>
>> * it's first release with CLI covers mostly all features;
>> * dev docs moved to client from the main repo;
>> * support for all new Savanna features introduced in Icehouse release
>> cycle;
>> * single common entrypoint, actual - savannaclient.client.Client('1.1);
>> * auth improvements;
>> * base resource class improvements;
>> * 93 commits from the prev. release.
>>
>> Thanks.
>>
>> On Thu, Feb 20, 2014 at 3:53 AM, Sergey Lukjanov
>> wrote:
>>>
>>> Additionally, it contains support for the latest EDP features.
>>>
>>>
>>> On Thu, Feb 20, 2014 at 3:52 AM, Sergey Lukjanov
>>> wrote:
>>>>
>>>>
>>>> Hi folks,
>>>>
>>>> I'd like to make a 0.5.0 release of savanna client soon, please, share
>>>> your thoughts about stuff that should be included to it.
>>>>
>>>> Currently we have the following major changes/fixes:
>>>>
>>>> * mostly implemented CLI;
>>>> * unified entry point for python bindings like other OpenStack clients;
>>>> * auth improvements;
>>>> * base resource class improvements.
>>>>
>>>> Full diff:
>>>> https://github.com/openstack/python-savannaclient/compare/0.4.1...master
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> Sincerely yours,
>>>> Sergey Lukjanov
>>>> Savanna Technical Lead
>>>> Mirantis Inc.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sincerely yours,
>>> Sergey Lukjanov
>>> Savanna Technical Lead
>>> Mirantis Inc.
>>
>>
>>
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra] openstack_citest MySQL user privileges to create databases on CI nodes
Slave images are auto rebuilt daily, so, probably, it's not happens yet for all providers. Anyway I see the following in nodepool logs: 2014-02-28 02:24:09,255 INFO nodepool.image.build.rax-ord.bare-precise: [0;36mnotice: /Stage[main]/Jenkins::Slave/Mysql::Db[openstack_citest]/Database_grant[openstack_citest@localhost/openstack_citest]/privileges: privileges changed '' to 'all'[0m On Fri, Feb 28, 2014 at 12:28 PM, Roman Podoliaka wrote: > Hi Clark, all, > > https://review.openstack.org/#/c/76634/ has been merged, but I still > get 'command denied' errors [1]. > > Is there something else, that must be done before we can use new > privileges of openstack_citest user? > > Thanks, > Roman > > [1] > http://logs.openstack.org/63/74963/4/check/gate-oslo-incubator-python27/e115a5f/console.html > > On Wed, Feb 26, 2014 at 11:54 AM, Roman Podoliaka > wrote: >> Hi Clark, >> >>>>> I think we can safely GRANT ALL on *.* to openstack_citest@localhost and >>>>> call that good enough >> Works for me. >> >> Thanks, >> Roman >> >> On Tue, Feb 25, 2014 at 8:29 PM, Clark Boylan wrote: >>> On Tue, Feb 25, 2014 at 2:33 AM, Roman Podoliaka >>> wrote: >>>> Hi all, >>>> >>>> [1] made it possible for openstack_citest MySQL user to create new >>>> databases in tests on demand (which is very useful for parallel >>>> running of tests on MySQL and PostgreSQL, thank you, guys!). >>>> >>>> Unfortunately, openstack_citest user can only create tables in the >>>> created databases, but not to perform SELECT/UPDATE/INSERT queries. >>>> Please see the bug [2] filed by Joshua Harlow. >>>> >>>> In PostgreSQL the user who creates a database, becomes the owner of >>>> the database (and can do everything within this database), and in >>>> MySQL we have to GRANT those privileges explicitly. But >>>> openstack_citest doesn't have the permission to do GRANT (even on its >>>> own databases). >>>> >>>> I think, we could overcome this issue by doing something like this >>>> while provisioning a node: >>>> GRANT ALL on `some_predefined_prefix_goes_here\_%`.* to >>>> 'openstack_citest'@'localhost'; >>>> >>>> and then create databases giving them names starting with the prefix value. >>>> >>>> Is it an acceptable solution? Or am I missing something? >>>> >>>> Thanks, >>>> Roman >>>> >>>> [1] https://review.openstack.org/#/c/69519/ >>>> [2] https://bugs.launchpad.net/openstack-ci/+bug/1284320 >>>> >>>> ___ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> The problem with the prefix approach is it doesn't scale. At some >>> point we will decide we need a new prefix then a third and so on >>> (which is basically what happened at the schema level). That said we >>> recently switched to using single use slaves for all unittesting so I >>> think we can safely GRANT ALL on *.* to openstack_citest@localhost and >>> call that good enough. This should work fine for upstream testing but >>> may not be super friendly to others using the puppet manifests on >>> permanent slaves. We can wrap the GRANT in a condition in puppet that >>> is set only on single use slaves if this is a problem. >>> >>> Clark >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] floating ip pool by name
We can add support for network names on the client / dashboard level as an UX enhancement. Client name resolving code sounds mostly useful. On Fri, Feb 28, 2014 at 11:43 AM, Alexander Ignatov wrote: > Andrew, > > This change was needed to heat engine. In case when heat engine and neutron > env are used Heat stacks fails with 'Bad network UUID error'. > This happen because neutron client can't work with networks by names. So > checking network IDs at the validation stage prevents from stack fails and > cluster errors. Also savanna expects IDs for all resources used during > cluster creation (flavors, images etc). Now there are networks. > > Regards, > Alexander Ignatov > > > > On 28 Feb 2014, at 04:09, Andrew Lazarev wrote: > > Hi Team, > > I was always using <"floating_ip_pool": "net04_ext"> construction and it > worked fine. Now it responds with validation error "Floating IP pool > net04_ext for node group 'manager' not found" because > https://bugs.launchpad.net/savanna/+bug/1282027 was merged and savanna > expects only ID here. Is it intentional restriction? What is the reasoning? > Referencing by name is comfortable. > > Thanks, > Andrew. > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting minutes Feb 27
Thanks everyone who have joined Savanna meeting. Here are the logs from the meeting: Minutes: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-02-27-18.01.html Log: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-02-27-18.01.log.html -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] heads up, set -o errexit on devstack - things will fail earlier now
And a big +1 from me too. It's really useful. On Fri, Feb 28, 2014 at 12:15 AM, Devananda van der Veen wrote: > Thu, Feb 27, 2014 at 9:34 AM, Ben Nemec wrote: >> >> On 2014-02-27 09:23, Daniel P. Berrange wrote: >>> >>> On Thu, Feb 27, 2014 at 08:38:22AM -0500, Sean Dague wrote: >>>> >>>> This patch is coming through the gate this morning - >>>> https://review.openstack.org/#/c/71996/ >>>> >>>> The point being to actually make devstack stop when it hits an error, >>>> instead of only once these compound to the point where there is no >>>> moving forward and some service call fails. This should *dramatically* >>>> improve the experience of figuring out a failure in the gate, because >>>> where it fails should be the issue. (It also made us figure out some >>>> wonkiness with stdout buffering, that was making debug difficult). >>>> >>>> This works on all the content that devstack gates against. However, >>>> there are a ton of other paths in devstack, including vendor plugins, >>>> which I'm sure aren't clean enough to run under -o errexit. So if all of >>>> a sudden things start failing, this may be why. Fortunately you'll be >>>> pointed at the exact point of the fail. >>> >>> >>> This is awesome! >> >> >> +1! Thanks Sean and everyone else who was involved with this. > > > Another big +1 for this! I've wished for it every time I tried to add > something to devstack and struggled with debugging it. > > -Deva > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting Feb 27 1800 UTC
Hi folks, We'll be having the Savanna team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_February.2C_27 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20140227T18 The main topics are project renaming and Icehouse 3 dev milestone. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Savanna graduation status
Hi folks, I'd like to follow-up Savanna graduation status. All requirements listed in the [0] has been solved. You can find details in [1]. So, I'd like to ask for Savanna graduation review topic addition to the TC meetings backlog. :) All questions raised on the incubation review were covered on the mid graduation review. There was no new questions/concerns raised on the mid graduation review except the diversity that is currently significantly better than 2 month ago and especially than in the time of incubation review. You can find more details about it in the etherpad. Thanks. [0] http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements#n58 [1] https://etherpad.openstack.org/p/savanna-graduation-status -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] Documentation update for IceHouse
Hey Ruslan, thanks for catching this. So, the plan for updating this docs is to make it during the i3 - rc1 time range, no FFE needed for docs. Thanks P.S. I'm taking tempest tests section. On Sat, Feb 22, 2014 at 4:50 PM, Ruslan Kamaldinov wrote: > As it was decided on our latest meeting I've added a new blueprint for > documentation updates: > https://blueprints.launchpad.net/savanna/+spec/update-docs-icehouse > > Here is a list of work items I've proposed: > * Update installation guide > * Setup development environment > * Devstack guide > * Tempest tests for Savanna > * DIB instructions > * Replace github with git.o.o > * How-to add a new migration script > * Update rest-api docs > > > Please, feel free to add new work items or assign them to yourself. > > Thanks, > Ruslan > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] client 0.5.0 release
Will be available in global requirements after merging
https://review.openstack.org/76357.
On Wed, Feb 26, 2014 at 12:50 AM, Sergey Lukjanov
wrote:
> Hi folks,
>
> I'm glad to announce that python-savannaclient v0.5.0 released!
>
> pypi: https://pypi.python.org/pypi/python-savannaclient/0.5.0
> tarball:
> http://tarballs.openstack.org/python-savannaclient/python-savannaclient-0.5.0.tar.gz
> launchpad: https://launchpad.net/python-savannaclient/0.5.x/0.5.0
>
> Notes:
>
> * it's first release with CLI covers mostly all features;
> * dev docs moved to client from the main repo;
> * support for all new Savanna features introduced in Icehouse release cycle;
> * single common entrypoint, actual - savannaclient.client.Client('1.1);
> * auth improvements;
> * base resource class improvements;
> * 93 commits from the prev. release.
>
> Thanks.
>
> On Thu, Feb 20, 2014 at 3:53 AM, Sergey Lukjanov
> wrote:
>> Additionally, it contains support for the latest EDP features.
>>
>>
>> On Thu, Feb 20, 2014 at 3:52 AM, Sergey Lukjanov
>> wrote:
>>>
>>> Hi folks,
>>>
>>> I'd like to make a 0.5.0 release of savanna client soon, please, share
>>> your thoughts about stuff that should be included to it.
>>>
>>> Currently we have the following major changes/fixes:
>>>
>>> * mostly implemented CLI;
>>> * unified entry point for python bindings like other OpenStack clients;
>>> * auth improvements;
>>> * base resource class improvements.
>>>
>>> Full diff:
>>> https://github.com/openstack/python-savannaclient/compare/0.4.1...master
>>>
>>> Thanks.
>>>
>>> --
>>> Sincerely yours,
>>> Sergey Lukjanov
>>> Savanna Technical Lead
>>> Mirantis Inc.
>>
>>
>>
>>
>> --
>> Sincerely yours,
>> Sergey Lukjanov
>> Savanna Technical Lead
>> Mirantis Inc.
>
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
--
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] client 0.5.0 release
Hi folks,
I'm glad to announce that python-savannaclient v0.5.0 released!
pypi: https://pypi.python.org/pypi/python-savannaclient/0.5.0
tarball:
http://tarballs.openstack.org/python-savannaclient/python-savannaclient-0.5.0.tar.gz
launchpad: https://launchpad.net/python-savannaclient/0.5.x/0.5.0
Notes:
* it's first release with CLI covers mostly all features;
* dev docs moved to client from the main repo;
* support for all new Savanna features introduced in Icehouse release cycle;
* single common entrypoint, actual - savannaclient.client.Client('1.1);
* auth improvements;
* base resource class improvements;
* 93 commits from the prev. release.
Thanks.
On Thu, Feb 20, 2014 at 3:53 AM, Sergey Lukjanov wrote:
> Additionally, it contains support for the latest EDP features.
>
>
> On Thu, Feb 20, 2014 at 3:52 AM, Sergey Lukjanov
> wrote:
>>
>> Hi folks,
>>
>> I'd like to make a 0.5.0 release of savanna client soon, please, share
>> your thoughts about stuff that should be included to it.
>>
>> Currently we have the following major changes/fixes:
>>
>> * mostly implemented CLI;
>> * unified entry point for python bindings like other OpenStack clients;
>> * auth improvements;
>> * base resource class improvements.
>>
>> Full diff:
>> https://github.com/openstack/python-savannaclient/compare/0.4.1...master
>>
>> Thanks.
>>
>> --
>> Sincerely yours,
>> Sergey Lukjanov
>> Savanna Technical Lead
>> Mirantis Inc.
>
>
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
--
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] Nominate Andrew Lazarew for savanna-core
Unanimously. Congratulations, Andrew, welcome to the core team! On Fri, Feb 21, 2014 at 4:46 PM, Matthew Farrellee wrote: > On 02/19/2014 05:40 PM, Sergey Lukjanov wrote: > >> Hey folks, >> >> I'd like to nominate Andrew Lazarew (alazarev) for savanna-core. >> >> He is among the top reviewers of Savanna subprojects. Andrew is working >> on Savanna full time since September 2013 and is very familiar with >> current codebase. His code contributions and reviews have demonstrated a >> good knowledge of Savanna internals. Andrew have a valuable knowledge of >> both core and EDP parts, IDH plugin and Hadoop itself. He's working on >> both bugs and new features implementation. >> >> Some links: >> >> http://stackalytics.com/report/reviews/savanna-group/30 >> http://stackalytics.com/report/reviews/savanna-group/90 >> http://stackalytics.com/report/reviews/savanna-group/180 >> https://review.openstack.org/#/q/owner:alazarev+savanna+AND+ >> -status:abandoned,n,z >> https://launchpad.net/~alazarev >> >> Savanna cores, please, reply with +1/0/-1 votes. >> >> Thanks. >> >> -- >> Sincerely yours, >> Sergey Lukjanov >> Savanna Technical Lead >> Mirantis Inc. >> > > fyi, some of those links don't work, but these do, > > http://stackalytics.com/report/contribution/savanna-group/30 > http://stackalytics.com/report/contribution/savanna-group/90 > http://stackalytics.com/report/contribution/savanna-group/180 > > i'm very happy to see andrew evolving in the savanna community, making > meaningful contributions, demonstrating a reasoned approach to resolve > disagreements, and following guidelines such as GitCommitMessages more > closely. i expect he will continue his growth as well as influence others > to contribute positively. > > +1 > > best, > > > matt > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting minutes Feb 20
Thanks everyone who have joined Savanna meeting. Here are the logs from the meeting: Minutes: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-02-20-18.03.html Log: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-02-20-18.03.log.html -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] renaming: initial voting
We've agreed to send top 5 options to foundation for review, more details - http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-02-20-18.03.html On Thu, Feb 20, 2014 at 10:02 PM, Sergey Lukjanov wrote: > I've contacted foundation and they are ready to verify 5 options, so, > we'll choose them on todays irc team meeting (starting right now). > > > On Wed, Feb 19, 2014 at 12:27 AM, Sergey Lukjanov > wrote: > >> The voting is ended, you can ding results here - >> http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=10&id=E_5dd4f18fde38ce8e&algorithm=beatpath >> >> So, the new name options for more detailed discussion are: >> >> 1. Gravity (Condorcet winner: wins contests with all other choices) >> 2. Sahara loses to Gravity by 10-8 >> 3. Quazar loses to Gravity by 13-3, loses to Sahara by 12-6 >> 4. Stellar loses to Gravity by 13-4, loses to Quazar by 9-7 >> 5. Caravan loses to Gravity by 12-5, loses to Stellar by 9-7 >> 6. Tied: >> Fusor loses to Gravity by 13-2, loses to Caravan by 9-4 >> Maestro loses to Gravity by 15-3, loses to Quazar by 9-5 >> Magellanic loses to Gravity by 15-0, loses to Caravan by 9-5 >> 9. Magellan loses to Gravity by 16-1, loses to Maestro by 7-4 >> 10. Stackadoop loses to Gravity by 14-6, loses to Magellan by 8-6 >> >> Thanks for voting. >> >> >> On Tue, Feb 18, 2014 at 10:52 AM, Sergey Lukjanov > > wrote: >> >>> Currently, we have only 19/47 votes, so, I'm adding one more day. >>> >>> >>> On Fri, Feb 14, 2014 at 3:04 PM, Sergey Lukjanov >> > wrote: >>> >>>> Hi folks, >>>> >>>> I've created a poll to select 10 candidates for new Savanna name. It's >>>> a first round of selecting new name for our lovely project. This poll will >>>> be ended in Monday, Feb 17. >>>> >>>> You should receive an email from "Sergey Lukjanov (CIVS poll >>>> supervisor) slukja...@mirantis.com" via cs.cornell.edu with topic >>>> "Poll: Savanna new name candidates". >>>> >>>> Thank you! >>>> >>>> P.S. I've bcced all ATCs, don't panic. >>>> >>>> -- >>>> Sincerely yours, >>>> Sergey Lukjanov >>>> Savanna Technical Lead >>>> Mirantis Inc. >>>> >>> >>> >>> >>> -- >>> Sincerely yours, >>> Sergey Lukjanov >>> Savanna Technical Lead >>> Mirantis Inc. >>> >> >> >> >> -- >> Sincerely yours, >> Sergey Lukjanov >> Savanna Technical Lead >> Mirantis Inc. >> > > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] renaming: initial voting
I've contacted foundation and they are ready to verify 5 options, so, we'll choose them on todays irc team meeting (starting right now). On Wed, Feb 19, 2014 at 12:27 AM, Sergey Lukjanov wrote: > The voting is ended, you can ding results here - > http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=10&id=E_5dd4f18fde38ce8e&algorithm=beatpath > > So, the new name options for more detailed discussion are: > > 1. Gravity (Condorcet winner: wins contests with all other choices) > 2. Sahara loses to Gravity by 10-8 > 3. Quazar loses to Gravity by 13-3, loses to Sahara by 12-6 > 4. Stellar loses to Gravity by 13-4, loses to Quazar by 9-7 > 5. Caravan loses to Gravity by 12-5, loses to Stellar by 9-7 > 6. Tied: > Fusor loses to Gravity by 13-2, loses to Caravan by 9-4 > Maestro loses to Gravity by 15-3, loses to Quazar by 9-5 > Magellanic loses to Gravity by 15-0, loses to Caravan by 9-5 > 9. Magellan loses to Gravity by 16-1, loses to Maestro by 7-4 > 10. Stackadoop loses to Gravity by 14-6, loses to Magellan by 8-6 > > Thanks for voting. > > > On Tue, Feb 18, 2014 at 10:52 AM, Sergey Lukjanov > wrote: > >> Currently, we have only 19/47 votes, so, I'm adding one more day. >> >> >> On Fri, Feb 14, 2014 at 3:04 PM, Sergey Lukjanov >> wrote: >> >>> Hi folks, >>> >>> I've created a poll to select 10 candidates for new Savanna name. It's a >>> first round of selecting new name for our lovely project. This poll will be >>> ended in Monday, Feb 17. >>> >>> You should receive an email from "Sergey Lukjanov (CIVS poll supervisor) >>> slukja...@mirantis.com" via cs.cornell.edu with topic "Poll: Savanna >>> new name candidates". >>> >>> Thank you! >>> >>> P.S. I've bcced all ATCs, don't panic. >>> >>> -- >>> Sincerely yours, >>> Sergey Lukjanov >>> Savanna Technical Lead >>> Mirantis Inc. >>> >> >> >> >> -- >> Sincerely yours, >> Sergey Lukjanov >> Savanna Technical Lead >> Mirantis Inc. >> > > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][all] config sample tools on os x
Yup, current implementation depends on GNU getopt. Julien, cool, that means I'm not crazy :) About using common getopt functionally - at least long args will be removed to support non GNU getopt. Rewriting it on pure python will be more useful IMO. On Thu, Feb 20, 2014 at 1:45 PM, Julien Danjou wrote: > On Thu, Feb 20 2014, Chmouel Boudjnah wrote: > > > In which sort of system setup other than macosx/freebsd > generate_sample.sh > > is not working? > > Likely everywhere GNU tools are not standard. So that's every system > _except_ GNU/Linux ones I'd say. :) > > -- > Julien Danjou > -- Free Software hacker > -- http://julien.danjou.info > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][all] config sample tools on os x
Another option is to conditionally use different getopt args like: if OSX: use getopt w/o long opts else: use powerful getopt w/ long opts It adds some inconsistency to the script but makes it useful for OS X users. Anyway, it's still possible to just use it w/o args to ensure latest config. On Thu, Feb 20, 2014 at 4:01 AM, Chmouel Boudjnah wrote: > > On Thu, Feb 20, 2014 at 12:17 AM, Sergey Lukjanov > wrote: > >> tools/config/generate_sample.sh isn't working on OS X due to the getopt >> usage. Any recipes / proposals to fix it? I have a workaround at least. >> > > > thanks for the workaround, I had a look on this while reporting bug > https://bugs.launchpad.net/heat/+bug/1261370, the easy way would be to > use bash builtin getopt but that would mean we would have to drop long > options. > > Is dropping long options an (pun not sure if it's intended) option? > > Chmouel. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][all] config sample tools on os x
Agreed, I just like to share/receive thoughts on it, probably the better workaround :) On Thu, Feb 20, 2014 at 3:48 AM, Doug Hellmann wrote: > > > > On Wed, Feb 19, 2014 at 6:17 PM, Sergey Lukjanov > wrote: > >> Hey stackers, >> >> tools/config/generate_sample.sh isn't working on OS X due to the getopt >> usage. Any recipes / proposals to fix it? I have a workaround at least. >> > > Your workaround looks fine. I wouldn't reject a patch, but since we don't > really use OS X as a platform I don't know if we would spend any time > changing the script to work there. > > Doug > > > >> >> TL;DR >> >> So, as I said tools/config/generate_sample.sh isn't working on OS X. >> Specifically it just couldn't parse command line arguments w/o any errors, >> just ignoring them. The reason of such behavior is significant difference >> between GNU getopt and BSD one (used in OS X). Probably, it could be easily >> fixed, but I don't know both of them. >> >> The main issue is that many projects are >> using tools/config/check_uptodate.sh in pep8 tox env to ensure that their >> config sample is always uptodate. So, "tox -e pep8" command always failing >> for such projects. >> >> Workaround: >> >> * install GNU getopt by using homebrew (brew install gnu-getopt) or >> macports (port install getopts); >> * add it to the PATH before the actual getopt before running tox; >> * if you'd like to make it default just add it to your >> bashrc/zshrc/etcrc, for example, for brew you should add: export >> PATH=$(brew --prefix gnu-getopt)/bin:$PATH >> >> Thanks. >> >> -- >> Sincerely yours, >> Sergey Lukjanov >> Savanna Technical Lead >> Mirantis Inc. >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] client 0.5.0 release
Additionally, it contains support for the latest EDP features. On Thu, Feb 20, 2014 at 3:52 AM, Sergey Lukjanov wrote: > Hi folks, > > I'd like to make a 0.5.0 release of savanna client soon, please, share > your thoughts about stuff that should be included to it. > > Currently we have the following major changes/fixes: > > * mostly implemented CLI; > * unified entry point for python bindings like other OpenStack clients; > * auth improvements; > * base resource class improvements. > > Full diff: > https://github.com/openstack/python-savannaclient/compare/0.4.1...master > > Thanks. > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] client 0.5.0 release
Hi folks, I'd like to make a 0.5.0 release of savanna client soon, please, share your thoughts about stuff that should be included to it. Currently we have the following major changes/fixes: * mostly implemented CLI; * unified entry point for python bindings like other OpenStack clients; * auth improvements; * base resource class improvements. Full diff: https://github.com/openstack/python-savannaclient/compare/0.4.1...master Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][all] config sample tools on os x
Hey stackers, tools/config/generate_sample.sh isn't working on OS X due to the getopt usage. Any recipes / proposals to fix it? I have a workaround at least. TL;DR So, as I said tools/config/generate_sample.sh isn't working on OS X. Specifically it just couldn't parse command line arguments w/o any errors, just ignoring them. The reason of such behavior is significant difference between GNU getopt and BSD one (used in OS X). Probably, it could be easily fixed, but I don't know both of them. The main issue is that many projects are using tools/config/check_uptodate.sh in pep8 tox env to ensure that their config sample is always uptodate. So, "tox -e pep8" command always failing for such projects. Workaround: * install GNU getopt by using homebrew (brew install gnu-getopt) or macports (port install getopts); * add it to the PATH before the actual getopt before running tox; * if you'd like to make it default just add it to your bashrc/zshrc/etcrc, for example, for brew you should add: export PATH=$(brew --prefix gnu-getopt)/bin:$PATH Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] Nominate Andrew Lazarew for savanna-core
Hey folks, I'd like to nominate Andrew Lazarew (alazarev) for savanna-core. He is among the top reviewers of Savanna subprojects. Andrew is working on Savanna full time since September 2013 and is very familiar with current codebase. His code contributions and reviews have demonstrated a good knowledge of Savanna internals. Andrew have a valuable knowledge of both core and EDP parts, IDH plugin and Hadoop itself. He's working on both bugs and new features implementation. Some links: http://stackalytics.com/report/reviews/savanna-group/30 http://stackalytics.com/report/reviews/savanna-group/90 http://stackalytics.com/report/reviews/savanna-group/180 https://review.openstack.org/#/q/owner:alazarev+savanna+AND+-status:abandoned,n,z https://launchpad.net/~alazarev Savanna cores, please, reply with +1/0/-1 votes. Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting Feb 20 1800 UTC
Hi folks, We'll be having the Savanna team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_February.2C_20 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20140220T18 The main topics are project renaming Icehouse 3 dev milestone. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] renaming: initial voting
The voting is ended, you can ding results here - http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=10&id=E_5dd4f18fde38ce8e&algorithm=beatpath So, the new name options for more detailed discussion are: 1. Gravity (Condorcet winner: wins contests with all other choices) 2. Sahara loses to Gravity by 10-8 3. Quazar loses to Gravity by 13-3, loses to Sahara by 12-6 4. Stellar loses to Gravity by 13-4, loses to Quazar by 9-7 5. Caravan loses to Gravity by 12-5, loses to Stellar by 9-7 6. Tied: Fusor loses to Gravity by 13-2, loses to Caravan by 9-4 Maestro loses to Gravity by 15-3, loses to Quazar by 9-5 Magellanic loses to Gravity by 15-0, loses to Caravan by 9-5 9. Magellan loses to Gravity by 16-1, loses to Maestro by 7-4 10. Stackadoop loses to Gravity by 14-6, loses to Magellan by 8-6 Thanks for voting. On Tue, Feb 18, 2014 at 10:52 AM, Sergey Lukjanov wrote: > Currently, we have only 19/47 votes, so, I'm adding one more day. > > > On Fri, Feb 14, 2014 at 3:04 PM, Sergey Lukjanov > wrote: > >> Hi folks, >> >> I've created a poll to select 10 candidates for new Savanna name. It's a >> first round of selecting new name for our lovely project. This poll will be >> ended in Monday, Feb 17. >> >> You should receive an email from "Sergey Lukjanov (CIVS poll supervisor) >> slukja...@mirantis.com" via cs.cornell.edu with topic "Poll: Savanna >> new name candidates". >> >> Thank you! >> >> P.S. I've bcced all ATCs, don't panic. >> >> -- >> Sincerely yours, >> Sergey Lukjanov >> Savanna Technical Lead >> Mirantis Inc. >> > > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Repositoris re-organization
a proposal. Please, feel free to discuss :)
>>>>
>>>> First of all, I would suggest to have a single reposository for all the
>>>> three main components of Murano: main murano API (the contents of the
>>>> present), workflow execution engine (currently murano-conductor; also it
>>>> was suggested to rename the component itself to murano-engine for more
>>>> consistent naming) and metadata repository (currently murano-repository).
>>>> These should remain as independent modules, being able to run as
>>>> different daemons, but stored within a single repository (similar to how
>>>> heat has heat-api, heat-cfn and heat-engine under the same hood). The name
>>>> of this repository is tentative: I think none of the existing match, so I
>>>> would suggest to create a new repo (simple "murano" seems to fit the best),
>>>> and then relocate all the content from other 3 repos and remove them
>>>> aftwerwards.
>>>>
>>>> When the api, the repository and the engine are merged into a single
>>>> repo, there will be no sense in having murano-common repo for storing their
>>>> common classes: instead, there should be a "common" package inside the main
>>>> murano repository.
>>>>
>>>> Also, it has been suggested to move our agents (both windows and
>>>> unified python) into the main repository as well - just to put them into a
>>>> separate subfolder. I don't see any reasons why they should be separated
>>>> from core Murano: I don't believe we are going to have any third-party
>>>> implementations of our "Unified agent" proposals, while this possibility
>>>> was the main reason for separatinng them.
>>>>
>>>> Next, deployment scripts and auto-generated docs: are there reasons why
>>>> they should be in their own repositories, instead of "docs" and
>>>> "tools/deployment" folders of the primary repo? I would prefer the latter:
>>>> docs and deployment scripts have no meaning without the sources which they
>>>> document/deploy - so it is better to have them consistent.
>>>>
>>>>
>>>> Then, the python bindings: "There can be only one" (c). Yes, the
>>>> metadata API and the main murano API are different indeed, however there is
>>>> no reason in having two repositories for their clients: let's have a single
>>>> repo, containing two packages inside. Are there any technical reasons
>>>> preventing us from doing that?
>>>> CLI should be common as well - I think there should be a single
>>>> command-line utility ("murano" should be the name), allowing to query both
>>>> APIs. This CLI will eventually evolve into the developer's utility: it will
>>>> get commands to package, sign and submit application packages.
>>>>
>>>> Openstack Dashboard plugin - aka Murano-dashboard - should remain in a
>>>> separated repo, I have no objections here :)
>>>>
>>>> murano-tests may reamin independent as well - however, this repository
>>>> is not likely to be transferred when we go to incubation: incubated
>>>> projects should have tempest test in their repositories, shoudn't they? Our
>>>> our test may remain on stackforge - this is irrelevant.
>>>>
>>>> And finally, we need some place to store sources of our metadata
>>>> objects: the definition of core murano library, as well as example
>>>> services, with all their stuff - metadata and ui definitions, heat
>>>> templates, scripts etc. Here I propose to create a new repo, specially
>>>> dedicated for this purpose. If we succeed in building the ecosystem for
>>>> application developers and publishers, this will be the repo in which they
>>>> should contribute, while the core murano repo's will remain relativele
>>>> stable.
>>>>
>>>>
>>>> So, this brings us to the following list of repos:
>>>>
>>>>- *murano* - main services, common, agents docs, deployments scripts
>>>>- *python-muranoclient* - python bindings and CLI
>>>>- *murano-dashboard* - OS Dashboard plugin
>>>>- *murano-apps* - new repo for metadata, including core library and
>>>>example apps.
>>>>- *murano-tests* - existing test-repo, not going to be transferred
>>>>when incubated.
>>>>
>>>>
>>>> This leaves us with just 4 repositories (plus one additional which will
>>>> remain on stackforge), with clear separation of concerns.
>>>>
>>>> There may be technical issues in doing this mergement (we do not want
>>>> to loose revision history, do we?), but they should be solvable (I'll write
>>>> to infra asking on what is possible and what is not), but in general this
>>>> is the direction in which we should be moving, as it seems to me.
>>>>
>>>> --
>>>> Regards,
>>>> Alexander Tivelkov
>>>>
>>>> ___
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> 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-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] plugin version or hadoop version?
penstack.org >>> <mailto:OpenStack-dev@lists.openstack.org> >>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> CONFIDENTIALITY NOTICE >>> NOTICE: This message is intended for the use of the individual or >>> entity to which it is addressed and may contain information that is >>> confidential, privileged and exempt from disclosure under applicable >>> law. If the reader of this message is not the intended recipient, you >>> are hereby notified that any printing, copying, dissemination, >>> distribution, disclosure or forwarding of this communication is >>> strictly prohibited. If you have received this communication in error, >>> please contact the sender immediately and delete it from your system. >>> Thank You.___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> <mailto:OpenStack-dev@lists.openstack.org> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] reverify/recheck
gt;i-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A& >> >> >>r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=B8yQ75uRFa7dyD%2F >> >> >>bgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0A&s=21e7f4ebc24f0a13780981720f9332111d >> >>d603f3c0661229dc90d82bfb5c3122> >> >> >> >> >> >> >> >> >> >> ___ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> >> >> >> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi >> >> >>-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r >> >> >>=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59x >> >> >>Icg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=1a2a59024e18b786b5c2c13535b7f3d050363 >> >>ff628dc96b8561e12489d30c0bd >> >> >> >___ >> >OpenStack-dev mailing list >> >OpenStack-dev@lists.openstack.org >> > >> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi- >> >> >bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e >> >> >H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59xIcg >> >> >6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=1a2a59024e18b786b5c2c13535b7f3d050363ff62 >> >8dc96b8561e12489d30c0bd >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] renaming: initial voting
Currently, we have only 19/47 votes, so, I'm adding one more day. On Fri, Feb 14, 2014 at 3:04 PM, Sergey Lukjanov wrote: > Hi folks, > > I've created a poll to select 10 candidates for new Savanna name. It's a > first round of selecting new name for our lovely project. This poll will be > ended in Monday, Feb 17. > > You should receive an email from "Sergey Lukjanov (CIVS poll supervisor) > slukja...@mirantis.com" via cs.cornell.edu with topic "Poll: Savanna new > name candidates". > > Thank you! > > P.S. I've bcced all ATCs, don't panic. > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing
Sukhdev, that's awesome, I think it'll be great to make folks able to start from something easy configurable like gerrit trigger plugin. On Sat, Feb 15, 2014 at 6:01 AM, Sukhdev Kapur wrote: > > > > On Thu, Feb 13, 2014 at 12:39 PM, Jay Pipes wrote: > >> On Thu, 2014-02-13 at 12:34 -0800, Sukhdev Kapur wrote: >> > Jay, >> > >> > Just an FYI. We have modified the Gerrit plugin it accept/match regex >> > to generate notifications of for "receck no bug/bug ###". It turned >> > out to be very simple fix and we (Arista Testing) is now triggering on >> > recheck comments as well. >> >> Thanks for the update, Sukhdev! Is this updated Gerrit plugin somewhere >> where other folks can use it? >> > > > Yes the patch is ready. I am documenting it as a part of overall > description of Arista Testing Setup and will be releasing soon as part of > the document that I am writing. > Hopefully next week. > > regards.. > -Sukhdev > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] renaming: initial voting
Hi folks, I've created a poll to select 10 candidates for new Savanna name. It's a first round of selecting new name for our lovely project. This poll will be ended in Monday, Feb 17. You should receive an email from "Sergey Lukjanov (CIVS poll supervisor) slukja...@mirantis.com" via cs.cornell.edu with topic "Poll: Savanna new name candidates". Thank you! P.S. I've bcced all ATCs, don't panic. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] project name collision - renaming required
Hi folks, It was decided to remove some names from the initial voting, please, see them in meeting logs - http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-02-13-18.00.html Thanks. On Thu, Feb 13, 2014 at 4:34 PM, Sergey Lukjanov wrote: > Please, note, that I'm planning today to setup first round of name voting > to select top N options and trash bad options. It'll be done after the IRC > team meeting. > > > On Sat, Feb 8, 2014 at 9:34 AM, Sergey Lukjanov wrote: > >> There are already some names proposed in the etherpad, so, I'll setup a >> voting to choose top N options and discuss them detailed. The voting will >> be started after the next IRC team meeting next week, Feb 13. >> >> Thanks. >> >> P.S. Looking forward for new name proposals :) >> >> >> On Thu, Jan 30, 2014 at 10:39 AM, Sergey Lukjanov > > wrote: >> >>> Hi folks, >>> >>> As part of preparations for graduation from incubation [0], I've >>> contacted OpenStack Foundation Marketing team to ensure that everything is >>> ok with our program and project names from their point of view. Thanks for >>> Lauren Sell for providing info. >>> >>> Thetus Corporation already use 'Savanna' as the name for one of their >>> technologies [1]. Thetus doesn't actually hold any registered trademark for >>> 'Savanna', but they have common-law rights to the mark because they have >>> established use and marketed it since 2010, so, in case if we applied for a >>> trademark, they could certainly challenge us and win. So, the answer from >>> marketing team was that it's a pretty high risk to continue using our >>> lovely name... The most sad part is that I couldn't google their site using >>> words savanna, hadoop, cloud and etc. >>> >>> Let's move on to the new name selection process. I'm proposing one or >>> two weeks for brainstorming and sharing your thoughts about the project >>> name depending on number of suitable options, then I'll probably setup the >>> small voting to select the best option. >>> >>> I've created an etherpad [2] for discussing new name options, so, the >>> process is send your options to this thread and then go to the etherpad [2] >>> to discuss them. Please, don't forget to google your options to avoid one >>> more renaming in future ;) >>> >>> Thanks, looking forward for you thoughts. >>> >>> [0] >>> http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements- >>> "Project should have engaged with marketing team to check suitable >>> official name" >>> [1] http://www.thetus.com/savanna >>> [2] https://etherpad.openstack.org/p/savanna-renaming >>> >>> -- >>> Sincerely yours, >>> Sergey Lukjanov >>> Savanna Technical Lead >>> Mirantis Inc. >>> >> >> >> >> -- >> Sincerely yours, >> Sergey Lukjanov >> Savanna Technical Lead >> Mirantis Inc. >> > > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] instructions for creating a new oslo library
Doug, great work, I think it could be sometimes be a base for a detailed guide about different type projects creation. On Thu, Feb 13, 2014 at 1:29 AM, Doug Hellmann wrote: > > > > On Wed, Feb 12, 2014 at 4:12 PM, Ben Nemec wrote: > >> On 2014-02-12 13:28, Doug Hellmann wrote: >> >> I have been working on instructions for creating new Oslo libraries, >> either from scratch or by graduating code from the incubator. I would >> appreciate any feedback about whether I have all of the necessary details >> included in https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary >> >> Thanks, >> Doug >> >> First off: \o/ >> >> This should really help cut down on the amount of code we need to sync >> from incubator. >> >> Given all the fun we've had with oslo.sphinx, maybe we should add a note >> that only runtime deps should use the oslo. namespace? >> > > Yes, definitely, I added that. Thanks! > > > >> Other than that, I think I'd have to run through the process to have >> further comments. >> > > You'll have your chance to do that soon, I hope! :-) > > Doug > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gamification and on-boarding ...
+1, nice idea, it could be really funny. agreed with Thierry's note about automation. On Thu, Feb 13, 2014 at 5:53 PM, Sean Dague wrote: > On 02/13/2014 05:37 AM, Thierry Carrez wrote: > > Sandy Walsh wrote: > >> The informal OpenStack motto is "automate everything", so perhaps we > should consider some form of gamification [1] to help us? Can we offer > badges, quests and challenges to new users to lead them on the way to being > strong contributors? > >> > >> "Fixed your first bug" badge > >> "Updated the docs" badge > >> "Got your blueprint approved" badge > >> "Triaged a bug" badge > >> "Reviewed a branch" badge > >> "Contributed to 3 OpenStack projects" badge > >> "Fixed a Cells bug" badge > >> "Constructive in IRC" badge > >> "Freed the gate" badge > >> "Reverted branch from a core" badge > >> etc. > > > > I think that works if you only keep the ones you can automate. > > "Constructive in IRC" for example sounds a bit subjective to me, and you > > don't want to issue those badges one-by-one manually. > > > > Second thing, you don't want the game to start polluting your bug > > status, i.e. people randomly setting bugs to "triaged" to earn the > > "Triaged a bug" badge. So the badges we keep should be provably useful ;) > > > > A few other suggestions: > > "Found a valid security issue" (to encourage security reports) > > "Fixed a bug submitted by someone else" (to encourage attacking random > bugs) > > "Removed code" (to encourage tech debt reduction) > > "Backported a fix to a stable branch" (to encourage backporting) > > "Fixed a bug that was tagged nobody-wants-to-fix-this-one" (to encourage > > people to attack critical / hard bugs) > > > > We might need "protected" tags to automate this: tags that only some > > people could set to bugs/tasks to designate "gate-freeing" or > > "nobody-wants-to-fix-this-one" bugs that will give you badges if you fix > > them. > > > > So overall it's a good idea, but it sounds a bit tricky to automate it > > properly to avoid bad side-effects. > > Gamification is a cool idea, if someone were to implement it, I'd be +1. > > Realistically, the biggest issue I see with on-boarding is mentoring > time. Especially with folks completely new to our structure, there is a > lot of confusing things going on. And OpenStack is a ton to absorb. I > get pinged a lot on IRC, answer when I can, and sometimes just have to > ignore things because there are only so many hours in the day. > > I think Anita has been doing a great job with the Neutron CI onboarding > and new folks, and that's given me perspective on just how many > dedicated mentors we'd need to bring new folks on. With 400 new people > showing up each release, it's a lot of engagement time. It's also > investment in our future, as some of these folks will become solid > contributors and core reviewers. > > So it seems like the only way we'd make real progress here is to get a > chunk of people to devote some dedicated time to mentoring in the next > cycle. Gamification might be most useful, but honestly I expect a "Start > Here" page with the consolidated list of low-hanging-fruit bugs, and a > Review Here page with all reviews for low hanging fruit bugs (so they > don't get lost by core review team) would be a great start. > > The delays on reviews for relatively trivial fixes I think is something > that is probably more demotivating to new folks than the lack of badges. > So some ability to keep on top of that I think would be really great. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing
ot;recheck". :( >>> >>> So, we either need to a) change the requirements of third party testers, >>> b) enhance the Jenkins Gerrit plugin with the missing functionality, or >>> c) add documentation on how to set up Zuul as the triggering system >>> instead of the Jenkins Gerrit plugin. >>> >>> I'm happy to work on c), but I think relaxing the restriction (a) is >>> probably needed short-term. >>> >>> Best, >>> -jay >>> >>> [1] http://ci.openstack.org/third_party.html >>> [2] http://ci.openstack.org/third_party.html#requirements >>> [3] >>> >>> http://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way >>> [4] By "linked" I mean it both reads from the OpenStack Gerrit system >>> and writes (adds comments) to it >>> [5] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ >>> [6] http://github.com/jaypipes/os-ext-testing >>> [7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger >>> [8] >>> >>> https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/triggers.py#L121 >>> >>> >>> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting minutes Feb 13
Thanks everyone who have joined Savanna meeting. Here are the logs from the meeting: Minutes: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-02-13-18.00.html Log: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-02-13-18.00.log.html -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] Mission Statement wording
We have a small voting on the meeting and agreed on this one ("To provide a
scalable data processing stack and associated management interfaces").
On Thu, Feb 13, 2014 at 6:53 PM, Andrew Lazarev wrote:
> Short version looks good for me.
>
> Andrew.
>
>
> On Thu, Feb 13, 2014 at 4:29 AM, Sergey Lukjanov
> wrote:
>
>> Hi folks,
>>
>> I'm working now on adding Savanna's mission statement to governance docs
>> [0]. There are some comments on our current one to make it simpler and
>> remove marketing like stuff.
>>
>> So, current option is:
>>
>> To provide a scalable data processing stack and associated management
>> interfaces.
>>
>> (thanks for Doug for proposing it).
>>
>> So, please, share your objections (and suggestions too). Additionally I'd
>> like to talk about it on todays IRC meeting.
>>
>> Thanks.
>>
>> [0] https://review.openstack.org/#/c/71045/1/reference/programs.yaml
>>
>> --
>> Sincerely yours,
>> Sergey Lukjanov
>> Savanna Technical Lead
>> Mirantis Inc.
>>
>
>
--
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] project name collision - renaming required
Please, note, that I'm planning today to setup first round of name voting to select top N options and trash bad options. It'll be done after the IRC team meeting. On Sat, Feb 8, 2014 at 9:34 AM, Sergey Lukjanov wrote: > There are already some names proposed in the etherpad, so, I'll setup a > voting to choose top N options and discuss them detailed. The voting will > be started after the next IRC team meeting next week, Feb 13. > > Thanks. > > P.S. Looking forward for new name proposals :) > > > On Thu, Jan 30, 2014 at 10:39 AM, Sergey Lukjanov > wrote: > >> Hi folks, >> >> As part of preparations for graduation from incubation [0], I've >> contacted OpenStack Foundation Marketing team to ensure that everything is >> ok with our program and project names from their point of view. Thanks for >> Lauren Sell for providing info. >> >> Thetus Corporation already use 'Savanna' as the name for one of their >> technologies [1]. Thetus doesn't actually hold any registered trademark for >> 'Savanna', but they have common-law rights to the mark because they have >> established use and marketed it since 2010, so, in case if we applied for a >> trademark, they could certainly challenge us and win. So, the answer from >> marketing team was that it's a pretty high risk to continue using our >> lovely name... The most sad part is that I couldn't google their site using >> words savanna, hadoop, cloud and etc. >> >> Let's move on to the new name selection process. I'm proposing one or two >> weeks for brainstorming and sharing your thoughts about the project name >> depending on number of suitable options, then I'll probably setup the small >> voting to select the best option. >> >> I've created an etherpad [2] for discussing new name options, so, the >> process is send your options to this thread and then go to the etherpad [2] >> to discuss them. Please, don't forget to google your options to avoid one >> more renaming in future ;) >> >> Thanks, looking forward for you thoughts. >> >> [0] >> http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements- >> "Project should have engaged with marketing team to check suitable >> official name" >> [1] http://www.thetus.com/savanna >> [2] https://etherpad.openstack.org/p/savanna-renaming >> >> -- >> Sincerely yours, >> Sergey Lukjanov >> Savanna Technical Lead >> Mirantis Inc. >> > > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting Feb 13 1800 UTC
Hi folks, We'll be having the Savanna team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_February.2C_13 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20140213T18 P.S. I'd like to discuss mission statement and project renaming today. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] Mission Statement wording
Hi folks, I'm working now on adding Savanna's mission statement to governance docs [0]. There are some comments on our current one to make it simpler and remove marketing like stuff. So, current option is: To provide a scalable data processing stack and associated management interfaces. (thanks for Doug for proposing it). So, please, share your objections (and suggestions too). Additionally I'd like to talk about it on todays IRC meeting. Thanks. [0] https://review.openstack.org/#/c/71045/1/reference/programs.yaml -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] Proposing Sergey Lukjanov for infra-core
Thank you all! I'm glad to help infra team with extremely growing number of CRs to their projects. On Tue, Feb 11, 2014 at 2:24 PM, Thierry Carrez wrote: > James E. Blair wrote: > > I'm very pleased to propose that we add Sergey Lukjanov to the > > infra-core team. > > > > He is among the top reviewers of projects in openstack-infra, and is > > very familiar with how jenkins-job-builder and zuul are used and > > configured. He has done quite a bit of work in helping new projects > > through the process and ensuring that changes to the CI system are > > correct. In addition to providing very helpful reviews he has also > > contributed significant patches to our Python projects illustrating a > > high degree of familiarity with the code base and project direction. > > And as a bonus, we're all looking forward to once again having an > > infra-core member in a non-US time zone! > > +1! > > My only fear is that Sergey is going in too many directions at the same > time (remember he is also the Savanna^WSahara/Caravan/Batyr/Slonik PTL) > and might burn out. But so far he has been gracefully handling the > increasing load... so let's see how that goes :) > > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] in-instance update hooks
Hi Clint, nice blueprint. I've added a section about Savanna to the etherpad. Our further usecase looks like the Trove's one - we probably like to support resizing nodes. Additionally, we'd like to decommission data nodes before reboot/shutdown them. Thanks. On Tue, Feb 11, 2014 at 9:22 AM, Clint Byrum wrote: > Hi, so in the previous thread about rolling updates it became clear that > having in-instance control over updates is a more fundamental idea than > I had previously believed. During an update, Heat does things to servers > that may interrupt the server's purpose, and that may cause it to fail > subsequent things in the graph. > > Specifically, in TripleO we have compute nodes that we are managing. > Before rebooting a machine, we want to have a chance to live-migrate > workloads if possible, or evacuate in the simpler case, before the node > is rebooted. Also in the case of a Galera DB where we may even be running > degraded, we want to ensure that we have quorum before proceeding. > > I've filed a blueprint for this functionality: > > https://blueprints.launchpad.net/heat/+spec/update-hooks > > I've cobbled together a spec here, and I would very much welcome > edits/comments/etc: > > https://etherpad.openstack.org/p/heat-update-hooks > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Ready to import Launchpad Answers into Ask OpenStack
Thank you! On Tue, Feb 11, 2014 at 11:36 AM, Stefano Maffulli wrote: > Hi Sergey > > On Tue 11 Feb 2014 08:01:48 AM CET, Sergey Lukjanov wrote: > > Stefano, is it possible to import savanna's answers@launchpad to > ask.o.o? > > Yes, indeed. I apologize for not putting you explicitly in the cc list. > The full list of projects we'll work on is on the bug itself: > > https://bugs.launchpad.net/openstack-community/+bug/1212089 > > savanna was already there, I must have overlooked your email when > composing this request. We'll be importing during the next few days. > > Regards, > Stef > > -- > Ask and answer questions on https://ask.openstack.org > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Ready to import Launchpad Answers into Ask OpenStack
Awesome! Stefano, is it possible to import savanna's answers@launchpad to ask.o.o? Thanks. On Fri, Feb 7, 2014 at 12:01 AM, Russell Bryant wrote: > On 02/06/2014 12:07 PM, Stefano Maffulli wrote: > > Hello folks, > > > > we're ready to import the answers from Launchpad into Ask OpenStack. A > > script will import all questions, answers, comments (and data abou user > > accounts) from LP into Ask, tag them as the project of origin (nova, > > swift, etc). You can see the results of the test runs on > > http://ask-staging.openstack.org/en/questions/ > > For example, the questions migrated from LP Answers Swift are > > > http://ask-staging.openstack.org/en/questions/scope:all/sort:activity-desc/tags:swift/page:1/ > > > > We'll try also to sync accounts already existing on Ask with those > > imported from LP, matching on usernames, OpenID and email addresses as > > exposed by LP API. If there is no match, a new account will be created. > > > > I'm writing to you to make sure that you're aware of this effort and to > > ask you if you are really, adamantly against closing LP Answers. In case > > you are against, I'll try to convince you otherwise :) > > > > You can see the history of the effort and its current status on > > > > https://bugs.launchpad.net/openstack-community/+bug/1212089 > > > > Next step is to set a date to run the import. The process will be: > > > > 1 - run the import script > > 2 - put Ask down for maintenance > > 3 - import data into Ask > > 4 - check that it run correctly > > 5 - close all LP Answers, reconfigure LP projects to redirect to Ask > > > > I think we can run this process one project at the time so we minimize > > interruptions. If the PTLs authorize me I think I have the necessary > > permissions to edit LP Answers, remove the archives from the public once > > the data is replicated correctly on Ask, so you can focus on coding. > > > > Let me know what you think about closing LP Answers, use Ask exclusively > > to handle support requests and about delegating to me closing LP Answers > > for your projects. > > All sounds good to me! Thanks for doing this! > > -- > Russell Bryant > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] project name collision - renaming required
There are already some names proposed in the etherpad, so, I'll setup a voting to choose top N options and discuss them detailed. The voting will be started after the next IRC team meeting next week, Feb 13. Thanks. P.S. Looking forward for new name proposals :) On Thu, Jan 30, 2014 at 10:39 AM, Sergey Lukjanov wrote: > Hi folks, > > As part of preparations for graduation from incubation [0], I've contacted > OpenStack Foundation Marketing team to ensure that everything is ok with > our program and project names from their point of view. Thanks for Lauren > Sell for providing info. > > Thetus Corporation already use 'Savanna' as the name for one of their > technologies [1]. Thetus doesn't actually hold any registered trademark for > 'Savanna', but they have common-law rights to the mark because they have > established use and marketed it since 2010, so, in case if we applied for a > trademark, they could certainly challenge us and win. So, the answer from > marketing team was that it's a pretty high risk to continue using our > lovely name... The most sad part is that I couldn't google their site using > words savanna, hadoop, cloud and etc. > > Let's move on to the new name selection process. I'm proposing one or two > weeks for brainstorming and sharing your thoughts about the project name > depending on number of suitable options, then I'll probably setup the small > voting to select the best option. > > I've created an etherpad [2] for discussing new name options, so, the > process is send your options to this thread and then go to the etherpad [2] > to discuss them. Please, don't forget to google your options to avoid one > more renaming in future ;) > > Thanks, looking forward for you thoughts. > > [0] > http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements- > "Project should have engaged with marketing team to check suitable > official name" > [1] http://www.thetus.com/savanna > [2] https://etherpad.openstack.org/p/savanna-renaming > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting minutes Feb 6
Thanks everyone who have joined Savanna meeting. Here are the logs from the meeting: Minutes: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-02-06-18.09.html Log: http://eavesdrop.openstack.org/meetings/savanna/2014/savanna.2014-02-06-18.09.log.html -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Python 3.3 gates are failing
The same with swiftclient, hacking, openstacksdk and others - http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiJ2FzY2lpJyBjb2RlYyBjYW4ndCBkZWNvZGUgYnl0ZSAweGMzIGluIHBvc2l0aW9uIDkwNTU6IG9yZGluYWwgbm90IGluIHJhbmdlKDEyOClcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM5MTc3NDY4MTMwMX0= On Fri, Feb 7, 2014 at 3:18 PM, Noorul Islam K M wrote: > > Recently python3.3 jobs started failing. Noticed this in > python-solumclient project but it looks like a common problem. > > python-solumclient > > > http://logs.openstack.org/72/57172/2/check/gate-python-solumclient-python33/8da814d/console.html > > python-novaclient > > > http://logs.openstack.org/46/71846/1/check/gate-python-novaclient-python33/68bc48a/console.html > > Regards, > Noorul > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Governance] Integrated projects and new requirements
Probably all PTLs could be asked to prepare initial report for requirements like it was done last time for graduating projects. On Thu, Feb 6, 2014 at 6:07 PM, Dina Belova wrote: > I propose we do this in future TC meetings, time permitting. I >> propose we start with projects where the PTL was also elected to the TC, >> so that we give this new review's process some mileage. > > > +1, good idea > > > On Thu, Feb 6, 2014 at 5:47 PM, Thierry Carrez wrote: > >> Dina Belova wrote: >> > Perhaps we should start putting each project on the TC agenda for a >> > review of its current standing. For any gaps, I think we should >> set a >> > specific timeframe for when we expect these gaps to be filled. >> > >> > >> > Really good idea. New requirements are great, but frankly speaking not >> > all currently integrated projects fit all of them. >> > Will be nice to find out all gaps there and fix them asap. >> >> Agreed. I propose we do this in future TC meetings, time permitting. I >> propose we start with projects where the PTL was also elected to the TC, >> so that we give this new review's process some mileage. >> >> So.. Nova, Cinder, Neutron ? >> >> -- >> Thierry Carrez (ttx) >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting Feb 6 1800 UTC
Hi folks, We'll be having the Savanna team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_February.2C_06 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20140206T18 P.S. The main topic will be Savanna project renaming. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] async devstack/tempest gating
Hi folks, I'd like to announce that now we have the following bunch of devstack-gate jobs with Savanna enabled and very basic Tempest tests running for Savanna. Each of this job runs migrations to setup DB and sanity checks REST API. We have 3 types of jobs running: * Nova-Network + MySQL; * Neutron + MySQL; * Nova-Network + PostgreSQL. And for which projects we're running them (all 3 jobs): * voting jobs for Savanna repo; * non-voting for Tempest; * non-voting for DevStack; * non-voting for devstack-gate. P.S. thanks for infra folks for awesome infra ;) Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] savann-ci, Re: [savanna] Alembic migrations and absence of DROP column in sqlite
Trevor, I've created an issue to track it https://bugs.launchpad.net/savanna/+bug/1276764 On Wed, Feb 5, 2014 at 8:56 PM, Trevor McKay wrote: > Hi Sergey, > > Is there a bug or a blueprint for this? I did a quick search but > didn't see one. > > Thanks, > > Trevor > > On Wed, 2014-02-05 at 16:06 +0400, Sergey Kolekonov wrote: > > I'm currently working on moving on the MySQL for savanna-ci > > > > > > On Wed, Feb 5, 2014 at 3:53 PM, Sergey Lukjanov > > wrote: > > Agreed, let's move on to the MySQL for savanna-ci to run > > integration tests against production-like DB. > > > > > > On Wed, Feb 5, 2014 at 1:54 AM, Andrew Lazarev > > wrote: > > Since sqlite is not in the list of "databases that > > would be used in production", CI should use other DB > > for testing. > > > > > > Andrew. > > > > > > On Tue, Feb 4, 2014 at 1:13 PM, Alexander Ignatov > > wrote: > > Indeed. We should create a bug around that and > > move our savanna-ci to mysql. > > > > Regards, > > Alexander Ignatov > > > > > > > > On 05 Feb 2014, at 01:01, Trevor McKay > > wrote: > > > > > This brings up an interesting problem: > > > > > > In https://review.openstack.org/#/c/70420/ > > I've added a migration that > > > uses a drop column for an upgrade. > > > > > > But savann-ci is apparently using a sqlite > > database to run. So it can't > > > possibly pass. > > > > > > What do we do here? Shift savanna-ci tests > > to non sqlite? > > > > > > Trevor > > > > > > On Sat, 2014-02-01 at 18:17 +0200, Roman > > Podoliaka wrote: > > >> Hi all, > > >> > > >> My two cents. > > >> > > >>> 2) Extend alembic so that op.drop_column() > > does the right thing > > >> We could, but should we? > > >> > > >> The only reason alembic doesn't support > > these operations for SQLite > > >> yet is that SQLite lacks proper support of > > ALTER statement. For > > >> sqlalchemy-migrate we've been providing a > > work-around in the form of > > >> recreating of a table and copying of all > > existing rows (which is a > > >> hack, really). > > >> > > >> But to be able to recreate a table, we > > first must have its definition. > > >> And we've been relying on SQLAlchemy schema > > reflection facilities for > > >> that. Unfortunately, this approach has a > > few drawbacks: > > >> > > >> 1) SQLAlchemy versions prior to 0.8.4 don't > > support reflection of > > >> unique constraints, which means the > > recreated table won't have them; > > >> > > >> 2) special care must be taken in 'edge' > > cases (e.g. when you want to > > >> drop a BOOLEAN column, you must also drop > > the corresponding CHECK (col > > >> in (0, 1)) constraint manually, or SQLite > > will raise an e
Re: [openstack-dev] [savanna] Choosing provisioning engine during cluster launch
It sounds little useful for dev/testing, I'm not really think that it's needed, but not -1 such addition to the REST API. On Thu, Jan 30, 2014 at 7:52 PM, Trevor McKay wrote: > My mistake, it's already there. I missed the distinction between set on > startup and set per cluster. > > Trev > > On Thu, 2014-01-30 at 10:50 -0500, Trevor McKay wrote: > > +1 > > > > How about an undocumented config? > > > > Trev > > > > On Thu, 2014-01-30 at 09:24 -0500, Matthew Farrellee wrote: > > > i imagine this is something that can be useful in a development and > > > testing environment, especially during the transition period from > direct > > > to heat. so having the ability is not unreasonable, but i wouldn't > > > expose it to users via the dashboard (maybe not even directly in the > cli) > > > > > > generally i want to reduce the number of parameters / questions the > user > > > is asked > > > > > > best, > > > > > > > > > matt > > > > > > On 01/30/2014 04:42 AM, Dmitry Mescheryakov wrote: > > > > I agree with Andrew. I see no value in letting users select how their > > > > cluster is provisioned, it will only make interface a little bit more > > > > complex. > > > > > > > > Dmitry > > > > > > > > > > > > 2014/1/30 Andrew Lazarev > > > <mailto:alaza...@mirantis.com>> > > > > > > > > Alexander, > > > > > > > > What is the purpose of exposing this to user side? Both engines > must > > > > do exactly the same thing and they exist in the same time only > for > > > > transition period until heat engine is stabilized. I don't see > any > > > > value in proposed option. > > > > > > > > Andrew. > > > > > > > > > > > > On Wed, Jan 29, 2014 at 8:44 PM, Alexander Ignatov > > > > mailto:aigna...@mirantis.com>> wrote: > > > > > > > > Today Savanna has two provisioning engines, heat and old one > > > > known as 'direct'. > > > > Users can choose which engine will be used by setting special > > > > parameter in 'savanna.conf'. > > > > > > > > I have an idea to give an ability for users to define > > > > provisioning engine > > > > not only when savanna is started but when new cluster is > > > > launched. The idea is simple. > > > > We will just add new field 'provisioning_engine' to 'cluster' > > > > and 'cluster_template' > > > > objects. And profit is obvious, users can easily switch from > one > > > > engine to another without > > > > restarting savanna service. Of course, this parameter can be > > > > omitted and the default value > > > > from the 'savanna.conf' will be applied. > > > > > > > > Is this viable? What do you think? > > > > > > > > Regards, > > > > Alexander Ignatov > > > > > > > > > > > > > > > > > > > > ___ > > > > OpenStack-dev mailing list > > > > OpenStack-dev@lists.openstack.org > > > > <mailto:OpenStack-dev@lists.openstack.org> > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > > > > ___ > > > > OpenStack-dev mailing list > > > > OpenStack-dev@lists.openstack.org > > > > <mailto:OpenStack-dev@lists.openstack.org> > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > > > > > > > > ___ > > > > OpenStack-dev mailing list > > > > OpenStack-dev@lists.openstack.org > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > ___ > > > OpenStack-dev mailing list > > > OpenStack-dev@lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] savann-ci, Re: [savanna] Alembic migrations and absence of DROP column in sqlite
It's about integration tests that aren't db-specific, so, just DATABASE/connection should be fixed ;) On Wed, Feb 5, 2014 at 4:33 PM, Alexei Kornienko wrote: > Hi > > > I'm currently working on moving on the MySQL for savanna-ci > > We are working on same task in ceilometer so maybe you could use some of > our patches as reference: > > https://review.openstack.org/#/c/59489/ > https://review.openstack.org/#/c/63049/ > > Regards, > Alexei > > > On 02/05/2014 02:06 PM, Sergey Kolekonov wrote: > > I'm currently working on moving on the MySQL for savanna-ci > > > On Wed, Feb 5, 2014 at 3:53 PM, Sergey Lukjanov wrote: > >> Agreed, let's move on to the MySQL for savanna-ci to run integration >> tests against production-like DB. >> >> >> On Wed, Feb 5, 2014 at 1:54 AM, Andrew Lazarev wrote: >> >>> Since sqlite is not in the list of "databases that would be used in >>> production", CI should use other DB for testing. >>> >>> Andrew. >>> >>> >>> On Tue, Feb 4, 2014 at 1:13 PM, Alexander Ignatov >> > wrote: >>> >>>> Indeed. We should create a bug around that and move our savanna-ci to >>>> mysql. >>>> >>>> Regards, >>>> Alexander Ignatov >>>> >>>> >>>> >>>> On 05 Feb 2014, at 01:01, Trevor McKay wrote: >>>> >>>> > This brings up an interesting problem: >>>> > >>>> > In https://review.openstack.org/#/c/70420/ I've added a migration >>>> that >>>> > uses a drop column for an upgrade. >>>> > >>>> > But savann-ci is apparently using a sqlite database to run. So it >>>> can't >>>> > possibly pass. >>>> > >>>> > What do we do here? Shift savanna-ci tests to non sqlite? >>>> > >>>> > Trevor >>>> > >>>> > On Sat, 2014-02-01 at 18:17 +0200, Roman Podoliaka wrote: >>>> >> Hi all, >>>> >> >>>> >> My two cents. >>>> >> >>>> >>> 2) Extend alembic so that op.drop_column() does the right thing >>>> >> We could, but should we? >>>> >> >>>> >> The only reason alembic doesn't support these operations for SQLite >>>> >> yet is that SQLite lacks proper support of ALTER statement. For >>>> >> sqlalchemy-migrate we've been providing a work-around in the form of >>>> >> recreating of a table and copying of all existing rows (which is a >>>> >> hack, really). >>>> >> >>>> >> But to be able to recreate a table, we first must have its >>>> definition. >>>> >> And we've been relying on SQLAlchemy schema reflection facilities for >>>> >> that. Unfortunately, this approach has a few drawbacks: >>>> >> >>>> >> 1) SQLAlchemy versions prior to 0.8.4 don't support reflection of >>>> >> unique constraints, which means the recreated table won't have them; >>>> >> >>>> >> 2) special care must be taken in 'edge' cases (e.g. when you want to >>>> >> drop a BOOLEAN column, you must also drop the corresponding CHECK >>>> (col >>>> >> in (0, 1)) constraint manually, or SQLite will raise an error when >>>> the >>>> >> table is recreated without the column being dropped) >>>> >> >>>> >> 3) special care must be taken for 'custom' type columns (it's got >>>> >> better with SQLAlchemy 0.8.x, but e.g. in 0.7.x we had to override >>>> >> definitions of reflected BIGINT columns manually for each >>>> >> column.drop() call) >>>> >> >>>> >> 4) schema reflection can't be performed when alembic migrations are >>>> >> run in 'offline' mode (without connecting to a DB) >>>> >> ... >>>> >> (probably something else I've forgotten) >>>> >> >>>> >> So it's totally doable, but, IMO, there is no real benefit in >>>> >> supporting running of schema migrations for SQLite. >>>> >> >>>> >>> ...attempts to drop schema generation based on models in favor of >>>> migrations >>>> >> &
Re: [openstack-dev] [savanna] Undoing a change in the alembic migrations
Just to clarify, new migration scripts should be added. You can find details on how to do it here - https://github.com/openstack/savanna/blob/master/savanna/db/migration/alembic_migrations/README On Thu, Jan 30, 2014 at 8:16 AM, Alexander Ignatov wrote: > Yes, you need create new migration script. Btw, we already have started > doing this. > The first example was when Jon added 'neutron' param to the > 'job_execution' object: > > https://review.openstack.org/#/c/63517/17/savanna/db/migration/alembic_migrations/versions/002_add_job_exec_extra.py > > Regards, > Alexander Ignatov > > > > On 30 Jan 2014, at 02:25, Andrew Lazarev wrote: > > +1 on new migration script. Just to be consecutive. > > Andrew. > > > On Wed, Jan 29, 2014 at 2:17 PM, Trevor McKay wrote: > >> Hi Sergey, >> >> In https://review.openstack.org/#/c/69982/1 we are moving the >> 'main_class' and 'java_opts' fields for a job execution into the >> job_configs['configs'] dictionary. This means that 'main_class' and >> 'java_opts' don't need to be in the database anymore. >> >> These fields were just added in the initial version of the migration >> scripts. The README says that migrations work "from icehouse". Since >> this is the initial script, does that mean we can just remove references >> to those fields from the db models and the script, or do we need a new >> migration script (002) to erase them? >> >> Thanks, >> >> Trevor >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] Specific job type for streaming mapreduce? (and someday pipes)
I like the dot-separated name. There are several reasons for it: * it'll not require changes in all Savanna subprojects; * eventually we'd like to use not only Oozie for EDP (for example, if we'll support Twitter Storm) and this new tools could require additional 'subtypes'. Thanks for catching this. On Tue, Feb 4, 2014 at 10:47 PM, Trevor McKay wrote: > Thanks Andrew. > > My author thought, which is in between, is to allow dotted types. > "MapReduce.streaming" for example. > > This gives you the subtype flavor but keeps all the APIs the same. > We just need a wrapper function to separate them when we compare types. > > Best, > > Trevor > > On Mon, 2014-02-03 at 14:57 -0800, Andrew Lazarev wrote: > > I see two points: > > * having Savanna types mapped to Oozie action types is intuitive for > > hadoop users and this is something we would like to keep > > * it is hard to distinguish different kinds of one job type > > > > > > Adding 'subtype' field will solve both problems. Having it optional > > will not break backward compatibility. Adding database migration > > script is also pretty straightforward. > > > > > > Summarizing, my vote is on "subtype" field. > > > > > > Thanks, > > Andrew. > > > > > > On Mon, Feb 3, 2014 at 2:10 PM, Trevor McKay > > wrote: > > > > I was trying my best to avoid adding extra job types to > > support > > mapreduce variants like streaming or mapreduce with pipes, but > > it seems > > that adding the types is the simplest solution. > > > > On the API side, Savanna can live without a specific job type > > by > > examining the data in the job record. Presence/absence of > > certain > > things, or null values, etc, can provide adequate indicators > > to what > > kind of mapreduce it is. Maybe a little bit subtle. > > > > But for the UI, it seems that explicit knowledge of what the > > job is > > makes things easier and better for the user. When a user > > creates a > > streaming mapreduce job and the UI is aware of the type later > > on at job > > launch, the user can be prompted to provide the right configs > > (i.e., the > > streaming mapper and reducer values). > > > > The explicit job type also supports validation without having > > to add > > extra flags (which impacts the savanna client, and the JSON, > > etc). For > > example, a streaming mapreduce job does not require any > > specified > > libraries so the fact that it is meant to be a streaming job > > needs to be > > known at job creation time. > > > > So, to that end, I propose that we add a MapReduceStreaming > > job type, > > and probably at some point we will have MapReducePiped too. > > It's > > possible that we might have other job types in the future too > > as the > > feature set grows. > > > > There was an effort to make Savanna job types parallel Oozie > > action > > types, but in this case that's just not possible without > > introducing a > > "subtype" field in the job record, which leads to a database > > migration > > script and savanna client changes. > > > > What do you think? > > > > Best, > > > > Trevor > > > > > > > > _______ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] savann-ci, Re: [savanna] Alembic migrations and absence of DROP column in sqlite
> >> >>> >> >>> On Sat, Feb 1, 2014 at 2:19 AM, Boris Pavlovic < >> bpavlo...@mirantis.com> >> >>> wrote: >> >>>> >> >>>> Jay, >> >>>> >> >>>> Yep we shouldn't use migrations for sqlite at all. >> >>>> >> >>>> The major issue that we have now is that we are not able to ensure >> that DB >> >>>> schema created by migration & models are same (actually they are not >> same). >> >>>> >> >>>> So before dropping support of migrations for sqlite & switching to >> model >> >>>> based created schema we should add tests that will check that model & >> >>>> migrations are synced. >> >>>> (we are working on this) >> >>>> >> >>>> >> >>>> >> >>>> Best regards, >> >>>> Boris Pavlovic >> >>>> >> >>>> >> >>>> On Fri, Jan 31, 2014 at 7:31 PM, Andrew Lazarev < >> alaza...@mirantis.com> >> >>>> wrote: >> >>>>> >> >>>>> Trevor, >> >>>>> >> >>>>> Such check could be useful on alembic side too. Good opportunity for >> >>>>> contribution. >> >>>>> >> >>>>> Andrew. >> >>>>> >> >>>>> >> >>>>> On Fri, Jan 31, 2014 at 6:12 AM, Trevor McKay >> wrote: >> >>>>>> >> >>>>>> Okay, I can accept that migrations shouldn't be supported on >> sqlite. >> >>>>>> >> >>>>>> However, if that's the case then we need to fix up >> savanna-db-manage so >> >>>>>> that it checks the db connection info and throws a polite error to >> the >> >>>>>> user for attempted migrations on unsupported platforms. For >> example: >> >>>>>> >> >>>>>> "Database migrations are not supported for sqlite" >> >>>>>> >> >>>>>> Because, as a developer, when I see a sql error trace as the >> result of >> >>>>>> an operation I assume it's broken :) >> >>>>>> >> >>>>>> Best, >> >>>>>> >> >>>>>> Trevor >> >>>>>> >> >>>>>> On Thu, 2014-01-30 at 15:04 -0500, Jay Pipes wrote: >> >>>>>>> On Thu, 2014-01-30 at 14:51 -0500, Trevor McKay wrote: >> >>>>>>>> I was playing with alembic migration and discovered that >> >>>>>>>> op.drop_column() doesn't work with sqlite. This is because >> sqlite >> >>>>>>>> doesn't support dropping a column (broken imho, but that's >> another >> >>>>>>>> discussion). Sqlite throws a syntax error. >> >>>>>>>> >> >>>>>>>> To make this work with sqlite, you have to copy the table to a >> >>>>>>>> temporary >> >>>>>>>> excluding the column(s) you don't want and delete the old one, >> >>>>>>>> followed >> >>>>>>>> by a rename of the new table. >> >>>>>>>> >> >>>>>>>> The existing 002 migration uses op.drop_column(), so I'm assuming >> >>>>>>>> it's >> >>>>>>>> broken, too (I need to check what the migration test is doing). >> I >> >>>>>>>> was >> >>>>>>>> working on an 003. >> >>>>>>>> >> >>>>>>>> How do we want to handle this? Three good options I can think >> of: >> >>>>>>>> >> >>>>>>>> 1) don't support migrations for sqlite (I think "no", but maybe) >> >>>>>>>> >> >>>>>>>> 2) Extend alembic so that op.drop_column() does the right thing >> >>>>>>>> (more >> >>>>>>>> open-source contributions for us, yay :) ) >> >>>>>>>> >> >>>>>>>> 3) Add our own wrapper in savanna so that we have a drop_column() >> >>>>>>>> method >> >>>>>>>> that wraps copy/rename. >> >>>>>>>> >> >>>>>>>> Ideas, comments? >> >>>>>>> >> >>>>>>> Migrations should really not be run against SQLite at all -- only >> on >> >>>>>>> the >> >>>>>>> databases that would be used in production. I believe the general >> >>>>>>> direction of the contributor community is to be consistent around >> >>>>>>> testing of migrations and to not run migrations at all in unit >> tests >> >>>>>>> (which use SQLite). >> >>>>>>> >> >>>>>>> Boris (cc'd) may have some more to say on this topic. >> >>>>>>> >> >>>>>>> Best, >> >>>>>>> -jay >> >>>>>>> >> >>>>>>> >> >>>>>>> ___ >> >>>>>>> OpenStack-dev mailing list >> >>>>>>> OpenStack-dev@lists.openstack.org >> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> ___ >> >>>>>> OpenStack-dev mailing list >> >>>>>> OpenStack-dev@lists.openstack.org >> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> ___ >> >>>> OpenStack-dev mailing list >> >>>> OpenStack-dev@lists.openstack.org >> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>> >> >>> >> >>> >> >>> ___ >> >>> OpenStack-dev mailing list >> >>> OpenStack-dev@lists.openstack.org >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>> >> >> >> >> ___ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing
Hi Jay, it's really very easy to setup Zuul for it (we're using one for Savanna CI). There are some useful links: * check pipeline as an example of zuul layout configuration - https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml#L5 * zuul docs - http://ci.openstack.org/zuul/ * zuul config sample - https://github.com/openstack-infra/zuul/blob/master/etc/zuul.conf-sample So, I think that it could be easy enough to setup Zuul for 3rd party testing, but it'll be better to have some doc about it. Thanks. On Wed, Feb 5, 2014 at 3:55 AM, Jay Pipes wrote: > Sorry for cross-posting to both mailing lists, but there's lots of folks > working on setting up third-party testing platforms that are not members > of the openstack-infra ML... > > tl;dr > - > > The third party testing documentation [1] has requirements [2] that > include the ability to trigger a recheck based on a gerrit comment. > > Unfortunately, the Gerrit Jenkins Trigger plugin [3] does not have the > ability to trigger job runs based on a regex-filtered comment (only on > the existence of any new comment to the code review). > > Therefore, we either should: > > a) Relax the requirement that the third party system trigger test > re-runs when a comment including the word "recheck" appears in the > Gerrit event stream > > b) Modify the Jenkins Gerrit plugin to support regex filtering on the > comment text (in the same way that it currently supports regex filtering > on the project name) > > or > > c) Add documentation to the third party testing pages that explains how > to use Zuul as a replacement for the Jenkins Gerrit plugin. > > I propose we do a) for the short term, and I'll work on c) long term. > However, I'm throwing this out there just in case there are some Java > and Jenkins whizzes out there that could get b) done in a jiffy. > > details > --- > > OK, so I've been putting together documentation on how to set up an > external Jenkins platform that is "linked" [4] with the upstream > OpenStack CI system. > > Recently, I wrote an article detailing how the upstream CI system > worked, including a lot of the gory details from the > openstack-infra/config project's files. [5] > > I've been working on a follow-up article that goes through how to set up > a Jenkins system, and in writing that article, I created a source > repository [6] that contains scripts, instructions and Puppet modules > that set up a Jenkins system, the Jenkins Job Builder tool, and > installs/configures the Jenkins Gerrit plugin [7]. > > I planned to use the Jenkins Gerrit plugin as the mechanism that > triggers Jenkins jobs on the external system based on gerrit events > published by the OpenStack review.openstack.org Gerrit service. In > addition to being mentioned in the third party documentation, Jenkins > Job Builder has the ability to construct Jenkins jobs that are triggered > by the Jenkins Gerrit plugin [8]. > > Unforunately, I've run into a bit of a snag. > > The third party testing documentation has requirements that include the > ability to trigger a recheck based on a gerrit comment: > > > Support recheck to request re-running a test. > * Support the following syntaxes recheck no bug and recheck bug ###. > * Recheck means recheck everything. A single recheck comment should > re-trigger all testing systems. > > > The documentation has a section on using the Gerrit Jenkins Trigger > plugin [3] to accept notifications from the upstream OpenStack Gerrit > instance. > > But unfortunately, the Jenkins Gerrit plugin does not support the > ability to trigger a re-run of a job given a regex match of the word > "recheck". :( > > So, we either need to a) change the requirements of third party testers, > b) enhance the Jenkins Gerrit plugin with the missing functionality, or > c) add documentation on how to set up Zuul as the triggering system > instead of the Jenkins Gerrit plugin. > > I'm happy to work on c), but I think relaxing the restriction (a) is > probably needed short-term. > > Best, > -jay > > [1] http://ci.openstack.org/third_party.html > [2] http://ci.openstack.org/third_party.html#requirements > [3] > > http://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way > [4] By "linked" I mean it both reads from the OpenStack Gerrit system > and writes (adds comments) to it > [5] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ > [6] http://github.com/jaypipes/os-ext-testing > [7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigge
Re: [openstack-dev] [Climate] 0.1.0 release
Great progress! My congratulations. On Wed, Feb 5, 2014 at 3:36 PM, Dina Belova wrote: > Hi, folks! > > Today Climate has been released first time and I'm really glad to say that > :) > > This release implements following use cases: > >- User wants to reserve virtual machine and use it later. He/she asks >Nova to create server, passing special hints, describing information like >lease start and end time. In this case instance will be not just booted, >but also shelved not to use cloud resources when it's not needed. At the >time user passed as 'lease start time' instance will be unshelled and used >as user wants to. User may define different actions that might happen to >instance at lease end - like snapshoting or/and suspending or/and removal. >- User wants to reserve compute capacity of whole compute host to use >it later. In this case he/she asks Climate to provide host with passed >characteristics from predefined pool of hosts (that is managed by admin >user). If this request might be processed, user will have the opportunity >run his/her instances on reserved host when lease starts. > > > Here are our release notes: > Climate/Release_Notes/0.1.0<https://wiki.openstack.org/wiki/Climate/Release_Notes/0.1.0> > > Other useful links: > >- Climate Wiki <https://wiki.openstack.org/wiki/Climate> >- Climate Launchpad <https://launchpad.net/climate> >- Future plans for 0.2.x <https://etherpad.openstack.org/p/climate-0.2> > > > Thanks all team who worked on Climate 0.1.0 and everybody who helped us! > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > _______ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Barbican Incubation Review
Probably, while you're not incubated, it'll be better to place this code into your repo (example: https://github.com/stackforge/solum/tree/master/contrib/devstack). On Sat, Feb 1, 2014 at 5:43 AM, Chad Lung wrote: > > This is a follow-up to Jarret Raim's email regarding Barbican's incubation > review: > > http://lists.openstack.org/pipermail/openstack-dev/2014-January/025860.html > > Please note that the PR for Barbican's DevStack integration can now be > found here: > > https://review.openstack.org/#/c/70512/ > > Thanks for any feedback or comments. > > Chad Lung > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] project name collision - renaming required
Hi folks, As part of preparations for graduation from incubation [0], I've contacted OpenStack Foundation Marketing team to ensure that everything is ok with our program and project names from their point of view. Thanks for Lauren Sell for providing info. Thetus Corporation already use 'Savanna' as the name for one of their technologies [1]. Thetus doesn't actually hold any registered trademark for 'Savanna', but they have common-law rights to the mark because they have established use and marketed it since 2010, so, in case if we applied for a trademark, they could certainly challenge us and win. So, the answer from marketing team was that it's a pretty high risk to continue using our lovely name... The most sad part is that I couldn't google their site using words savanna, hadoop, cloud and etc. Let's move on to the new name selection process. I'm proposing one or two weeks for brainstorming and sharing your thoughts about the project name depending on number of suitable options, then I'll probably setup the small voting to select the best option. I've created an etherpad [2] for discussing new name options, so, the process is send your options to this thread and then go to the etherpad [2] to discuss them. Please, don't forget to google your options to avoid one more renaming in future ;) Thanks, looking forward for you thoughts. [0] http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements- "Project should have engaged with marketing team to check suitable official name" [1] http://www.thetus.com/savanna [2] https://etherpad.openstack.org/p/savanna-renaming -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] team meeting Jan 30 1800 UTC
Hi folks, We'll be having the Savanna team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_January.2C_30 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20140130T18 P.S. The main topic will be Savanna project renaming. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] How to handle diverging EDP job configuration settings
fit of running apps.
> >>>>
> >>>> What if we allow "savanna." settings to be added to configs? If we do
> >>>> that, any and all special configuration settings for specific job
> types
> >>>> or subtypes can be handled with no database changes and no api
> changes.
> >>>>
> >>>> Downside
> >>>>
> >>>> Currently, all 'configs' are rendered in the generated oozie workflow.
> >>>> The "savanna." settings would be stripped out and processed by
> Savanna,
> >>>> thereby changing that behavior a bit (maybe not a big deal)
> >>>>
> >>>> We would also be mixing "savanna." configs with config_hints for jobs,
> >>>> so users would potentially see "savanna." settings mixed with
> oozie
> >>>> and hadoop settings. Again, maybe not a big deal, but it might blur
> the
> >>>> lines a little bit. Personally, I'm okay with this.
> >>>>
> >>>> Slightly different
> >>>> --
> >>>> We could also add a "'savanna-configs': {}" element to job_configs to
> >>>> keep the configuration spaces separate.
> >>>>
> >>>> But, now we would have 'savanna-configs' (or another name), 'configs',
> >>>> 'params', and 'args'. Really? Just how many different types of values
> >>>> can we come up with? :)
> >>>>
> >>>> I lean away from this approach.
> >>>>
> >>>> Related: breaking up the superset
> >>>> -
> >>>>
> >>>> It is also the case that not every job type has every value type.
> >>>>
> >>>>Configs ParamsArgs
> >>>> HiveY YN
> >>>> Pig Y YY
> >>>> MapReduce Y NN
> >>>> Java Y N Y
> >>>>
> >>>> So do we make that explicit in the docs and enforce it in the api with
> >>>> errors?
> >>>>
> >>>> Thoughts? I'm sure there are some :)
> >>>>
> >>>> Best,
> >>>>
> >>>> Trevor
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ___
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev@lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>> ___
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Lots of gating failures because of testtools
I've proposed temp fix for global requirements: https://review.openstack.org/#/c/69840/, it's not the best solution, but looks like the only one now. logstash link: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOiBcIkltcG9ydEVycm9yOiBjYW5ub3QgaW1wb3J0IG5hbWUgYWxsXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjkwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjEzOTA5OTMwMjU5MDF9 On Wed, Jan 29, 2014 at 3:18 PM, Matthieu Huin wrote: > Thanks so much for figuring this out, I was very puzzled by that this > morning,trying to run keystone tests on my local copy ! > > Matthieu Huin > > m...@enovance.com > > - Original Message - > > From: "Ivan Melnikov" > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > > Sent: Wednesday, January 29, 2014 12:07:13 PM > > Subject: [openstack-dev] [all] Lots of gating failures because of > testtools > > > > Hi there, > > > > I see lots of unit tests jobs on gate fail with errors like > > > > 2014-01-29 10:48:44.933 | File > > > "/home/jenkins/workspace/gate-taskflow-python26/.tox/py26/lib/python2.6/site-packages/subunit/test_results.py", > > line 23, in > > 2014-01-29 10:48:44.934 | from testtools.compat import all > > 2014-01-29 10:48:44.935 | ImportError: cannot import name all > > 2014-01-29 10:48:44.992 | ERROR: InvocationError: > > '/home/jenkins/workspace/gate-taskflow-python26/.tox/py26/bin/python > > setup.py testr --slowest --testr-args=' > > > > Looks like subunit is not compatible with just-released testtools > > 0.9.35. I guess we will need to pin testtools to 0.9.34 in > > test-requirements.txt. Or there are better solution? > > > > I filed a bug to subunit upstream: > > https://bugs.launchpad.net/subunit/+bug/1274056 > > > > I also filed a bug for taskflow, feel free to add your projects there if > > it's affected, too: https://bugs.launchpad.net/taskflow/+bug/1274050 > > > > -- > > WBR, > > Ivan A. Melnikov > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [savanna] savannaclient v2 api
FYI, the code contains comments suggesting it should be > >>>>plugin specific. > >>>> > >>>> > https://github.com/openstack/savanna/blob/master/savanna/service/edp/workflow_creator/workflow_factory.py#L179 > >>>>< > https://github.com/openstack/__savanna/blob/master/savanna/__service/edp/workflow_creator/__workflow_factory.py#L179 > > > >>>> > >>>>< > https://github.com/openstack/__savanna/blob/master/savanna/__service/edp/workflow_creator/__workflow_factory.py#L179 > >>>>< > https://github.com/openstack/savanna/blob/master/savanna/service/edp/workflow_creator/workflow_factory.py#L179 > >> > >>>> > >>>> IMHO, the EDP should have no plugin specific dependencies. > >>>> > >>>> If it currently does, we should look into why and see if > we > >>>>can't > >>>> eliminate this entirely. > >>>> > >>>>[AL] EDP uses plugins in two ways: > >>>>1. for HDFS user > >>>>2. for config hints > >>>>I think both items should not be plugin specific on EDP API > >>>>level. But > >>>>implementation should go to plugin and call plugin API for > result. > >>>> > >>>> > >>>>In fact they are both plugin specific. The user is forced to click > >>>>through a plugin selection (when launching a job on transient > >>>>cluster) or the plugin selection has already occurred (when > >>>>launching a job on an existing cluster). > >>>> > >>>>Since the config is something that is plugin specific, you might > not > >>>>have hbase hints from vanilla but you would from hdp, and you > >>>>already have plugin information whenever you ask for a hint, my > view > >>>>that this be under the /plugins namespace is growing stronger. > >>>> > >>>> > >>>> [AL] Disagree. They are plugin specific, but EDP itself could have > >>>> additional plugin-independent logic inside. Now config hints return > EDP > >>>> properties (like mapred.input.dir) as well as plugin-specific > >>>> properties. Placing it under /plugins namespace will give a vision > that > >>>> it is fully plugin specific. > >>>> > >>>> I like to see EDP API fully plugin independent and in one workspace. > If > >>>> core side needs some information internally it can easily go into the > >>>> plugin. > >>> > >>> I'm not sure if we're disagreeing. We may, in fact, be in violent > agreement. > >>> > >>> The EDP API is fully plugin independent, and should stay that way as a > project goal. config-hints is extra data that the horizon app can use to > help give users suggestions about what config they may want to optionally > add to their job. Those config options are independent of the job and > specific to the cluster where the job will run, which is the purview of the > plugin. > >>> > >>> Moving config-hints out of the EDP API will make this even more clear. > >>> > >>> Best, > >>> > >>> > >>> matt > >>> > >>> ___ > >>> OpenStack-dev mailing list > >>> OpenStack-dev@lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] Future 0.2 release scope discussion
I think that firstly you should define the policy / approach for choosing the date for the next release. At least it should be clear which is more important - release data or scope. On Thu, Jan 23, 2014 at 9:07 PM, Dina Belova wrote: > Hello folks :) > > We've started accumulating ideas for 0.2 release. Here is link to Etherpad: > > https://etherpad.openstack.org/p/climate-0.2 > > You are welcome to suggest ideas :) > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
