On 2/21/19 10:19 AM, Cordoba Malibran, Erich wrote:
On Thu, 2019-02-21 at 09:15 -0500, Curtis wrote:
On Thu, Feb 21, 2019 at 8:46 AM Eslimi, Dariush <Dariush.Eslimi@windr iver.com> wrote:
Hi,
I see Spec as a high level design for a code that going to be developed, and to make sure it aligns with how community is going to use it and to make everybody aware of what is going to do, so others can chime in and say things that can address multiple needs and influence its design. Let's call this apple.
Now I see the case of a code that has been developed before even the community existed, and now been presented to the community to fill a gap and improve productivity, no time to change the design and would be up to community to accept or reject it as is. A case of donation really, I call this one Orange.
For Orange I think Spec is not the right word, we need a wiki/readme to see what it does, and how to use it. It is too late to produce a spec to influence the design.
OpenStack Operators have a tools landing repository [1] that didn't/doesn't have the same level of requirements the rest of the OpenStack code typically does, so organizations could open source internal. potentially untested, scripts but not have to necessarily adhere to all of the usual requirements. Over time the code in that repository could be improved and moved out once it made sense.
I think it's worthwhile to have useful internal code open sourced, and in some cases make it a bit easier to do so, and if the code/tool gets used then start improving it following general standards. This would require a new repository.
Just a thought. :)
I really like the idea of having a new repository as a landing zone where things can be stabilize over time. When I started reviewing this tool I noticed that my comments were more focused on design (features that we might not need, restructure of cli arguments and so on) and I understand that fixing this is outside of the scope of sharing an internal tool.
So, should be go in the path of creating a new repository? or can we use an "experimental" folder within stx-tools?
What do you think about this?
I think that this can land in the stx-tools directory along with the other deployment scripts. As was pointed out in the meeting this morning, this code has been in use within WindRiver for a while now and they are making it available to the community. I think that the initial PR needed to have a better commit message explaining this and a little more thought put into the request before it got reviewed, such as removing the .pyc files, licensing, documentation, the first two where show stopper for me, but easily fixed, documentation could be added later. Sau!
Thanks, Curtis
[1]: https://git.openstack.org/cgit/openstack/osops-tools-contrib/tre e/README.rst
My .02$, Dariush
-----Original Message----- From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran@intel. com] Sent: February-20-19 6:21 PM To: Waheed, Numan <Numan.Waheed@windriver.com>; starlingx-discuss@l ists.starlingx.io Subject: Re: [Starlingx-discuss] Python Based VBox Installer
Hi,
I just reviewed the tool and I think it's a great tool and it will be really useful for the community. I just have one general question that I would like to extend to the community. Should this tool be supported by a spec?
-Erich
On Wed, 2019-02-20 at 21:21 +0000, Waheed, Numan wrote:
A Python-based installer for StarlingX has been submitted to stx- tools repo. This automated installer has been used by Wind River engineers on a continual basis for installing StarlingX on VBox environment. This installer is not a new development. This has been used for several years for quick install on VBox. It is being delivered to help community for ease of installation of starlingx. Feel free to use this installer and even add new features to serve the community better.
The installer is going in via following submission: https://review.openstack.org/#/c/637958/
Numan. _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-disc uss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss