Re: [openstack-dev] [Solum] Core Reviewer Change

[Julien Vey]

+1

2014-10-01 0:20 GMT+02:00 Angus Salkeld :

> +1
> On 01/10/2014 3:08 AM, "Adrian Otto"  wrote:
>
>> Solum Core Reviewer Team,
>>
>> I propose the following change to our core reviewer group:
>>
>> -lifeless (Robert Collins) [inactive]
>> +murali-allada (Murali Allada)
>> +james-li (James Li)
>>
>> Please let me know your votes (+1, 0, or -1).
>>
>> Thanks,
>>
>> Adrian
>>
>> ___
>> 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

Re: [openstack-dev] [Solum] Core Reviewer Change

[Julien Vey]

+1

Pierre always provide valuable feedback. Glad to see him in the core team


2014-07-09 11:26 GMT+02:00 Adrian Otto :

> Solum Core Reviewer Team,
>
> I propose the following change to our core reviewer group:
>
> +stannie (Pierre Padrixe)
>
> Please let me know your votes (+1, 0, or -1).
>
> Thanks,
>
> Adrian
>
> ___
> 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] [solum] reviews for the new API

[Julien Vey]

Murali, Roshan.

I think there is a misunderstood. By default, the user wouldn't see any
"workflow" dsl. If the user does not specify anything, we would use a
pre-defined mistral workbook defined by Solum, as Adrian described

If the user needs more, mistral is not so complicated. Have a look at this
example Angus has done
https://review.openstack.org/#/c/95709/4/etc/solum/workbooks/build.yaml
We can define anything as solum actions, and the users would just have to
call one of this actions. Solum takes care of the implementation. If we
have comments about the DSL, Mistral's team is willing to help.

Our end-users will be developers, and a lot of them will need a custom
workflow at some point. For instance, if Jenkins has so many plugins, it's
because there are as many custom build workflows, specific to each company.
If we add an abstraction on top of mistral or any other workflow engine, we
will lock developers in our own decisions, and any additional feature would
require a new development in Solum, whereas exposing (when users want it)
mistral, we would allow for any customization.

Julien




2014-06-04 19:50 GMT+02:00 Roshan Agrawal :

>  Agreeing with what Murali said below. We should make things really
> simple for the 99 percentile of the users, and not force the complexity
> needed by the minority of the “advanced users” on the rest of the 99
> percentile users.
>
>
>
> Mistral is a generic workflow DSL, we do not need to expose all that
> complexity to the Solum user that wants to customize the pipeline.
> “Non-advanced” users will have a need to customize the pipeline. In this
> case, the user is not necessarily the developer persona, but typically an
> admin/release manager persona.
>
>
>
> Pipeline customization should be doable easily, without having the
> understand or author a generic workflow DSL.
>
>
>
> For the really advanced user who needs to have a finer grained need to
> tweak the mistral workflow DSL (I am not sure if there will be a use case
> for this if we have the right customizations exposed via the pipeline API),
> we should have the “option” for the user to tweak the mistral DSL directly,
> but we should not expect 99.9% (or more) of the users to deal with a
> generic workflow.
>
>
>
>
>
> *From:* Murali Allada [mailto:murali.all...@rackspace.com]
> *Sent:* Wednesday, June 04, 2014 12:09 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [solum] reviews for the new API
>
>
>
> Angus/Julien,
>
>
>
> I would disagree that we should expose the mistral DSL to end users.
>
>
>
> What if we decide to use something other than Mistral in the future? We
> should be able to plug in any workflow system we want without changing what
> we expose to the end user.
>
>
>
> To me, the pipeline DSL is similar to our plan file. We don't expose a
> heat template to our end users.
>
>
>
> Murali
>
>
>
>
>
>
>
> On Jun 4, 2014, at 10:58 AM, Julien Vey 
>
>  wrote:
>
>
>
>  Hi Angus,
>
>
>
> I really agree with you. I would insist on #3, most of our users will use
> the default workbook, and only advanced users will want to customize the
> workflow. "advanced" users should easily understand a mistral workbook,
> cause they are "advanced"
>
>
>
> To add to the cons of creating our own DSL, it will require a lot more
> work, more design discussions, more maintenance... We might end up doing
> what mistral is already doing. If we have some difficulties with Mistral's
> DSL, we can talk with the team, and contribute back our experience of using
> Mistral.
>
>
>
> Julien
>
>
>
>
>
>
>
>
>
> 2014-06-04 14:11 GMT+02:00 Angus Salkeld :
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all
>
> I have posted this series and it has evoked a surprising (to me) amount
> of discussion so I wanted to clarify some things and talk to some of the
> issues so we can move forward.
>
> So first note is this is an early posting and still is not tested much.
>
>
> https://review.openstack.org/#/q/status:open+project:stackforge/solum+branch:master+topic:new-api,n,z
>
> First the terminology
>I have a pipeline meaning the association between a mistral workbook,
>a trigger url and a plan. This is a running entity not just a
>different workbook.
>
> The main issue seems to be the extent to which I am exposing the mistral
> workbook. Many of you expected a simpler workflow DSL that would be
> converted into the mistral workbook.
>
> The reason for me doing it this way are:
> 1) so we don't have to write much code

Re: [openstack-dev] [solum] reviews for the new API

[Julien Vey]

Hi Angus,

I really agree with you. I would insist on #3, most of our users will use
the default workbook, and only advanced users will want to customize the
workflow. "advanced" users should easily understand a mistral workbook,
cause they are "advanced"

To add to the cons of creating our own DSL, it will require a lot more
work, more design discussions, more maintenance... We might end up doing
what mistral is already doing. If we have some difficulties with Mistral's
DSL, we can talk with the team, and contribute back our experience of using
Mistral.

Julien





2014-06-04 14:11 GMT+02:00 Angus Salkeld :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all
>
> I have posted this series and it has evoked a surprising (to me) amount
> of discussion so I wanted to clarify some things and talk to some of the
> issues so we can move forward.
>
> So first note is this is an early posting and still is not tested much.
>
>
> https://review.openstack.org/#/q/status:open+project:stackforge/solum+branch:master+topic:new-api,n,z
>
> First the terminology
>I have a pipeline meaning the association between a mistral workbook,
>a trigger url and a plan. This is a running entity not just a
>different workbook.
>
> The main issue seems to be the extent to which I am exposing the mistral
> workbook. Many of you expected a simpler workflow DSL that would be
> converted into the mistral workbook.
>
> The reason for me doing it this way are:
> 1) so we don't have to write much code
> 2) this is an iterative process. Let's try it the simple way first and
>only make it more complicated if we really need to (the agile way?).
> 3) to be consistent in the way we treat heat templates, mistral
>workbooks and language packs - i.e. we provide standard ones and
>allow you to customize down to the underlying openstack primitives
>if you want (we should aim for this to be only a small percentage
>of our users).
>eg. pipeline == (check-build-deploy mistral workbook +
> basic-docker heat template + custom plan)
>here the user just choose the heat template and workbook from a list
>of options.
>
> 4) if the mistral dsl is difficult for our users to work with we should
>give the mistral devs a chance to improve it before working around
>it.
> 5) our users are primary developers and I don't think the current
>mistral DSL is tricky to figure out for someone that can code.
> 6) doing it this way we can make use of heat and mistral's horizon
>plugins and link to them from the pipeline instead of having to
>redo all of the same pages. In a similar why that heat links to
>servers/volumes etc from a running stack.
>
> - -Angus
>
>
> Some things to note:
> - - the entire mistral engine can be replaced with an engine level plugin
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTjwz2AAoJEFrDYBLxZjWoEr0H/3nh66Umdw2nGUEs+SikigXa
> XAN90NHHPuf1ssEqrF/rMjRKg+GvrLx+31x4oFfHEj7oplzGeVA9TJC0HOp4h6dh
> iCeXAHF7KX+t4M4VuZ0y9TJB/jLxfxg4Qge7ENJpNDD/gggjMYSNhcWzBG87QBE/
> Mi4YAvxNk1/C3/YZYx2Iujq7oM+6tflTeuoG6Ld72JMHryWT5/tdYZrCMnuD4F7Q
> 8a6Ge3t1dQh7ZlNHEuRDAg3G5oy+FInXyFasXYlYbtdpTxDL8/HbXegyAcsw42on
> 2ZKRDYBubQr1MJKvSV5I3jjOe4lxXXFylbWpYpoU8Y5ZXEKp69R4wrcVISF1jQQ=
> =P0Sl
> -END PGP SIGNATURE-
>
> ___
> 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] [Solum] Environments Use Cases

[Julien Vey]

Hi Roshan,

Happy to see you start the discussion about environments

Angus also started a wiki page on this
https://wiki.openstack.org/wiki/Solum/ApiModel but on a more technical
level.
And we discussed it a little on this review
https://review.openstack.org/#/c/84434/

About the use-cases you described, here are some comments:
#1 : I don't think it should be the developer responsibility to say where
his application gets deployed. It should have been decided during the
creation of the environments, what would be the "chaining" of
environnements. A developer would only push his code to the first
environment, and the promotions are responsible of the rest.
#3 : I think a better way to say it would be "As a release manager, I can
choose how many resources I allocate to each environnement". I don't think
we need "quota" or "threshold"
#4 : Good point!
#6 : The artifact generated by the build job will never get rebuild (a WAR
archive for instance, in case of a Java WebApp), but the DU might be. For
instance, we might want to use docker for Dev/Testing and VMs for production

Regards
Julien


2014-04-14 21:43 GMT+02:00 Roshan Agrawal :

>  As a follow up to our F2F discussion at Raleigh on Environments,  I have
> documented an initial set of use cases as it relates to Environments:
>
> https://wiki.openstack.org/wiki/Solum/Environments
>
>
>
> The goal of this discussion thread on Environments is for the Solum team
> to develop a POV on what Environment is, and which project(s) in OpenStack
> should own it. With this, we should be able to go into the Atlanta summit
> and engage in discussions with the relevant project teams.
>
>
>
> We can discuss in the IRC meeting tomorrow, meanwhile would appreciate
> your feedback on what is documented above.
>
>
>
> Thanks & Regards,
>
> *Roshan Agrawal*
>
> Direct:512.874.1278
>
> Mobile:  512.354.5253
>
> roshan.agra...@rackspace.com
>
>
>
> ___
> 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] [Solum] Question about Zuul's role in Solum

[Julien Vey]

Hi,

I have some concerns about using Zuul in Solum

I agree gating is a great feature but it is not useful for every project
and as Adrian said, not understood by everyone.
I think many Solum users, and PaaS users in general, are
single-project/single-build/simple git worklow and do not care about gating.

I see 2 drawbacks with Zuul :
- Tenant Isolation : How do we allow access on zuul (and jenkins) for a
specific tenant in isolation to the others tenants using Solum.
- Build customization : One of the biggest advantage of Jenkins is its
ecosystem and the many build customization it offers. Using zuul will
prohibit this.

About Gerrit, I think it is also a little too much. Many users have their
own reviewing system, Pull requests with github, bitbucket or stash, their
own instance of gerrit, or even a custom git workflow.
Gerrit would be a great feature for future versions of Solum. but only as
an optionnal one, we should not force people into it.

Julien

2014-02-13 5:47 GMT+01:00 Clark Boylan :

> On Wed, Feb 12, 2014 at 7:25 PM, Noorul Islam K M 
> wrote:
> > "devdatta kulkarni"  writes:
> >
> >> Hi,
> >>
> >> I have been looking at Zuul for last few days and had a question
> >> about its intended role within Solum.
> >>
> >> From what I understand, Zuul is a code gating system.
> >>
> >> I have been wondering if code gating is something we are considering as
> a feature
> >> to be provided in Solum? If yes, then Zuul is a perfect fit.
> >> But if not, then we should discuss what benefits do we gain by using
> Zuul
> >> as an integral part of Solum.
> >>
> >> It feels to me that right now we are treating Zuul as a conduit for
> triggering job(s)
> >> that would do the following:
> >> - clone/download source
> >> - run tests
> >> - create a deployment unit (DU) if tests pass
> >> - upload DU to glance
> >> - trigger the DU deployment workflow
> >>
> >> In the language-pack working group we have talked about being able to do
> >> CI on the submitted code and building the DUs only after tests pass.
> >> Now, there is a distinction between doing CI on merged code vs.
> >> doing it before code is permanently merged to master/stable branches.
> >> The latter is what a 'code gating' system does, and Zuul is a perfect
> fit for this.
> >> For the former though, using a code gating system is not be needed.
> >> We can achieve the former with an API endpoint, a queue,
> >> and a mechanism to trigger job(s) that perform above mentioned steps.
> >>
> >> I guess it comes down to Solum's vision. If the vision includes
> supporting, among other things, code gating
> >> to ensure that Solum-managed code is never broken, then Zuul is a
> perfect fit.
> >> Of course, in that situation we would want to ensure that the gating
> functionality is pluggable
> >> so that operators can have a choice of whether to use Zuul or something
> else.
> >> But if the vision is to be that part of an overall application
> lifecycle management flow which deals with
> >> creation and scaling of DUs/plans/assemblies but not necessarily be a
> code gate, then we should re-evaluate Zuul's role
> >> as an integral part of Solum.
> >>
> >> Thoughts?
> >>
> >
> > Is Zuul tightly couple with launchpad? I see that most of the
> > information that it displays is coming from launchpad.
> >
> > If it is, is it a good idea to force launchpad on users?
> >
> > Regards,
> > Noorul
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> I can't think of any places that Zuul requires launchpad (or displays
> launchpad info for that matter). It is a bit coupled to Gerrit on one
> end and Gearman on the other, but not in an extreme way (the use of
> Gearman makes a bunch of sense imo, but having additional triggers
> instead of just Gerrit sounds great to me).
>
> Clark
>
> ___
> 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] [solum] Issues in running tests

[Julien Vey]

Hi Rajdeep,

We just updated the
documentation
recently
with some necessary packages to install :  *libxml2-dev* and *libxslt-dev*.
You just need to install those 2 packages.
If you are on Ubuntu, see
http://stackoverflow.com/questions/6504810/how-to-install-lxml-on-ubuntu/6504860#6504860

Julien


2014-02-02 Rajdeep Dua :

> Hi,
> I am facing some errors running tests in a fresh installation of solum
>
> $tox -e py27
>
> 
>
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fPIC
> -I/home/hadoop/work/openstack/solum-2/solum/.tox/py27/build/lxml/src/lxml/includes
> -I/usr/include/python2.7 -c src/lxml/lxml.etree.c -o
> build/temp.linux-x86_64-2.7/src/lxml/lxml.etree.o -w
>
> In file included from src/lxml/lxml.etree.c:340:0:
>
> /home/hadoop/work/openstack/solum-2/solum/.tox/py27/build/lxml/src/lxml/includes/etree_defs.h:9:31:
> fatal error: libxml/xmlversion.h: No such file or directory
>
> compilation terminated.
>
> error: command 'gcc' failed with exit status 1
>
> 
>
>
> Thanks
> Rajdeep
>
> ___
> 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