Re: [openstack-dev] [ironic] [ironic-ui] Proposing Anup Navare (anupn) for ironic-ui-core

2017-09-20 Thread Beth Elwell
++ I think Anup would be a great addition to the core team :) Thank you for all 
your contributions!

Beth

> On 20 Sep 2017, at 01:16, Julia Kreger  wrote:
> 
> Greetings fellow stackers!
> 
> I would like to propose adding Anup Navare to ironic-ui-core. Anup has
> been involved with ironic-ui this past cycle as well as various other
> areas across ironic which gives me further confidence in making this
> proposal.
> 
> I have already informally polled the existing ironic-ui-core members,
> to which everyone has responded positively. If there are no
> objections, I'll make the change in one week.
> 
> -Julia
> 
> __
> 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] Kingbird UX for Horizon

2017-09-14 Thread Beth Elwell
Hi Goutham,

I apologise I have not come across Kingbird before but will be interested to 
find out more about it!

To me the UX looks good but I don’t have enough exposure to what Kingbird is to 
know if it represents what you will need from a UI. Horizon has lots of 
templates and examples of how to build modals and buttons etc as per your 
current mocks so please do look at current examples and ask in 
#openstack-horizon if you need any help or advise at all. That will save you 
work and ensure the UI is consistent and we don’t have lots of duplicate code 
and ways of making the same sort of things that could prove to be confusing for 
future developers. As I say though, you are always welcome in channel and there 
will always be someone around to help you out and point you in the right 
direction.

Hope that helps!
Beth


> On 14 Sep 2017, at 00:24, Goutham Pratapa  wrote:
> 
> HI all,
> 
> Attached are the expected UX screens for Kingbird's horizon please feel free 
> to provide feedback on this.
> 
> 
> P.S: Images are drawn using paint and we will follow all the OpenStack 
> Horizon standards when we develop
> 
> -- 
> Cheers !!!
> Goutham Pratapa
> __
> 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] [horizon] PTG meetup

2017-09-06 Thread Beth Elwell
Hi all, 

Just wondering who is going to the PTG from the horizon team and whether we 
want to organise a google hangout group and/or plans for a happy hour or 
evening for the team to get to know each other better maybe? 

Looking forward to seeing you there,

Beth Elwell (betherly)
__
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] [horizon] Unknown provider resource-type-registry.service test error

2017-04-11 Thread Beth Elwell
Hi!

Just as a follow up to my email yesterday, tests are now passing. Many thanks 
Rob for helping me out with this on IRC!

If anyone else comes across this error message developing panels in horizon, my 
solution was that I wasn’t making the correct modules available with just 
beforeEach(module(‘horizon.app.core.network_qos')); Weirdly even adding 
beforeEach(module(‘horizon.app.core.openstack-service-api')); didn’t fix the 
errors, yet injecting a broader scope of 
beforeEach(module(‘horizon.app.core')); works in this case.

Thanks again,
Beth
IRC: betherly

> On 10 Apr 2017, at 17:45, Beth Elwell <beth.openst...@gmail.com> wrote:
> 
> Hi all,
> 
> Thanks very much in advance for any help you are able to offer.
> 
> I have been working on developing the QoS Policies panel for horizon and have 
> the panel working, however I am struggling with the qos.service.spec.js file. 
> In advance of going into my findings and issues so far, the related patch is 
> located at https://review.openstack.org/#/c/418828/ 
> <https://review.openstack.org/#/c/418828/> 
> 
> The error log is as follows: 
> 
> http://paste.openstack.org/show/606058/ 
> <http://paste.openstack.org/show/606058/>
> 
>  <http://paste.openstack.org/show/606058/>From that error log it looks to me 
> like the resource-type-registry for neutron is not being defined, and the 
> error appears with the link to the network_qos module as per line 19 
> https://review.openstack.org/#/c/418828/28/openstack_dashboard/static/app/core/network_qos/qos.service.spec.js
>  
> <https://review.openstack.org/#/c/418828/28/openstack_dashboard/static/app/core/network_qos/qos.service.spec.js>
>  
> 
> However the resource-type-registry is definitely defined and I cannot see why 
> this should be throwing errors.
> 
> It could well be I have just looked at this code for too long and my brain is 
> skipping over something, but any help anyone can give on this would be 
> massively appreciated.
> 
> Many thanks,
> Beth
> IRC: betherly

__
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] [horizon] Unknown provider resource-type-registry.service test error

2017-04-10 Thread Beth Elwell
Hi all,

Thanks very much in advance for any help you are able to offer.

I have been working on developing the QoS Policies panel for horizon and have 
the panel working, however I am struggling with the qos.service.spec.js file. 
In advance of going into my findings and issues so far, the related patch is 
located at https://review.openstack.org/#/c/418828/ 
 

The error log is as follows: 

http://paste.openstack.org/show/606058/ 


 From that error log it looks to me 
like the resource-type-registry for neutron is not being defined, and the error 
appears with the link to the network_qos module as per line 19 
https://review.openstack.org/#/c/418828/28/openstack_dashboard/static/app/core/network_qos/qos.service.spec.js
 

 

However the resource-type-registry is definitely defined and I cannot see why 
this should be throwing errors.

It could well be I have just looked at this code for too long and my brain is 
skipping over something, but any help anyone can give on this would be 
massively appreciated.

Many thanks,
Beth
IRC: betherly__
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] [horizon] Single core review for patch approval

2017-03-01 Thread Beth Elwell
Yep I totally agree that adding cores for the sake of adding cores doesn’t make 
sense. Just trying to fish for ideas to prevent having to go to a single +2 to 
merge as that does make me nervous. But I guess for the sake of moving code 
through it needs to be done at the moment.


> On 1 Mar 2017, at 11:53, Rob Cresswell <robert.cressw...@outlook.com> wrote:
> 
> Adding inexperienced cores doesn't really alleviate that issue though, and I 
> don't currently feel that there is anyone with the right balance of 
> experience and activity to be added to the core team.
> 
> Me and Richard monitor review activity very closely though, and we are 
> actively looking to grow the team. We just need more activity from reviewers 
> so that they can learn, and in turn we can teach them. I don't expect people 
> to know everything before being core - I certainly didn't - but I don't think 
> the bar is being met just yet.
> 
> Rob
> 
> On 1 March 2017 at 10:36, Beth Elwell <beth.openst...@gmail.com 
> <mailto:beth.openst...@gmail.com>> wrote:
> Has there been any consideration of growing the core team to help with review 
> bandwidth? I ask only because that resulting responsibility to the community 
> can drive additional review activity. Just worried that only 1x +2 could 
> cause issues with code being  merged on a project this large that could 
> potentially break things or clash with other opinions or standards of how it 
> should be written/implemented? It concerns me that it makes it easier to 
> overlook larger things in more substantial patches. I guess as you say, there 
> needs to be accountability re not always going for the single +2 when the 
> patch is of that sort of size and you need a second opinion?
> 
> Beth
> 
> > On 28 Feb 2017, at 10:09, Rob Cresswell <robert.cressw...@outlook.com 
> > <mailto:robert.cressw...@outlook.com>> wrote:
> >
> > Hey everyone,
> >
> > Horizon is moving to requiring only a single core review for code approval. 
> > Note that cores are not obliged to approve on a single +2; if a core would 
> > like a second opinion for patches that are complex or high risk, that is 
> > also fine.
> >
> > We still require at least one of the core reviewers or contributor on a 
> > patch to be from separate companies however. For example, if a patch is 
> > authored by someone from Cisco, then I could not (as a Cisco employee) +2+w 
> > the patch by myself; it would require at least another core +2.
> >
> > This should help us move smaller patches along quicker.
> >
> > Rob
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> > <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [horizon] Single core review for patch approval

2017-03-01 Thread Beth Elwell
Has there been any consideration of growing the core team to help with review 
bandwidth? I ask only because that resulting responsibility to the community 
can drive additional review activity. Just worried that only 1x +2 could cause 
issues with code being merged on a project this large that could potentially 
break things or clash with other opinions or standards of how it should be 
written/implemented? It concerns me that it makes it easier to overlook larger 
things in more substantial patches. I guess as you say, there needs to be 
accountability re not always going for the single +2 when the patch is of that 
sort of size and you need a second opinion?

Beth

> On 28 Feb 2017, at 10:09, Rob Cresswell  wrote:
> 
> Hey everyone,
> 
> Horizon is moving to requiring only a single core review for code approval. 
> Note that cores are not obliged to approve on a single +2; if a core would 
> like a second opinion for patches that are complex or high risk, that is also 
> fine.
> 
> We still require at least one of the core reviewers or contributor on a patch 
> to be from separate companies however. For example, if a patch is authored by 
> someone from Cisco, then I could not (as a Cisco employee) +2+w the patch by 
> myself; it would require at least another core +2.
> 
> This should help us move smaller patches along quicker.
> 
> Rob
> __
> 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] [Horizon] How do we move forward with xstatic releases?

2016-03-10 Thread Beth Elwell

> On 10 Mar 2016, at 07:46, Richard Jones  wrote:
>  
> It has been mentioned, xstatic packages can block the gate. We currently
> control xstatic package releases, thus we can roll back, if something
> goes wrong.
> 
> If we're pulling directly with npm/bower, someone from the outside can
> break us. We already have the situation with pypi packages.
> With proper packages, we could even use the gate to release those
> packages and thus verify, we're not breaking anyone.
> 
> We're going to have potential breakage (gate breakage, in the integrated 
> tests) any time we release a package (regardless of release mechanism) and 
> have to update two separate repositories resulting in out-of-sync version 
> specification and expectation (ie. upper-constraints specification and 
> Horizon's code expectation) as described in my OP. The only solution that 
> we're aware of is to synchronise updating those two things, through one of 
> the mechanisms proposed so far (or possibly through a mechanism not yet 
> proposed.)

If we will anyway have potential breakage I don’t understand why the better 
solution here would not be to just use the bower and npm tools which are 
standardised for JavaScript and would move Horizon more towards using widely 
recognised tooling from within not just Openstack but the wider development 
community. Back versions always need to be supported for a time, however I 
would add that long term this could end up saving time and create a stable 
longer term solution.

> __
> 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] [horizon] Proposal to add Diana Whitten to horizon-core

2016-03-09 Thread Beth Elwell
I’m not a core but I wanted to add my complete agreement with making Diana a 
core in horizon. She has done some incredible work in horizon through her work 
on the code, reviews and also community attitude and assistance getting people 
(myself included) familiar with horizon.

Beth

> On 8 Mar 2016, at 22:48, Lin Hua Cheng  wrote:
> 
> big +1 from me.
> 
> She made a lot of contribution in making theming better for horizon and also 
> prevented potential issues through reviews.
> Thanks for all the hard work, Diana.
> 
> -Lin
> 
> On Tue, Mar 8, 2016 at 2:06 PM, David Lyle  > wrote:
> I propose adding Diana Whitten[1] to horizon-core.
> 
> Diana is an active reviewer, contributor and community member. Over
> the past couple of releases, Diana has driven extensive changes around
> theme-ability in Horizon and drastically increased the standardization
> of our use of bootstrap. During this time, Diana has also provided
> valuable reviews to keep us on the straight and narrow preventing our
> continued abuse of defenseless web technologies.
> 
> Please respond with comments, +1s, or objections by Friday.
> 
> Thanks,
> David
> 
> [1] 
> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>  
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [ironic] Next meeting is November 9

2015-10-22 Thread Beth Elwell
Hi Jim,

I will be on holiday the week of the 9th November and so will be unable to make 
that meeting. Work on the ironic UI will be posted in the sub team report 
section and if anyone has any questions regarding it please shoot me an email 
or ping me.

Thanks!
Beth

> On 22 Oct 2015, at 01:58, Jim Rollenhagen  wrote:
> 
> Hi folks,
> 
> Since we'll all be at the summit next week, and presumably recovering
> the following week, the next Ironic meeting will be on November 9, in
> the usual place and time. See you there! :)
> 
> // jim
> 
> __
> 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] [ironic] [horizon] ironic panels

2015-10-21 Thread Beth Elwell



On 21/10/2015 01:48, Jim Rollenhagen wrote:

On Tue, Oct 20, 2015 at 04:50:04PM +0100, Beth Elwell wrote:

Hi Jim,

I have replied inline to your comments below:

On 19/10/2015 19:38, Jim Rollenhagen wrote:

On Mon, Oct 19, 2015 at 07:05:04PM +0100, Beth Elwell wrote:

Hi all,

I am currently in the process of writing an Ironic panel in Horizon
upstream. It was originally intended for this panel to be written in
Angular JS, however, as I understand, no horizon angular work will
merge for several months, and 2-3 panels (of which ironic is not one)
are being moved to the feature branch to iterate on the design pattern
that they want to use to implement the angular.

With regard to the ironic panel, this means that in order to implement
it in angular, it will take weeks or perhaps months to merge and even
when it does, it may well need to be rewritten to follow design patterns
being set at the moment.

Therefore I propose that I continue to develop this as a Horizon python
panel as a short term solution to allow a UI to exist for our users of
Ironic ASAP and longer term make use of the ironic webclient and the
work that krotscheck is currently doing on that.

I would appreciate feedback with regard to whether the ironic community
are happy for me to continue on with developing a horizon panel or would
like me to work on an angular panel.

In general, I like the idea of "get a web interface to users quickly",
and in that spirit I think building a horizon panel is the right thing
to do.

I do love the webclient work; I think it's great. However, considering
that (as far as I know) there's only two people working on Ironic web
interfaces, is it valuable to be working on two different web interfaces
right now? In the worst case:

I have had contact from another party interested in helping get a horizon
panel up and running quickly and so it is definitely doable to have that
being worked on as well as the work on the webclient.

* horizon panel will be built
* webclient will also be built
* horizon will figure out angular stuff
* webclient will be re-written to work with horizon
* webclient will likely take significant time to merge into horizon
* old horizon panel will be deprecated
* (in time) old horizon panel will be removed

And in the best case, only the rewrite step is skipped, and maybe the
merge into horizon won't take long. There's also a question about how
much different the two are, and how large of a leap that is for users.

That seems like a lot of extra effort and maintenance for an entire
team; let alone two people. So I question if it's worth working on the
webclient, or punting on that until horizon is ready, and then
refactoring the horizon panel into angular.

Is there a clear benefit to having both worked on in parallel?

As I see it they ultimately fulfill different purposes and therefore
developing both is not a waste of resources or time. The panel is a short
term solution to fulfill a user requirement for a user interface within
Horizon. The webclient is a long term mission to create independent API
libraries in javascript in order to make openstack more composable.

Okay, after reading this and talking with krotscheck in IRC:

* The horizon panel is clearly valuable, as many users use Horizon. We
   should support that.

* The ironic-webclient work is clearly valuable, as we support running
   Ironic standalone, and a standalone web UI would be great to have for
   that.

* I'm not opinionated whether "independent API libraries in Javascript
   in order to make OpenStack more composable" is valuable. It seems like
   it is, assuming there's a use case for that. The clear use case to me
   is to allow Horizon competitors to be built, which seems useful for
   folks that don't want to or care to use Horizon.

At any rate, I agree the horizon panel should be worked on - let's get
our users a UI.


Following the original email I have spoken further with the Horizon 
teams. In assessing the state of my existing work and theirs on the 
angular panel have got to, it seems pointless to remake a Django horizon 
panel, and in so doing go backwards, when one in angular already 
virtually exists in full now.


After discussion with David Lyle from horizon I will be converting the 
angular panel to a plugin that will be a significantly faster effort 
than starting another panel from scratch in Django. As I understand, 
this will have much the same effect as a panel within horizon - our 
users will have an ironic UI allowing them to access ironic from within 
horizon and we will be able to reuse most of the existing code that has 
already been written to do so to avoid replication of the same thing in 
just a different language.


// jim

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

Re: [openstack-dev] [ironic] [horizon] ironic panels

2015-10-20 Thread Beth Elwell

Hi Jim,

I have replied inline to your comments below:

On 19/10/2015 19:38, Jim Rollenhagen wrote:

On Mon, Oct 19, 2015 at 07:05:04PM +0100, Beth Elwell wrote:

Hi all,

I am currently in the process of writing an Ironic panel in Horizon
upstream. It was originally intended for this panel to be written in
Angular JS, however, as I understand, no horizon angular work will
merge for several months, and 2-3 panels (of which ironic is not one)
are being moved to the feature branch to iterate on the design pattern
that they want to use to implement the angular.

With regard to the ironic panel, this means that in order to implement
it in angular, it will take weeks or perhaps months to merge and even
when it does, it may well need to be rewritten to follow design patterns
being set at the moment.

Therefore I propose that I continue to develop this as a Horizon python
panel as a short term solution to allow a UI to exist for our users of
Ironic ASAP and longer term make use of the ironic webclient and the
work that krotscheck is currently doing on that.

I would appreciate feedback with regard to whether the ironic community
are happy for me to continue on with developing a horizon panel or would
like me to work on an angular panel.

In general, I like the idea of "get a web interface to users quickly",
and in that spirit I think building a horizon panel is the right thing
to do.

I do love the webclient work; I think it's great. However, considering
that (as far as I know) there's only two people working on Ironic web
interfaces, is it valuable to be working on two different web interfaces
right now? In the worst case:
I have had contact from another party interested in helping get a 
horizon panel up and running quickly and so it is definitely doable to 
have that being worked on as well as the work on the webclient.

* horizon panel will be built
* webclient will also be built
* horizon will figure out angular stuff
* webclient will be re-written to work with horizon
* webclient will likely take significant time to merge into horizon
* old horizon panel will be deprecated
* (in time) old horizon panel will be removed

And in the best case, only the rewrite step is skipped, and maybe the
merge into horizon won't take long. There's also a question about how
much different the two are, and how large of a leap that is for users.

That seems like a lot of extra effort and maintenance for an entire
team; let alone two people. So I question if it's worth working on the
webclient, or punting on that until horizon is ready, and then
refactoring the horizon panel into angular.

Is there a clear benefit to having both worked on in parallel?


As I see it they ultimately fulfill different purposes and therefore 
developing both is not a waste of resources or time. The panel is a 
short term solution to fulfill a user requirement for a user interface 
within Horizon. The webclient is a long term mission to create 
independent API libraries in javascript in order to make openstack more 
composable.

// jim

__
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

Thanks,
Beth
__
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] [ironic] [horizon] ironic panels

2015-10-19 Thread Beth Elwell


Hi all,

I am currently in the process of writing an Ironic panel in Horizon
upstream. It was originally intended for this panel to be written in
Angular JS, however, as I understand, no horizon angular work will
merge for several months, and 2-3 panels (of which ironic is not one)
are being moved to the feature branch to iterate on the design pattern
that they want to use to implement the angular.

With regard to the ironic panel, this means that in order to implement
it in angular, it will take weeks or perhaps months to merge and even
when it does, it may well need to be rewritten to follow design patterns
being set at the moment.

Therefore I propose that I continue to develop this as a Horizon python
panel as a short term solution to allow a UI to exist for our users of
Ironic ASAP and longer term make use of the ironic webclient and the
work that krotscheck is currently doing on that.

I would appreciate feedback with regard to whether the ironic community
are happy for me to continue on with developing a horizon panel or would
like me to work on an angular panel.

Many thanks,
Beth Elwell


__
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