openstack team mailing list archive

[Narayan Desai <narayan.desai@xxxxxxxxx>]

Ghe, while you're right that these two workloads are different, deployers
need developers to use a representative environment during development, or
the code doesn't work when it hits real deployments. We've now been bitten
during our initial deployment of cactus, our upgrade to diablo, and our
recent tests preparing for the essex upgrade because we can't run our
management infrastructure on a single system.

During cactus, we had issues when we tried to run multiple nova-network
servers distinctly from the api service. IIRC during the diablo release, we
had issues with keystone and horizon. This time, we had issues with
glance/keystone integration. I'm not saying that things haven't improved,
it just seems that each release has a new issue caused by the assumption
that all services will be running on the same host.

As we get more users with large deployments, these sorts of issues will
only become a bigger deal, and will hinder large scale adoption.
 -nld

On Wed, Mar 21, 2012 at 3:26 AM, Ghe Rivero <ghe.rivero@xxxxxxxxxxxx> wrote:

> Hi,
>     we are facing two differents problems here. We have developers and
> final users, and both of them with different expectations about what to get
> from OpenStack. Developers wants an easy way to test "untested" code, new
> cool-probably-broken features and be able to change immediately - devstack
> is the perfect tool for this . On the other hand, final users just want a
> working easy to deploy system, without care if the latest
> cool-probably-broken feature is included (I bet they prefer it to not be).
> But the truth is that OpenStack can't ignore any of them. Nobody will use a
> program which is hard to install, deploy, test or develop on it. Some
> consensus will be necessary in the user side (I think we all agree that
> development is ok with devstack) As Justin pointed before,
> http://summit.openstack.org/sessions/view/26, can be a good starting
> point, defining a common set of minimums that every package should comply
> with (file/dir locations and perms, minimal contents of config files, users
> created, python external modules requiriments/ minimal versions, ...), so
> when someone complaint about something, we know that the installation has
> some minimal standards that it follows (just a quick idea that just came to
> my mind to help debugging users installations,  a simple script, that use
> paste.openstack.org, and post there the config files, daemons runnings,
> last lines of some logs, version of pkgs installed...)
>
> Ghe Rivero
>
> On Wed, Mar 21, 2012 at 5:20 AM, Joshua Harlow <harlowja@xxxxxxxxxxxxx>wrote:
>
>>  Another idea:
>>
>> *http://meego.gitorious.org/meego-developer-tools/spectacle
>> *
>> That python code seems to be able to take a yaml defintion and generate
>> either rpm specfiles or debian pkg files.
>>
>> It might be forked or extended (or both) and used to generate the initial
>> set of package definitions for openstack in a non-pkg specific format...
>>
>>
>> On 3/20/12 11:01 AM, "Justin Santa Barbara" <justin@xxxxxxxxxxxx> wrote:
>>
>> Hi Thomas,
>>
>> I think devstack has done a lot for the developer's use-case, but I
>> believe we should also have a official / semi-official project that does
>> some sort of packaging to help the production use-case.  I've proposed a
>> summit discussion: http://summit.openstack.org/sessions/view/26
>>
>> The background: I want a semi-production deployment, but as a developer I
>> still want to be able to edit the code (which makes packages inconvenient).
>>  devstack is orientated towards e.g. wiping the databases.
>>
>> I'm hoping that all the various OS packagers can work together, or at
>> least tell us what sucks.  As a community, we should solve these problems
>> once, and the OpenStack project shouldn't treat them as externalities.
>>  I've been doing some initial coding here:
>> https://github.com/justinsb/openstack-simple-config
>>
>> The first use case I'm trying to solve is "single node installation of
>> OpenStack" that is as easy as possible, but also isn't painting the user
>> into the corner.  Think "apt-get openstack", then the user finds they like
>> it and grows to a 4 node cluster, all the way up to a 100 node cluster.  So
>> it uses KVM, FlatManager, config drive injection, Postgresql, etc. - I'm
>> afraid it is still quite "opinionated"!  I have Keystone, Glance & Nova
>> installing.  I'm using supervisord to avoid any OS dependencies/flamewars,
>> but I would imagine that any OS packager could move it to their preferred
>> init.d flavor easily.  Swift is next on my list - I was facing the problem
>> that the number of replicas isn't changeable, though I have a patch for
>> that now.
>>
>> If you'd like to work together, I'd love to collaborate (and that holds
>> for anyone doing packaging).  I'm hanging out in #openstack-packaging
>>
>> Justin
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Ghe Rivero
> *OpenStack & Distribution Engineer
> **www.stackops.com | * ghe.rivero@xxxxxxxxxxxx<diego.parrilla@xxxxxxxxxxxx>
> ** | +34 625 63 45 23 | skype:ghe.rivero*
> * <http://www.stackops.com/>
> *
>
> *
>
> ******************** ADVERTENCIA LEGAL ********************
> Le informamos, como destinatario de este mensaje, que el correo
> electrónico y las comunicaciones por medio de Internet no permiten asegurar
> ni garantizar la confidencialidad de los mensajes transmitidos, así como
> tampoco su integridad o su correcta recepción, por lo que STACKOPS
> TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias.
> Si no consintiese en la utilización del correo electrónico o de las
> comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro
> conocimiento de manera inmediata. Este mensaje va dirigido, de manera
> exclusiva, a su destinatario y contiene información confidencial y sujeta
> al secreto profesional, cuya divulgación no está permitida por la ley. En
> caso de haber recibido este mensaje por error, le rogamos que, de forma
> inmediata, nos lo comunique mediante correo electrónico remitido a nuestra
> atención y proceda a su eliminación, así como a la de cualquier documento
> adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o
> utilización de este mensaje, o de cualquier documento adjunto al mismo,
> cualquiera que fuera su finalidad, están prohibidas por la ley.
>
> ***************** PRIVILEGED AND CONFIDENTIAL ****************
> We hereby inform you, as addressee of this message, that e-mail and
> Internet do not guarantee the confidentiality, nor the completeness or
> proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L.
> does not assume any liability for those circumstances. Should you not agree
> to the use of e-mail or to communications via Internet, you are kindly
> requested to notify us immediately. This message is intended exclusively
> for the person to whom it is addressed and contains privileged and
> confidential information protected from disclosure by law. If you are not
> the addressee indicated in this message, you should immediately delete it
> and any attachments and notify the sender by reply e-mail. In such case,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message or any attachments, for any purpose, is strictly
> prohibited by law.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>