Re: [OpenStack-Infra] Biting the bullet on issue tracking

[Marton Kiss]

Hi,

Do we have a report about the major features we are missing from
Storyboard? As an SB user I missing those:
- proper notification system (email and / or in-app messages)
- story-id workflow integration with gerrit

Except this two, I don't have other concerns, I see smaller bugs that can
be fixed with a little work. I suggest to throw a little money to finish
those open issues in a reasonable time instead of jumping into unknown
again.

Brgds,
  Marton

2015-03-24 6:29 GMT+01:00 Christian Berendt :

> On 03/24/2015 12:02 AM, Monty Taylor wrote:
>
>> That is no longer true. Existing Open Source offerings not only can
>> represent a large portion of our data needs, but additionally can
>> support the additional features that have been requested by our
>> community today out of the box.
>>
>
> Monty, can you please list the appropriate alternatives?
>
> Christian.
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Biting the bullet on issue tracking

[Ricardo Carrillo Cruz]

Hey Michael

It's a shame we are getting rid of SB, it's an amazing kit of software.
I'm hoping we will be able to continue developing it, maybe not being the
main issue tracker for OpenStack now will allow the project become
what it was envisioned.

You have been a great lead and I am looking forward to work with you again
soon.

Kind regards

2015-03-24 0:28 GMT+01:00 Michael Krotscheck :

> Hey everyone!
>
> It's quite rough to realize that the thing you've been advocating, working
> on, and desperately trying to recruit contributors for is DoA, and that's
> what I've been struggling with for the past few weeks. Even so, I was part
> and parcel to coming up with Monty's recommendation, so this wasn't a
> surprise.
>
> Don't get me wrong: I love the project. I love the team, I love our
> technological vision, I love all these things. There are features that I
> feel are unique - Federation, process-agnosticism, clean api/ui separation,
> etc. - and given the opportunity (and proper resources) I would love to
> continue working on it. However for all the excitement that I've received
> over the past year, very little has solidified into any kind of concrete
> contribution. It was time to call the bluff.
>
> And yet... StoryBoard has been a fantastic test bed for JavaScript as a
> first class citizen in OpenStack, and I'm going to continue moving that
> forward. There are some missing parts of our infrastructure, some of our
> existing tools need to be refined and documented, and there are some sticky
> policy items that need to be proposed to the TC. I see no reason not to
> continue supporting StoryBoard as that test bed, especially since the
> infrastructure team is still using it. Once a reasonable sunset has been
> reached (assuming new contributors don't magically materialize), my plan is
> to dive into the other UI components in OpenStack.
>
> A very special thank you Yolanda Robla-Mota, Mike Heald, Riccardo Cruz,
> Nikita Konovalov, Aleksey Ripinien, Tom Pollard, and all the others who
> have contributed over the past year. Y'all are awesome.
>
> Michael
>
> On Mon, Mar 23, 2015 at 4:03 PM Monty Taylor  wrote:
>
>> Hi everybody,
>>
>> First, some background:
>>
>> A year and a half ago, Infra started down the road of of writing a
>> replacement for the pieces of Launchpad that OpenStack continues to use.
>> There were several reasons, but notable amongst them are:
>>
>> - Desire to use the forthcoming openstackid OpenID/Oauth as an SSO
>> - Delay in long-standing bugs that affect OpenStack getting fixed
>>
>> The existing open source offerings that we investigated did not have
>> adequate feature parity in the key data model areas that made Launchpad
>> particularly compelling as a choice for us, and adding what we needed to
>> the existing offerings would amount to substantial rewrites ... so we
>> decided that we had no real choice but to write our own.
>>
>> Where we're at
>>
>> We've gotten far enough to get Infra moved on to storyboard, but the
>> project has never really gotten resourced to the level it needs to be to
>> truly responsive to the needs of our community. We're making good
>> progress towards meeting the initial set of goals we set, but in the
>> mean time several new requests have come in - such as from the UX team
>> and the Product Management Working Group - that we cannot meet today and
>> which at our current rate I do not believe we would be able to meet in a
>> reasonable timeframe.
>>
>> At the same time, the state of the art around us has improved since we
>> started. A year and a half ago, I was able to very honestly say that we
>> needed to work on this effort because we simply had no other choice.
>> That is no longer true. Existing Open Source offerings not only can
>> represent a large portion of our data needs, but additionally can
>> support the additional features that have been requested by our
>> community today out of the box.
>>
>> The combination of the two of those makes the likelihood of us being
>> able to convince people to pony up more resources seem more and more far
>> fetched. I could be wrong, of course - it's possible that in response to
>> this someone will start jumping up and down and commit engineers to the
>> effort ... but I'm not holding my breath.
>>
>> Biting the bullet
>>
>> I think we should get out of the business of writing our own bug tracker.
>>
>> It's not an easy thing to say, and I don't say it lightly. There are
>> things that storyboard models well that continue to be things that
>> simply are not modeled elsewhere. However, I think it's important to
>> know when good enough will do, and I think it's important to be able to
>> step up and say that we tried valiantly, and everyone involved did a
>> great job, and yet the world has moved on and writing a bug tracker is
>> not, at the end of the day, what we're all here to do.
>>
>> We're looking at what our options are, and Thierry is examining them to
>> see how tolerable their d

Re: [OpenStack-Infra] Fwd: Biting the bullet on issue tracking

[Yolanda Robla Mota]

Hi
So i'm sad to see a project like StoryBoard not arrive to a good end, 
but I understand the decisions that lead to that. With the amount of 
dedicated resources to StoryBoard, it was very complicated to provide 
same features as other open source alternatives, and may be a better 
option to collaborate with other open source projects.
Thanks Michael for all of your support, and make it easy to contribute 
in StoryBoard. You've been incredibly supportive, and helped me to start 
contributing to the project and gain confidence on that. You rock!
Finally, I think these efforts have not been in vain, because as Michael 
says, we've setup the basis for a successful development using AngularJS 
and best practices there, that can be used as a start point for another 
projects.


It has been a pleasure to work with you all. Best
Yolanda




-- Forwarded message --
From: *Michael Krotscheck* >

Date: 2015-03-24 0:28 GMT+01:00
Subject: Re: [OpenStack-Infra] Biting the bullet on issue tracking
To: openstack-infra@lists.openstack.org 




Hey everyone!

It's quite rough to realize that the thing you've been advocating, 
working on, and desperately trying to recruit contributors for is DoA, 
and that's what I've been struggling with for the past few weeks. Even 
so, I was part and parcel to coming up with Monty's recommendation, so 
this wasn't a surprise.


Don't get me wrong: I love the project. I love the team, I love our 
technological vision, I love all these things. There are features that 
I feel are unique - Federation, process-agnosticism, clean api/ui 
separation, etc. - and given the opportunity (and proper resources) I 
would love to continue working on it. However for all the excitement 
that I've received over the past year, very little has solidified into 
any kind of concrete contribution. It was time to call the bluff.


And yet... StoryBoard has been a fantastic test bed for JavaScript as 
a first class citizen in OpenStack, and I'm going to continue moving 
that forward. There are some missing parts of our infrastructure, some 
of our existing tools need to be refined and documented, and there are 
some sticky policy items that need to be proposed to the TC. I see no 
reason not to continue supporting StoryBoard as that test bed, 
especially since the infrastructure team is still using it. Once a 
reasonable sunset has been reached (assuming new contributors don't 
magically materialize), my plan is to dive into the other UI 
components in OpenStack.


A very special thank you Yolanda Robla-Mota, Mike Heald, Riccardo 
Cruz, Nikita Konovalov, Aleksey Ripinien, Tom Pollard, and all the 
others who have contributed over the past year. Y'all are awesome.


Michael

On Mon, Mar 23, 2015 at 4:03 PM Monty Taylor > wrote:


Hi everybody,

First, some background:

A year and a half ago, Infra started down the road of of writing a
replacement for the pieces of Launchpad that OpenStack continues
to use.
There were several reasons, but notable amongst them are:

- Desire to use the forthcoming openstackid OpenID/Oauth as an SSO
- Delay in long-standing bugs that affect OpenStack getting fixed

The existing open source offerings that we investigated did not have
adequate feature parity in the key data model areas that made
Launchpad
particularly compelling as a choice for us, and adding what we
needed to
the existing offerings would amount to substantial rewrites ... so we
decided that we had no real choice but to write our own.

Where we're at

We've gotten far enough to get Infra moved on to storyboard, but the
project has never really gotten resourced to the level it needs to
be to
truly responsive to the needs of our community. We're making good
progress towards meeting the initial set of goals we set, but in the
mean time several new requests have come in - such as from the UX team
and the Product Management Working Group - that we cannot meet
today and
which at our current rate I do not believe we would be able to
meet in a
reasonable timeframe.

At the same time, the state of the art around us has improved since we
started. A year and a half ago, I was able to very honestly say
that we
needed to work on this effort because we simply had no other choice.
That is no longer true. Existing Open Source offerings not only can
represent a large portion of our data needs, but additionally can
support the additional features that have been requested by our
community today out of the box.

The combination of the two of those makes the likelihood of us being
able to convince people to pony up more resources seem more and
more far
fetched. I could be wrong, of course - it's possible that in
response to
this someone will start jumping up 

Re: [OpenStack-Infra] Biting the bullet on issue tracking

[Thierry Carrez]

Monty Taylor wrote:
> [...]
> We're looking at what our options are, and Thierry is examining them to
> see how tolerable their differences would be to our community.
> 
> I propose that we have a solid answer and migration plan to put in front
> of people by Vancouver at the latest.

StoryBoard was started initially as a proof-of-concept of what we'd
actually love to see in the tool we use for task tracking. I was writing
requirements documents to help the Infra team look into alternate
solutions, and finally decided that code could be worth a thousand words.

At that point, people got very excited at the idea of having a tool that
would precisely map our workflows and processes, rather than having a
tool you have to adapt your workflows and processes to. Let's use the
POC today! Since that initial excitement, three things happened.

(1) We realized coding the task tracking part is not really long or
difficult. It's all the boring infrastructure that is long and painful:
subscriptions, configurable email notifications, ACLs...

(2) We did not get the surge in contributors we expected to get. The
StoryBoard API server is built like an OpenStack API server to increase
dev familiarity, but HP and Mirantis were the only ones to dedicate
headcount to the effort.

(3) With StoryBoard being developed not as fast as we hoped, time
passed, some requirements changed, new teams have needs, and those are
not necessarily easily served with a beta tool.

So we are standing at the crossroads again.

First, we need to determine if we are ready to accept to use a tool that
is not tailored-fit to our workflows, in exchange for more immediate
gratification. That is what the "Biting the bullet" from Monty is about.
It's not an easy thing to do... after all the reason we want to move
away from Launchpad is the pain derived from using a tool that does not
fit our workflows and processes.

Second, we need to see which solution is the closest to "being usable
for us", and therefore should be the way forward. When you work on a
single project team, it's easy to overlook that we have a pretty unique
set of needs in OpenStack -- the ability to efficiently track tasks
across a large set of projects and branches (for our horizontal teams
sanity). Not all tools can be used like that. In fact, before we started
StoryBoard, Launchpad was still the best tool for that.

Personally I'm not totally convinced StoryBoard is out of the race. We
may realize that the amount of custom development needed to bring
existing solutions to a point where we can use them for task tracking in
OpenStack is superior to the amount of development needed to bring
StoryBoard at an acceptable usability level. But then, I don't
personally wield any significant development headcount, so I can't make
the choice: I can only define what "usable for OpenStack" minimally means.

It's also worth noting that Launchpad is not (yet) out of the game. It
could grow the set of features we need (ability to auth using
OpenStackID, multi-task features with tags and comments, task
dashboards, no more silly timeouts, comprehensive API...). Unlikely, but
still possible :)

I look forward to that discussion in Vancouver on the future of task
tracking in OpenStack.

-- 
Thierry Carrez (ttx)

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

Re: [OpenStack-Infra] enforce bug ids in commit message

[Darragh Bailey]

I believe the its-* plugins for gerrit could handle this for you, recently
someone mentioned on the repo mailing list that you can even exclude
branches from the requirement.

I'd suggest asking there directly if you haven't already.

Darragh
On 23 Mar 2015 22:17, "Jeremy Stanley"  wrote:

> On 2015-03-23 12:00:26 +0530 (+0530), Vinay Mahuli wrote:
> > I need info on where to make this change in a similar way how
> > Change-Id is checked/validated.
>
> "Require Change-Id in commit message" is a project-specific setting
> built into Gerrit by default.
>
>  https://gerrit-review.googlesource.com/Documentation/project-configuration.html#_require_change_id
> >
>
> Something similar may be possible by writing a Gerrit plug-in or a
> hook script, but it will almost certainly use a different mechanism
> as it won't be implemented directly in the Gerrit codebase as a
> built-in feature.
> --
> Jeremy Stanley
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-dev][cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)

[Mike Perez]

On 18:20 Mon 23 Mar , Diem Tran wrote:
> Hello Cinder team,
> 
> Oracle ZFSSA CI has been reporting since March 20th. Below is a link
> to the list of results the CI already posted:
> 
> https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z
> 
> Our CI system will be running and reporting results from now on,
> hence I kindly request that you accept our CI results and consider
> re-integrating our drivers back in Kilo RC.
> 
> If there is any concern, please let us know.

Diem,

I appreciate your team getting back to us on the CI. It appears your CI is
running 247 tests, when it should be running 304. Please verify you're running
tempest as followed in the instructions here:

https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

Once this issue is resolved, I'll continue to monitor the stability, and based
on that make a decision for readding the driver.

-- 
Mike Perez

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

Re: [OpenStack-Infra] enforce bug ids in commit message

[Zaro]

Yep, out of the box Gerrit commit hooks cannot block new patches from being
uploaded.  An alternative would be to immediately set the vote on the
patchset to Code-Review to -2 if the commit message doesn't match what you
want.  The hook script for something like that can be found here:
https://gerrit.googlesource.com/gerrit/+/master/contrib/check-valid-commit.py

-Khai

On Tue, Mar 24, 2015 at 12:27 PM, Darragh Bailey 
wrote:

> I believe the its-* plugins for gerrit could handle this for you, recently
> someone mentioned on the repo mailing list that you can even exclude
> branches from the requirement.
>
> I'd suggest asking there directly if you haven't already.
>
> Darragh
> On 23 Mar 2015 22:17, "Jeremy Stanley"  wrote:
>
>> On 2015-03-23 12:00:26 +0530 (+0530), Vinay Mahuli wrote:
>> > I need info on where to make this change in a similar way how
>> > Change-Id is checked/validated.
>>
>> "Require Change-Id in commit message" is a project-specific setting
>> built into Gerrit by default.
>>
>> > https://gerrit-review.googlesource.com/Documentation/project-configuration.html#_require_change_id
>> >
>>
>> Something similar may be possible by writing a Gerrit plug-in or a
>> hook script, but it will almost certainly use a different mechanism
>> as it won't be implemented directly in the Gerrit codebase as a
>> built-in feature.
>> --
>> Jeremy Stanley
>>
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Update "Intel PCI CI" account information

[Jiang, YuX Y]

Hi infra,
 I want to update the email address of CI account - "Intel PCI CI".
 Please help me to disable the old "Intel PCI CI" account. Thanks a lot!

The old information of that account are below:
Username: intelotccloud
Full Name: Intel PCI CI
Email address: otc_cl...@163.com
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra