Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack] Supporting code for incubated projects

2014-09-09 Thread Thierry Carrez
Mac Innes, Kiall wrote:
 While requesting a openstack/designate-dashboard project from the TC/Infra
 – The topic of why Designate panels, as an incubated project, can’t
 be merged into openstack/horizon was raised.
 
 In the openstack/governance review[1], Russell asked:
 
 Hm, I think we should discuss this with the horizon team, then. We are
 telling projects that incubation is a key time for integrating with
 other
 projects. I would expect merging horizon integration into horizon itself
 to be a part of that.

We are actually telling projects that they should work on their Horizon
panels while in incubation, and use their first integrated cycle (once
they graduate, before their first release), to get their panels into
Horizon mainline code.

That's what Sahara did over this cycle (they had a dashboard, they got
it merged in Horizon during juno, in time for final Juno release).

Now it's not a perfect setup: it put a lot of stress between Sahara and
Horizon teams -- it was essential for Sahara to get it merged, while no
horizon-core really signed up to review it. It took a bit of
cross-project coordination to get it in in time... I expect the same to
happen again.

-- 
Thierry Carrez (ttx)

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


Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack] Supporting code for incubated projects

2014-09-09 Thread Mac Innes, Kiall
 -Original Message-
 From: Sean Dague [mailto:s...@dague.net]
 Sent: 09 September 2014 15:13
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack]
 Supporting code for incubated projects
 
 On 09/09/2014 07:58 AM, Mac Innes, Kiall wrote:
  Hi all,
 
 
 
  While requesting a openstack/designate-dashboard project from the TC/
 
  Infra – The topic of why Designate panels, as an incubated project,
  can’t be merged into openstack/horizon was raised.
 
 
 
  In the openstack/governance review[1], Russell asked:
 
 
 
  Hm, I think we should discuss this with the horizon team, then. We are
  telling projects that incubation is a key time for integrating
  with other
  projects. I would expect merging horizon integration into horizon itself
  to be a part of that.
 
 
 
  With this in mind – I’d like to start a conversation with the Horizon,
  Tempest and DevStack teams around merging of code to support
 Incubated
  projects – What are the drawbacks?, Why is this currently frowned upon
  by the various teams? And – What do each of the parties believe is the
  Right Way forward?
 
 I though the Devstack and Tempest cases were pretty clear, once things are
 incubated they are fair game to get added in.

 Devstack is usually the right starting point, as that makes it easy for 
 everyone
 to have access to the code, and makes the testability by other systems
 viable.

 I currently don't see any designate changes that are passing Jenkins that
 need to be addressed, is there something that got missed?
 
   -Sean

From previous discussions with Tempest team members, we had been informed
this was not the case - this could have been miscommunication.

For DevStack, I never even asked - After two Not till you're integrated's, I 
made
the assumption DevStack would be the same.

I'll get our DevStack part's submitted for review ASAP if that's not the case!

The Horizon integration though, the spark for this conversation, still stands.

Thanks,
Kiall
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack] Supporting code for incubated projects

2014-09-09 Thread Sean Dague
On 09/09/2014 12:23 PM, Mac Innes, Kiall wrote:
 -Original Message-
 From: Sean Dague [mailto:s...@dague.net]
 Sent: 09 September 2014 15:13
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack]
 Supporting code for incubated projects

 On 09/09/2014 07:58 AM, Mac Innes, Kiall wrote:
 Hi all,



 While requesting a openstack/designate-dashboard project from the TC/

 Infra – The topic of why Designate panels, as an incubated project,
 can’t be merged into openstack/horizon was raised.



 In the openstack/governance review[1], Russell asked:



 Hm, I think we should discuss this with the horizon team, then. We are
 telling projects that incubation is a key time for integrating
 with other
 projects. I would expect merging horizon integration into horizon itself
 to be a part of that.



 With this in mind – I’d like to start a conversation with the Horizon,
 Tempest and DevStack teams around merging of code to support
 Incubated
 projects – What are the drawbacks?, Why is this currently frowned upon
 by the various teams? And – What do each of the parties believe is the
 Right Way forward?

 I though the Devstack and Tempest cases were pretty clear, once things are
 incubated they are fair game to get added in.

 Devstack is usually the right starting point, as that makes it easy for 
 everyone
 to have access to the code, and makes the testability by other systems
 viable.

 I currently don't see any designate changes that are passing Jenkins that
 need to be addressed, is there something that got missed?

  -Sean
 
 From previous discussions with Tempest team members, we had been informed
 this was not the case - this could have been miscommunication.

Once officially incubated it should be fine to add tempest tests. There
are tests for queues and baremetal in there. dns should be the same.

 For DevStack, I never even asked - After two Not till you're integrated's, 
 I made
 the assumption DevStack would be the same.

Devstack policy is basically once incubated, it's all good. We try to
resist every stackforge project under the sun trying to put config code
in devstack, however we've got a plugin interface so that projects can
maintain their devstack integration in their own tree.

 I'll get our DevStack part's submitted for review ASAP if that's not the case!
 
 The Horizon integration though, the spark for this conversation, still stands.
 
 Thanks,
 Kiall
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack] Supporting code for incubated projects

2014-09-09 Thread Lyle, David
Adding support for incubated projects in Horizon is blocked mainly for
dependency issues. The way Horizon utilizes the python-*clients we force a
requirement on distros to now include that version of the client even
though it is not officially part of OpenStack's integrated release.
Additionally, we've made exceptions and included incubated project support
in the past and doing so has been borderline disastrous from a release
point of view. Things like non-backward compatible client releases have
happened in the RC cycles.

I've been struggling with a better way forward. But including directly in
the Horizon tree, will create problems.

David

On 9/9/14, 8:12 AM, Sean Dague s...@dague.net wrote:

On 09/09/2014 07:58 AM, Mac Innes, Kiall wrote:
 Hi all,
 
  
 
 While requesting a openstack/designate-dashboard project from the TC/
 
 Infra ­ The topic of why Designate panels, as an incubated project,
can¹t
 be merged into openstack/horizon was raised.
 
  
 
 In the openstack/governance review[1], Russell asked:
 
  
 
 Hm, I think we should discuss this with the horizon team, then. We
are
 telling projects that incubation is a key time for integrating with
 other
 projects. I would expect merging horizon integration into horizon
itself
 to be a part of that.
 
  
 
 With this in mind ­ I¹d like to start a conversation with the Horizon,
 Tempest and DevStack teams around merging of code to support
 Incubated projects ­ What are the drawbacks?, Why is this currently
 frowned upon by the various teams? And ­ What do each of the parties
 believe is the Right Way forward?

I though the Devstack and Tempest cases were pretty clear, once things
are incubated they are fair game to get added in.

Devstack is usually the right starting point, as that makes it easy for
everyone to have access to the code, and makes the testability by other
systems viable.

I currently don't see any designate changes that are passing Jenkins
that need to be addressed, is there something that got missed?

   -Sean

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


Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack] Supporting code for incubated projects

2014-09-09 Thread Gabriel Hurley
I would also like to add that incubated != integrated. There's no telling how 
long a project may stay in incubation or how many changes it may undergo before 
it's deemed ready (see David's reasoning around client changes during RC's).

While the Horizon team has always made every effort to work closely with the 
incubated projects in getting them ready for merge as soon as they're 
officially integrated, doing so prior to that promise of stability, distro 
support, etc. isn't just infeasible, it's dangerous to the Horizon project.

Perhaps instead we should focus on making a better flow for installing 
experimental modules in a more official capacity. I always go back to how we 
can help build a better ecosystem. This problem applies to projects which are 
not and may never be incubated just as much as to incubated ones.

Sure, anyone with some know-how *can* load in another dashboard or panel into 
Horizon through their settings, but maybe it's time we looked at how to do this 
in a more user-friendly way.

- Gabriel

 -Original Message-
 From: Lyle, David [mailto:david.l...@hp.com]
 Sent: Tuesday, September 09, 2014 2:07 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack]
 Supporting code for incubated projects
 
 Adding support for incubated projects in Horizon is blocked mainly for
 dependency issues. The way Horizon utilizes the python-*clients we force a
 requirement on distros to now include that version of the client even though
 it is not officially part of OpenStack's integrated release.
 Additionally, we've made exceptions and included incubated project support
 in the past and doing so has been borderline disastrous from a release point
 of view. Things like non-backward compatible client releases have happened
 in the RC cycles.
 
 I've been struggling with a better way forward. But including directly in the
 Horizon tree, will create problems.
 
 David
 
 On 9/9/14, 8:12 AM, Sean Dague s...@dague.net wrote:
 
 On 09/09/2014 07:58 AM, Mac Innes, Kiall wrote:
  Hi all,
 
 
 
  While requesting a openstack/designate-dashboard project from the TC/
 
  Infra ­ The topic of why Designate panels, as an incubated project,
 can¹t  be merged into openstack/horizon was raised.
 
 
 
  In the openstack/governance review[1], Russell asked:
 
 
 
  Hm, I think we should discuss this with the horizon team, then.
 We are
  telling projects that incubation is a key time for integrating
 with  other
  projects. I would expect merging horizon integration into horizon
 itself
  to be a part of that.
 
 
 
  With this in mind ­ I¹d like to start a conversation with the
  Horizon, Tempest and DevStack teams around merging of code to support
  Incubated projects ­ What are the drawbacks?, Why is this currently
  frowned upon by the various teams? And ­ What do each of the parties
  believe is the Right Way forward?
 
 I though the Devstack and Tempest cases were pretty clear, once things
 are incubated they are fair game to get added in.
 
 Devstack is usually the right starting point, as that makes it easy for
 everyone to have access to the code, and makes the testability by other
 systems viable.
 
 I currently don't see any designate changes that are passing Jenkins
 that need to be addressed, is there something that got missed?
 
  -Sean
 
 --
 Sean Dague
 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

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