Open Stack

> You may not realize you do a disservice to those reading this post and
> those reviewing future patches if you set unreasonable expectations.

> Telling others that they can expect a patch merged in the same day is
> not reasonable, even if that has been your experience. While we do our
> best to keep current, we all are very busy and requests for repos are
> increasing. If folks want a repo they can submit a patch to create one,
> here is a good guide:
> http://docs.openstack.org/infra/manual/creators.html and it will be
> reviewed along with all other patches to project-config.

Anita,

Thanks for correcting me.  Yeah, I just quoted *my experience with
openstack-infra *blindly.  Sorry for that.

Rather I also wanted to point out to our folks, things in infra are so
automated that putting an openstack-related module into stackforge has been
become fully automatic and easy *(easy for the requestor, of course keeping
in mind that the request has to be correct and get's reviewed and approved
by  infra guys)*.  Kudos to you guys :-)

Regards,
Ramesh


On Sun, Mar 1, 2015 at 12:49 AM, Anita Kuno <anteaya at anteaya.info> wrote:

> On 02/28/2015 01:28 AM, Ramakrishnan G wrote:
> > Hello All,
> >
> > This is about adding vendor drivers in Ironic.
> >
> > In Kilo, we have many vendor drivers getting added in Ironic which is a
> > very good thing.  But something I noticed is that, most of these reviews
> > have lots of hardware-specific code in them.  This is something most of
> the
> > other Ironic folks cannot understand unless they go and read the hardware
> > manuals of the vendor hardware about what is being done.  Otherwise we
> just
> > need to blindly mark the file as reviewed.
> >
> > Now let me pitch in with our story about this.  We added a vendor driver
> > for HP Proliant hardware (the *ilo drivers in Ironic).  Initially we
> > proposed this same thing in Ironic that we will add all the hardware
> > specific code in Ironic itself under the directory drivers/modules/ilo.
> > But few of the Ironic folks didn't agree on this (Devananda especially
> who
> > is from my company :)). So we created a new module proliantutils, hosted
> in
> > our own github and recently moved it to stackforge.  We gave a limited
> set
> > of APIs for Ironic to use - like get_host_power_status(),
> set_host_power(),
> > get_one_time_boot(), set_one_time_boot(), etc. (Entire list is here
> >
> https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.py
> > ).
> >
> > We have only seen benefits in doing it.  Let me bring in some examples:
> >
> > 1) We tried to add support for some lower version of servers.  We could
> do
> > this without making any changes in Ironic (Review in proliantutils
> > https://review.openstack.org/#/c/153945/)
> > 2) We are adding support for newer models of servers (earlier we use to
> > talk to servers in protocol called RIBCL, newer servers we will use a
> > protocol called RIS) - We could do this with just 14 lines of actual code
> > change in Ironic (this was needed mainly because we didn't think we will
> > have to use a new protocol itself when we started) -
> > https://review.openstack.org/#/c/154403/
> >
> > Now talking about the advantages of putting hardware-specific code in
> > Ironic:
> >
> > *1) It's reviewed by Openstack community and tested:*
> > No. I doubt if I throw in 600 lines of new iLO specific code that is
> here (
> >
> https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.py
> )
> > for Ironic folks, they will hardly take a look at it.  And regarding
> > testing, it's not tested in the gate unless we have a 3rd party CI for
> it.
> >  [We (iLO drivers) also don't have 3rd party CI right now, but we are
> > working on it.]
> >
> > *2) Everything gets packaged into distributions automatically:*
> > Now the hardware-specific code that we add in Ironic under
> > drivers/modules/<vendor>/ will get packaged into distributions, but this
> > code in turn will have dependencies  which needs to be installed manually
> > by the operator (I assume vendor specific dependencies are not considered
> > by Linux distributions while packaging Openstack Ironic). Anyone
> installing
> > Ironic and wanting to manage my company's servers will again need to
> > install these dependencies manually.  Why not install the wrapper if
> there
> > is one too.
> >
> > I assume we only get these advantages by moving all of hardware-specific
> > code to a wrapper module in stackforge and just exposing some APIs for
> > Ironic to use:
> > * Ironic code would be much cleaner and easier to maintain
> > * Any changes related to your hardware - support for newer hardware, bug
> > fixes in particular models of hardware, would be very easy. You don't
> need
> > to change Ironic code for that. You could just fix the bug in your
> module,
> > release a new version and ask your users to install a newer version of
> the
> > module.
> > * python-fooclient could be used outside Ironic to easily manage foo
> > servers.
> > * Openstack CI for free if you are in stackforge - unit tests, flake
> tests,
> > doc generation, merge, pypi release everything handled automatically.
> >
> > I don't see any disadvantages.
> >
> > Now regarding the time taken to do this, if you have all the code ready
> now
> > in Ironic (which assume you will already have), perhaps it will take a
> day
> > to do this - half a day for putting into a separate module in
> python/github
> > and half a day for stackforge. The request to add stackforge should get
> > approved in the same day (if everything is all-right).
> You may not realize you do a disservice to those reading this post and
> those reviewing future patches if you set unreasonable expectations.
>
> Telling others that they can expect a patch merged in the same day is
> not reasonable, even if that has been your experience. While we do our
> best to keep current, we all are very busy and requests for repos are
> increasing. If folks want a repo they can submit a patch to create one,
> here is a good guide:
> http://docs.openstack.org/infra/manual/creators.html and it will be
> reviewed along with all other patches to project-config.
>
> Thank you,
> Anita.
> >
> > Let me know all of your thoughts on this.  If we agree, I feel we should
> > have some documentation on it in our Ironic docs directory.
> >
> > Thanks for reading :)
> >
> > Regards,
> > Ramesh
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150301/d06e62b2/attachment.html>