Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation

[Ivan Kolodyazhny]

Hi all,

Auto-created bugs could help in this effort. Honestly, nobody can say will
it work or not before we try it.

>From a Horizon's perspective, we need to have some solution which helps us
to know about new features
that would be good to add them to UI in the future. We started with an
etherpad [1] as a first step for now.

[1] https://etherpad.openstack.org/p/horizon-feature-gap

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Thu, Aug 2, 2018 at 11:38 PM, Jeremy Stanley  wrote:

> On 2018-08-02 14:16:10 -0500 (-0500), Sean McGinnis wrote:
> [...]
> > Interesting... I hadn't looked into Gerrit functionality enough to know
> about
> > these. Looks like this is probably what you are referring to?
> >
> > https://gerrit.googlesource.com/plugins/its-storyboard/
>
> Yes, that. Khai Do (zaro) did the bulk of the work implementing it
> for us but isn't around as much these days (we miss you!).
>
> > It's been awhile since I did anything significant with Java, but that
> might be
> > an option. Maybe a fun weekend project at least to see what it would
> take to
> > create an its-launchpad plugin.
> [...]
>
> Careful; if you let anyone know you've touched a Gerrit plug-in the
> requests for more help will never end.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation

[Jeremy Stanley]

On 2018-08-02 14:16:10 -0500 (-0500), Sean McGinnis wrote:
[...]
> Interesting... I hadn't looked into Gerrit functionality enough to know about
> these. Looks like this is probably what you are referring to?
> 
> https://gerrit.googlesource.com/plugins/its-storyboard/

Yes, that. Khai Do (zaro) did the bulk of the work implementing it
for us but isn't around as much these days (we miss you!).

> It's been awhile since I did anything significant with Java, but that might be
> an option. Maybe a fun weekend project at least to see what it would take to
> create an its-launchpad plugin.
[...]

Careful; if you let anyone know you've touched a Gerrit plug-in the
requests for more help will never end.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation

[Sean McGinnis]

On Thu, Aug 02, 2018 at 05:56:23PM +, Jeremy Stanley wrote:
> On 2018-08-02 10:09:48 -0500 (-0500), Sean McGinnis wrote:
> [...]
> > I was able to find part of how that is implemented in jeepyb:
> > 
> > http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py
> [...]
> 
> As for the nuts and bolts here, the script you found is executed
> from a Gerrit hook every time a change merges:
> 
> https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/files/gerrit/change-merged
> 

Thanks, that's at least a place I can start looking!

> Gerrit hooks are a bit fragile but also terribly opaque (the only
> way to troubleshoot a failure is a Gerrit admin pouring over a noisy
> log file on the server looking for a Java backtrace). If you decide
> to do something automated to open bugs/stories when changes merge, I
> recommend a Zuul job. We don't currently have a pipeline definition
> which generates a distinct build set for every merged change (the
> post and promote pipelines do supercedent queuing rather than
> independent queuing these days) but it would be easy to add one that
> does.
> 
> It _could_ also be a candidate for a Gerrit ITS plug-in (there's one
> for SB but not for LP as far as I know), but implementing this would
> mean spending more time in Java than most of us care to experience.

Interesting... I hadn't looked into Gerrit functionality enough to know about
these. Looks like this is probably what you are referring to?

https://gerrit.googlesource.com/plugins/its-storyboard/

It's been awhile since I did anything significant with Java, but that might be
an option. Maybe a fun weekend project at least to see what it would take to
create an its-launchpad plugin.

Thanks for the pointers!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation

[Jeremy Stanley]

On 2018-08-02 10:09:48 -0500 (-0500), Sean McGinnis wrote:
[...]
> I was able to find part of how that is implemented in jeepyb:
> 
> http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py
[...]

As for the nuts and bolts here, the script you found is executed
from a Gerrit hook every time a change merges:

https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/files/gerrit/change-merged

Gerrit hooks are a bit fragile but also terribly opaque (the only
way to troubleshoot a failure is a Gerrit admin pouring over a noisy
log file on the server looking for a Java backtrace). If you decide
to do something automated to open bugs/stories when changes merge, I
recommend a Zuul job. We don't currently have a pipeline definition
which generates a distinct build set for every merged change (the
post and promote pipelines do supercedent queuing rather than
independent queuing these days) but it would be easy to add one that
does.

It _could_ also be a candidate for a Gerrit ITS plug-in (there's one
for SB but not for LP as far as I know), but implementing this would
mean spending more time in Java than most of us care to experience.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation

[Jay S Bryant]

On 8/2/2018 10:59 AM, Radomir Dopieralski wrote:
To be honest, I don't see much point in automatically creating bugs 
that nobody is going to look at. When you implement a new feature, 
it's up to you to make it available in Horizon and CLI and wherever 
else, since the people working there simply don't have the time to 
work on it. Creating a ticket will not magically make someone do that 
work for you. We are happy to assist with this, but that's it. 
Anything else is going to get added whenever someone has any free 
cycles, or it becomes necessary for some reason (like breaking 
compatibility). That's the current reality, and no automation is going 
to help with it.


I disagree with this view.  In the past there have been companies that 
have had people working on Horizon to keep it implemented for their 
purposes.  Have these bugs available would have made their work easier.  
I also know that there are people on the OSC team that just work on 
keeping functions implemented and up to date.


At a minimum, having these bugs automatically opened would help when 
someone is trying to figure out why the new function they are looking 
for is not available in OSC or Horizon.  A search would turn up the fact 
that it hasn't been implemented yet.  Currently, we frequently have the 
discussion 'Has that been implemented in Horizon yet?'  This would 
reduce the confusion around that subject.


So, I support trying to make this happen as I feel it moves us towards a 
better UX for OpenStack.


On Thu, Aug 2, 2018 at 5:09 PM Sean McGinnis > wrote:


I'm wondering if someone on the infra team can give me some
pointers on how to
approach something, and looking for any general feedback as well.

Background
==
We've had things like the DocImpact tag that could be added to
commit messages
that would tie into some automation to create a launchpad bug when
that commit
merged. While we had a larger docs team and out-of-tree docs, I
think this
really helped us make sure we didn't lose track of needed
documentation
updates.

I was able to find part of how that is implemented in jeepyb:


http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py

Current Challenge
=
Similar to the need to follow up with documentation, I've seen a
lot of cases
where projects have added features or made other changes that
impact downstream
consumers of that project. Most often, I've seen cases where
something like
python-cinderclient adds some functionality, but it is on projects
like Horizon
or python-openstackclient to proactively go out and discover those
changes.

Not only just seeking out those changes, but also evaluating
whether a given
change should have any impact on their project. So we've ended up
in a lot of
cases where either new functionality isn't made available through
these
interfaces until a cycle or two later, or probably worse, cases
where something
is now broken with no one aware of it until an actual end user
hits a problem
and files a bug.

ClientImpact Plan
=
I've run this by a few people and it seems to have some support.
Or course I'm
open to any other suggestions.

What I would like to do is add a ClientImpact tag handling that
could be added
very similarly to DocImpact. The way I see it working is it would
work in much
the same way where project's can use this to add the tag to a
commit message
when they know it is something that will require additional work
in OSC or
Horizon (or others). Then when that commit merges, automation
would create a
launchpad bug and/or Storyboard story, including a default set of
client
projects. Perhaps we can find some way to make those impacted clients
configurable by source project, but that could be a follow-on
optimization.

I am concerned that this could create some extra overhead for
these projects.
But my hope is it would be a quick evaluation by a bug triager in
those
projects where they can, hopefully, quickly determine if a change
does not in
fact impact them and just close the ones they don't think require
any follow on
work.

I do hope that this will save some time and speed things up
overall for these
projects to be notified that there is something that needs their
attention
without needing someone to take the time to actively go out and
discover that.

Help Needed
===
From the bits I've found for the DocImpact handling, it looks like
it should
not be too much effort to implement the logic to handle a
ClientImpact flag.
But I have not been able to find all the moving parts that work
together to
perform that automation.

If anyone has 

Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation

[Sean McGinnis]

On Thu, Aug 02, 2018 at 05:59:20PM +0200, Radomir Dopieralski wrote:
> To be honest, I don't see much point in automatically creating bugs that
> nobody is going to look at. When you implement a new feature, it's up to
> you to make it available in Horizon and CLI and wherever else, since the
> people working there simply don't have the time to work on it. Creating a
> ticket will not magically make someone do that work for you. We are happy
> to assist with this, but that's it. Anything else is going to get added
> whenever someone has any free cycles, or it becomes necessary for some
> reason (like breaking compatibility). That's the current reality, and no
> automation is going to help with it.
> 

I don't think that's universally true with these projects. There are some on
these teams that are interested in implementing support for new features and
keeping existing things working right.

The reality for most of this then is new features won't be available and users
will move away from using something like Horizon for whatever else comes along
that will give them access to what they need. I know there are very few
developers focused on Cinder that also have the skillset to add functionality
to Horizon.

I agree ideally someone would work on things wherever they are needed, but I
think there is a barrier with skills and priorities to make that happen. And at
least in the case of Cinder, neither Horizon nor OpenStackClient are required. 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation

[Radomir Dopieralski]

To be honest, I don't see much point in automatically creating bugs that
nobody is going to look at. When you implement a new feature, it's up to
you to make it available in Horizon and CLI and wherever else, since the
people working there simply don't have the time to work on it. Creating a
ticket will not magically make someone do that work for you. We are happy
to assist with this, but that's it. Anything else is going to get added
whenever someone has any free cycles, or it becomes necessary for some
reason (like breaking compatibility). That's the current reality, and no
automation is going to help with it.

On Thu, Aug 2, 2018 at 5:09 PM Sean McGinnis  wrote:

> I'm wondering if someone on the infra team can give me some pointers on
> how to
> approach something, and looking for any general feedback as well.
>
> Background
> ==
> We've had things like the DocImpact tag that could be added to commit
> messages
> that would tie into some automation to create a launchpad bug when that
> commit
> merged. While we had a larger docs team and out-of-tree docs, I think this
> really helped us make sure we didn't lose track of needed documentation
> updates.
>
> I was able to find part of how that is implemented in jeepyb:
>
>
> http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py
>
> Current Challenge
> =
> Similar to the need to follow up with documentation, I've seen a lot of
> cases
> where projects have added features or made other changes that impact
> downstream
> consumers of that project. Most often, I've seen cases where something like
> python-cinderclient adds some functionality, but it is on projects like
> Horizon
> or python-openstackclient to proactively go out and discover those changes.
>
> Not only just seeking out those changes, but also evaluating whether a
> given
> change should have any impact on their project. So we've ended up in a lot
> of
> cases where either new functionality isn't made available through these
> interfaces until a cycle or two later, or probably worse, cases where
> something
> is now broken with no one aware of it until an actual end user hits a
> problem
> and files a bug.
>
> ClientImpact Plan
> =
> I've run this by a few people and it seems to have some support. Or course
> I'm
> open to any other suggestions.
>
> What I would like to do is add a ClientImpact tag handling that could be
> added
> very similarly to DocImpact. The way I see it working is it would work in
> much
> the same way where project's can use this to add the tag to a commit
> message
> when they know it is something that will require additional work in OSC or
> Horizon (or others). Then when that commit merges, automation would create
> a
> launchpad bug and/or Storyboard story, including a default set of client
> projects. Perhaps we can find some way to make those impacted clients
> configurable by source project, but that could be a follow-on optimization.
>
> I am concerned that this could create some extra overhead for these
> projects.
> But my hope is it would be a quick evaluation by a bug triager in those
> projects where they can, hopefully, quickly determine if a change does not
> in
> fact impact them and just close the ones they don't think require any
> follow on
> work.
>
> I do hope that this will save some time and speed things up overall for
> these
> projects to be notified that there is something that needs their attention
> without needing someone to take the time to actively go out and discover
> that.
>
> Help Needed
> ===
> From the bits I've found for the DocImpact handling, it looks like it
> should
> not be too much effort to implement the logic to handle a ClientImpact
> flag.
> But I have not been able to find all the moving parts that work together to
> perform that automation.
>
> If anyone has any background knowledge on how DocImpact is implemented and
> can
> give me a few pointers, I think I should be able to take it from there to
> get
> this implemented. Or if there is someone that knows this well and is
> interested
> in working on some of the implementation, that would be very welcome too!
>
> Sean
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [infra][horizon][osc] ClientImpact tag automation

[Sean McGinnis]

I'm wondering if someone on the infra team can give me some pointers on how to
approach something, and looking for any general feedback as well.

Background
==
We've had things like the DocImpact tag that could be added to commit messages
that would tie into some automation to create a launchpad bug when that commit
merged. While we had a larger docs team and out-of-tree docs, I think this
really helped us make sure we didn't lose track of needed documentation
updates.

I was able to find part of how that is implemented in jeepyb:

http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py

Current Challenge
=
Similar to the need to follow up with documentation, I've seen a lot of cases
where projects have added features or made other changes that impact downstream
consumers of that project. Most often, I've seen cases where something like
python-cinderclient adds some functionality, but it is on projects like Horizon
or python-openstackclient to proactively go out and discover those changes.

Not only just seeking out those changes, but also evaluating whether a given
change should have any impact on their project. So we've ended up in a lot of
cases where either new functionality isn't made available through these
interfaces until a cycle or two later, or probably worse, cases where something
is now broken with no one aware of it until an actual end user hits a problem
and files a bug.

ClientImpact Plan
=
I've run this by a few people and it seems to have some support. Or course I'm
open to any other suggestions.

What I would like to do is add a ClientImpact tag handling that could be added
very similarly to DocImpact. The way I see it working is it would work in much
the same way where project's can use this to add the tag to a commit message
when they know it is something that will require additional work in OSC or
Horizon (or others). Then when that commit merges, automation would create a
launchpad bug and/or Storyboard story, including a default set of client
projects. Perhaps we can find some way to make those impacted clients
configurable by source project, but that could be a follow-on optimization.

I am concerned that this could create some extra overhead for these projects.
But my hope is it would be a quick evaluation by a bug triager in those
projects where they can, hopefully, quickly determine if a change does not in
fact impact them and just close the ones they don't think require any follow on
work.

I do hope that this will save some time and speed things up overall for these
projects to be notified that there is something that needs their attention
without needing someone to take the time to actively go out and discover that.

Help Needed
===
From the bits I've found for the DocImpact handling, it looks like it should
not be too much effort to implement the logic to handle a ClientImpact flag.
But I have not been able to find all the moving parts that work together to
perform that automation.

If anyone has any background knowledge on how DocImpact is implemented and can
give me a few pointers, I think I should be able to take it from there to get
this implemented. Or if there is someone that knows this well and is interested
in working on some of the implementation, that would be very welcome too!

Sean

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev