Re: [OpenStack-Infra] [jjb] What's the deal with {{?

[Ian Wienand]

On 08/13/2015 08:19 PM, Darragh Bailey wrote:

macros do not get substitution performed unless you provide a
variable to be substituted in.


Thanks; that makes some sense when you grok what's going on,
especially as to why job-templates require it but other macros don't.

I have proposed [1] to better document the situation as it stands.


I wonder if jinja templating would avoid some of the quirks we run
into around using python's string formatting for substitution?



So I feel like jjb could probably do better even given the status-quo
-- if it bailed on missing parameters to shell-builders (or, always
expanded -- in essence the same thing), then we would *always* just
put "${{FOO}}" when we want "${FOO}" in the output.

As it stands, sometimes we take the "short-cut" of letting no
parameters represent "pass-through" -- but that leads to the rather
confusing inconsistency we have now.

I proposed [2]; jjb is more complex than I expected (duh!) so
interested if it can be made to work.

-i

[1] https://review.openstack.org/212952
[2] https://review.openstack.org/212980

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] ProphetStor CI account

[Asselin, Ramy]

Hi Rick,


In general, to get your account re-enabled, you need permission from the team 
that requested the account to be disabled. In this case it's the cinder team, 
not the infra team [1]

So you should post to the general developer list [2]. Add the tags [cinder] and 
[third-party] to get better attention.

A few comments.

1.   Logs need to be browsable online [3]

2.   Make sure you include all the required files [4]. There are quite a 
few missing, such as the test configuration (cinder.conf, tempest.conf, 
localrc, local.conf, etc.)

3.   You need to run all volume tests. Use regex volume [5]


Ramy

[1] 
http://docs.openstack.org/infra/system-config/third_party.html#permissions-on-your-third-party-system

[2]  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[3] 
http://docs.openstack.org/infra/system-config/third_party.html#faq-frequently-asked-questions

[4] http://docs.openstack.org/infra/system-config/third_party.html#requirements

[5] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers




___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] ProphetStor CI account

[Mike Perez]

On 23:21 Aug 13, Rick Chen wrote:
> Dear Infra team,
> 
>  
> 
> I already fixed my CI machine about failed to build up the devstack issue.
> Can you re-enable my CI gerrit account?
> 
> Account : prophetstor-ci
> 
> Account email: prophetstor...@prophetstor.com
>  
> 
>  
> 
> Latest CI verify report:
> 
> http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
> vm-tempest-cinder-ci/5043/console.html

Hi Rick,

This is the second time [1] I raised a problem with the Prophetstor CI. You
said you would then fix things [2], but my email went unaswered [3].

"I will fix it" is not going to cut it this time. I want actual answers on how
you're fixing this so we can stop this dance. Also what are you doing for
monitoring, instead of me having to notify you?

[1] - 
http://lists.openstack.org/pipermail/third-party-announce/2015-June/000192.html
[2] - 
http://lists.openstack.org/pipermail/third-party-announce/2015-June/000193.html
[3] - 
http://lists.openstack.org/pipermail/third-party-announce/2015-June/000219.html

-- 
Mike Perez

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Using ensure=>running by default in Puppet modules

[Yolanda Robla Mota]

Ok, but i continue seeing ths problem again between what infra says it's 
reasonable,
and i fully believe your are right, and what downstream users are 
expecting on that.


So why be opinionated on it? My opinion is to add the possibility to the 
module,
defaulting to false so when an user enables it, it's fully aware about 
what he is doing

and the consequences it may have.

El 13/08/15 a las 18:23, James E. Blair escribió:

Fabien Boucher  writes:


Hi,

I apologize I wasn't here yesterday to discuss about that on IRC.
I was surprised also about not letting puppet ensuring that the service is 
running and
now I understand well the reason behind it. But I think too, that for
most of downstream users (like those of puppet-openstackci) the most obvious 
behavior
is running by default. Having a switch to disable the default and disabling it 
in
system-config seems fine.

Furthermore an explanation as a comment about why we deactivate it from
system-config is good to have.

That's okay, we're trying to have this conversation on the mailing list
to make sure it's widely seen and participated in.  We're not doing a
great job of that, but we'll keep trying.  :)

Anyway, I think Jeremy described the history and our thinking well.

My preference would be to generally "enable=>true" but not
"ensure=>running".  For some of our services, having them start before a
sysadmin has verified the state of the system can be dangerous (think
Gerrit publishing a malformed git repo to github).  Moreover, sometimes
we need to stop those services for a brief time to fix something, and
having puppet automatically restart them could be dangerous.  We could
stop puppet, and sometimes we do, but that is an extra thing someone
needs to remember to do.  But more importantly, sometimes we stop a
service, then run puppet to apply a configuration change, then start it
again after verification or further work.  That is impossible to do if
puppet sets "ensure=>running".

Put another way, I believe our overall strategy is to use puppet as a
configuration management system, but not an orchestration system.  We're
moving towards using ansible as the orchestration system.  It turns out
that generally the desire to have "ensure=>running" set mostly comes
from wanting a newly launched server to have its services running.  The
orchestration system that launched the server is uniquely situated to
understand that it is running the bring-up of the server, and whether
any external dependencies are prepared for the server start.  So if we
want to automate that, I believe that is the place to do it.

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hp.com


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Using ensure=>running by default in Puppet modules

[Jeremy Stanley]

On 2015-08-13 09:16:46 -0700 (-0700), Colleen Murphy wrote:
[...]
> Downstream users of a puppet module will always expect the
> module to [...] start services.
[...]

I find it hard to believe that this is a common expectation among
system administrators, but it may be a cultural/generational bias?

When a daemon/service crashes, most of the time I don't want it
automatically started back up. Who knows what damage it may do? I
want it to stay down _hard_ until I can take a look at it and see
what's wrong, and make sure it's safe to be started back.
Unfortunately if puppet has ensure=>running and sees the service has
died, it will helpfully try to resuscitate it for you (perhaps over
and over and over and over and... or perhaps successfully and so
quickly that you won't know there's actually a problem you needed to
be aware of).
-- 
Jeremy Stanley

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Using ensure=>running by default in Puppet modules

[Colleen Murphy]

On Wed, Aug 12, 2015 at 2:15 PM, Jeremy Stanley  wrote:

> Change https://review.openstack.org/168306 for puppet-zuul came to
> my attention earlier today when it merged. After a quick discussion
> on IRC, Spencer proposed a revert which I approved so that we can
> get a little more discussion going about this topic.
>
> First, I'm really sorry I didn't see and weigh in on it sooner (it's
> not like I didn't have time, it was ~4.5 months old). Second, we've
> grown lots of new core reviewers and I'm thrilled they're reviewing
> and approving changes, and I don't want to discourage that in any
> way, so thank you to those of you who did review that change.
>
> In the past, not using ensure=>running on services in our Puppet
> modules was intentional, particularly for more stateful services,
> especially for services which trigger other (possibly remote)
> actions and have a potential to make a mess. It's pretty likely that
> those of us who were around for the earlier discussions about it
> failed to write it down anywhere obvious, leading others to assume
> it's a bug/oversight. I see a couple of obvious solutions though
> there are no doubt others:
>
> 1. Document in each module where we do this, at least in the readme
> and probably also in an inline comment around the service
> definition, that it's that way on purpose. Optionally, make the
> ensure conditional on a class parameter that defaults to unmanaged
> in case some downstreams want to use Puppet like a service manager.
>
> 2. Similar managed/unmanaged parameter, but make it default to
> running and override the default to unmanaged in our
> ::openstack_project classes. This means that we cease consuming our
> modules with the same defaults as downstream users, however if it
> turns out that our OpenStack Infra root sysadmins really do have a
> very different preference from the majority of our downstream
> consumers then at least we can be clear about that.
>
I am in favor of the managed/unmanaged parameter (I don't have a preference
for the default).

Managing the state of a service is one of the most fundamental features of
puppet[1]. Downstream users of a puppet module will always expect the
module to install packages, change config files, and start services. They
are expecting puppet to do automate everything within a single node. If
they are doing maintenance and they do not want packages installed, config
files changed, or services started, they will disable puppet during the
maintenance window. While this does not appear to fit in with Infra's
workflow, it is a valid use case for downstream users and I believe it
should be allowed via a parameter. Of course documenting the unexpected
behavior is the next best thing.

Colleen

[1] https://docs.puppetlabs.com/puppet_core_types_cheatsheet.pdf

> --
> Jeremy Stanley
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Using ensure=>running by default in Puppet modules

[James E. Blair]

Fabien Boucher  writes:

> Hi,
>
> I apologize I wasn't here yesterday to discuss about that on IRC.
> I was surprised also about not letting puppet ensuring that the service is 
> running and
> now I understand well the reason behind it. But I think too, that for
> most of downstream users (like those of puppet-openstackci) the most obvious 
> behavior
> is running by default. Having a switch to disable the default and disabling 
> it in
> system-config seems fine.
>
> Furthermore an explanation as a comment about why we deactivate it from
> system-config is good to have.

That's okay, we're trying to have this conversation on the mailing list
to make sure it's widely seen and participated in.  We're not doing a
great job of that, but we'll keep trying.  :)

Anyway, I think Jeremy described the history and our thinking well.

My preference would be to generally "enable=>true" but not
"ensure=>running".  For some of our services, having them start before a
sysadmin has verified the state of the system can be dangerous (think
Gerrit publishing a malformed git repo to github).  Moreover, sometimes
we need to stop those services for a brief time to fix something, and
having puppet automatically restart them could be dangerous.  We could
stop puppet, and sometimes we do, but that is an extra thing someone
needs to remember to do.  But more importantly, sometimes we stop a
service, then run puppet to apply a configuration change, then start it
again after verification or further work.  That is impossible to do if
puppet sets "ensure=>running".

Put another way, I believe our overall strategy is to use puppet as a
configuration management system, but not an orchestration system.  We're
moving towards using ansible as the orchestration system.  It turns out
that generally the desire to have "ensure=>running" set mostly comes
from wanting a newly launched server to have its services running.  The
orchestration system that launched the server is uniquely situated to
understand that it is running the bring-up of the server, and whether
any external dependencies are prepared for the server start.  So if we
want to automate that, I believe that is the place to do it.

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Using ensure=>running by default in Puppet modules

[Paul Belanger]

On Wed, Aug 12, 2015 at 09:15:37PM +, Jeremy Stanley wrote:
> Change https://review.openstack.org/168306 for puppet-zuul came to
> my attention earlier today when it merged. After a quick discussion
> on IRC, Spencer proposed a revert which I approved so that we can
> get a little more discussion going about this topic.
> 
> First, I'm really sorry I didn't see and weigh in on it sooner (it's
> not like I didn't have time, it was ~4.5 months old). Second, we've
> grown lots of new core reviewers and I'm thrilled they're reviewing
> and approving changes, and I don't want to discourage that in any
> way, so thank you to those of you who did review that change.
> 
> In the past, not using ensure=>running on services in our Puppet
> modules was intentional, particularly for more stateful services,
> especially for services which trigger other (possibly remote)
> actions and have a potential to make a mess. It's pretty likely that
> those of us who were around for the earlier discussions about it
> failed to write it down anywhere obvious, leading others to assume
> it's a bug/oversight. I see a couple of obvious solutions though
> there are no doubt others:
> 
> 1. Document in each module where we do this, at least in the readme
> and probably also in an inline comment around the service
> definition, that it's that way on purpose. Optionally, make the
> ensure conditional on a class parameter that defaults to unmanaged
> in case some downstreams want to use Puppet like a service manager.
> 
> 2. Similar managed/unmanaged parameter, but make it default to
> running and override the default to unmanaged in our
> ::openstack_project classes. This means that we cease consuming our
> modules with the same defaults as downstream users, however if it
> turns out that our OpenStack Infra root sysadmins really do have a
> very different preference from the majority of our downstream
> consumers then at least we can be clear about that.

I would suggest doing what the openstack puppet modules do for openstack
services. Puppet-keystone has a good example[1].  Then, we can toggle the
settings in system-config.

TL;DR - Add manage_service and enabled flags, defaulting them to true.

[1] 
https://github.com/openstack/puppet-keystone/blob/master/manifests/init.pp#L830

> -- 
> Jeremy Stanley
> 
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] ProphetStor CI account

[Rick Chen]

Dear Infra team,

 

I already fixed my CI machine about failed to build up the devstack issue.
Can you re-enable my CI gerrit account?

Account : prophetstor-ci

Account email: prophetstor...@prophetstor.com
 

 

Latest CI verify report:

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
vm-tempest-cinder-ci/5043/console.html

 

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [Openstack-Infra][CI][Keystone] Starting keystone failing in Devstack for CI

[Jeremy Stanley]

On 2015-08-13 13:48:17 +0530 (+0530), Abhishek Shrivastava wrote:
> In my CI while starting Keystone the service is failing and showing the
> following ERROR:
[...]
> 2015-08-13 08:08:58.937 | +++ openstack --os-url=http://127.0.0.1:5000/v3
> --os-identity-api-version=3 project create admin --domain=default --or-show
> -f value -c id
> *2015-08-13 08:09:01.806 | ERROR: openstack Missing parameter(s):*
> *2015-08-13 08:09:01.807 | Set a service URL, with --os-url, OS_URL or
> auth.url*
> 
> Can anyone help me to resolve this because if it throwing false ERRORS to
> the patches.

It's possible this is the os-client-config 1.6.2 related error
mentioned in Robert's E-mail to openstack-dev today:

http://lists.openstack.org/pipermail/openstack-dev/2015-August/071951.html

It looks like the offending change has been reverted and tagged as
1.6.3 about 4 hours ago.
-- 
Jeremy Stanley

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Using ensure=>running by default in Puppet modules

[Fabien Boucher]

Hi,

I apologize I wasn't here yesterday to discuss about that on IRC.
I was surprised also about not letting puppet ensuring that the service is 
running and
now I understand well the reason behind it. But I think too, that for
most of downstream users (like those of puppet-openstackci) the most obvious 
behavior
is running by default. Having a switch to disable the default and disabling it 
in
system-config seems fine.

Furthermore an explanation as a comment about why we deactivate it from
system-config is good to have.

Best regards,
Fabien

On 13/08/2015 11:07, Ricardo Carrillo Cruz wrote:
> I lean towards the second option that Jeremy pointed out.
> 
> External users just expect Puppet to bring up services configured by the 
> module, it makes sense to me having 'running' as default and override that at 
> the node or wrapper module.
> 
> Regards
> 
> El 13/8/2015 8:30, "Yolanda Robla Mota"  > escribió:
> 
> Hi
> It's great that you expose that because this review passed through a lot
> of eyes and we all +2, we all assumed that the manifest not managing
> the zuul services was a bug.
> From my perspective, i see advantages on puppet managing these
> services, but I can understand that not all end users will want the
> same.
> Advantages I see for managing services are:
> 
> 1. Manual intervention. If you don't have any extra orchestration
> layer on top, such as ansible, you need manual steps to spin up these
> services. That can be a blocker for some workflows, such as
> automated testing.
> 
> 2. Reliability. It can be better or worse option, but letting puppet
> manage the services can be a life-saver if for some reason the
> service goes down. For example i've had several problems with zuul-merger
> services being down and no one noticing it until reviews started to
> fail. Having puppet watching these cannot be the better solution but
> it works on the simplest environments.
> 
> So having said that, i think that the parameter option is a good one.
> Provide a parameter to zuul, to show if we want it to manage the
> services or not, and let end users decide.
> 
> Best
> Yolanda
> 
> El 12/08/15 a las 23:15, Jeremy Stanley escribió:
> 
> Change https://review.openstack.org/168306 for puppet-zuul came to
> my attention earlier today when it merged. After a quick discussion
> on IRC, Spencer proposed a revert which I approved so that we can
> get a little more discussion going about this topic.
> 
> First, I'm really sorry I didn't see and weigh in on it sooner (it's
> not like I didn't have time, it was ~4.5 months old). Second, we've
> grown lots of new core reviewers and I'm thrilled they're reviewing
> and approving changes, and I don't want to discourage that in any
> way, so thank you to those of you who did review that change.
> 
> In the past, not using ensure=>running on services in our Puppet
> modules was intentional, particularly for more stateful services,
> especially for services which trigger other (possibly remote)
> actions and have a potential to make a mess. It's pretty likely that
> those of us who were around for the earlier discussions about it
> failed to write it down anywhere obvious, leading others to assume
> it's a bug/oversight. I see a couple of obvious solutions though
> there are no doubt others:
> 
> 1. Document in each module where we do this, at least in the readme
> and probably also in an inline comment around the service
> definition, that it's that way on purpose. Optionally, make the
> ensure conditional on a class parameter that defaults to unmanaged
> in case some downstreams want to use Puppet like a service manager.
> 
> 2. Similar managed/unmanaged parameter, but make it default to
> running and override the default to unmanaged in our
> ::openstack_project classes. This means that we cease consuming our
> modules with the same defaults as downstream users, however if it
> turns out that our OpenStack Infra root sysadmins really do have a
> very different preference from the majority of our downstream
> consumers then at least we can be clear about that.
> 
> 
> -- 
> Yolanda Robla Mota
> Cloud Automation and Distribution Engineer
> +34 605641639 
> yolanda.robla-m...@hp.com 
> 
> 
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 
> 
> 
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.op

Re: [OpenStack-Infra] IBM XIV CI account

[Mikhail Medvedev]

Hi Isaac,

  I have added your new account (ibmxi...@il.ibm.com) to the Third-Party CI
gerrit group and have removed the old one. Someone from the Infra team
would still need to deactivate your old gerrit account.

Mikhail Medvedev (irc:mmedvede)
IBM PowerKVM CI


On Wed, Aug 12, 2015 at 12:58 AM, Isaac Beckman  wrote:

> Dear Infra team,
>
> A new CI account was created for IBM XIV as we could not edit the ssh
> public key that was assigned to the original account.
> We did this after we saw the following thread
> 
>
> The new account is:
> Account full name:* IBM XIV CI*
> Account email:* ibmxi...@il.ibm.com *
>
> The old account was connected to a private mail address (alo...@il.ibm.com)
> rather then having a dedicated mail address for it
> Please take care of cleaning up the old account. Need to make sure that
> you are not cleaning the personal gerrit account of Alon Marx which is also
> connected to the address: alo...@il.ibm.com
>
> Thanks,
> Isaac Beckman
>
> Office: +972-3-6897874
> Fax: +972-3-6897755
> Mobile: +972-50-2680180
> Email: isa...@il.ibm.com
>
> IBM XIV, Cloud Storage Solutions (previously HSG)
> www.ibm.com/storage/disk/xiv
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [jjb] What's the deal with {{?

[Darragh Bailey]

Hi,


macros do not get substitution performed unless you provide a variable to
be substituted in.


Following would trigger the behaviour:


- job-template:
name: '{foo}-test'
builders:
  - test_builder:
  FOO_BAR: hello
  - shell: |
  echo ${{FOO_3}}


Definitely a bit confusing, essentially the macro is added in through a
lookup in the register.ModuleRegistry.dispatch() method, where only if the
component is a dict is a substitution performed:
https://github.com/openstack-infra/jenkins-job-builder/blob/4a8b93b8c2d517c8dc27d91437454890cc49a640/jenkins_jobs/registry.py#L149-L168


I wonder if jinja templating would avoid some of the quirks we run into
around using python's string formatting for substitution?


On 13 August 2015 at 07:05, Ian Wienand  wrote:

> Hi,
>
> Just trying to get my head around this from [1]:
>
> ---
>
> - builder:
> name: test_builder
> builders:
>   - shell: |
>echo ${FOO_1}
>echo ${{FOO_2}}
>
> - job-template:
> name: '{foo}-test'
> builders:
>   - test_builder
>   - shell: |
>echo ${{FOO_3}}
>
> - project:
> name: 'foo'
> jobs:
>   - '{foo}-test':
>  foo: bar
>
> ---
>
> that's going to output a job basically
>
> ---
> echo ${FOO_1}
> echo ${{FOO_2}}
> echo ${FOO_3}
> ---
>
> Why do I *not* get a "FOO_1 parameter missing" for test_builder?  If I
> do
>
> ---
>
>   - test_builder:
>   FOO_1: bar
>
> ---
>
> it does actually come out with "echo $bar" as you might expect.
>
> Or the same question in reverse: why *do* I get an error about a
> missing parameter if I have just "${FOO_3}" in the job-template?
>
> I can't find a clear explanation for this, although there might be
> one I'm missing.  If I can find one, I'll add it to some sort of
> documentation.
>
> -i
>
> [1] https://review.openstack.org/#/c/212246
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>



-- 
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [Openstack-Infra][CI][Keystone] Starting keystone failing in Devstack for CI

[Abhishek Shrivastava]

Hi Folks,

Please reply for this issue as its causing a lot of trouble now.

On Thu, Aug 13, 2015 at 2:43 PM, Abhishek Shrivastava <
abhis...@cloudbyte.com> wrote:

> Hi Folks,
>
> In my CI while starting Keystone the service is failing and showing the
> following ERROR:
>
> 2015-08-13 08:08:58.935 | + export OS_TOKEN=111222333444
> 2015-08-13 08:08:58.935 | + OS_TOKEN=111222333444
> 2015-08-13 08:08:58.935 | + export OS_URL=http://127.0.0.1:35357/v2.0
> 2015-08-13 08:08:58.935 | + OS_URL=http://127.0.0.1:35357/v2.0
> 2015-08-13 08:08:58.935 | + create_keystone_accounts
> 2015-08-13 08:08:58.936 | ++ get_or_create_project admin default
> 2015-08-13 08:08:58.936 | ++ local project_id
> 2015-08-13 08:08:58.937 | +++ openstack --os-url=http://127.0.0.1:5000/v3
> --os-identity-api-version=3 project create admin --domain=default --or-show
> -f value -c id
> *2015-08-13 08:09:01.806 | ERROR: openstack Missing parameter(s):*
> *2015-08-13 08:09:01.807 | Set a service URL, with --os-url, OS_URL or
> auth.url*
>
> Can anyone help me to resolve this because if it throwing false ERRORS to
> the patches.
>
> --
>
>
> *Thanks & Regards,*
> *Abhishek*
> *Cloudbyte Inc. *
>
>
>
> --
>
>
> *Thanks & Regards,*
> *Abhishek*
> *Cloudbyte Inc. *
>



-- 


*Thanks & Regards,*
*Abhishek*
*Cloudbyte Inc. *
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Using ensure=>running by default in Puppet modules

[Ricardo Carrillo Cruz]

I lean towards the second option that Jeremy pointed out.

External users just expect Puppet to bring up services configured by the
module, it makes sense to me having 'running' as default and override that
at the node or wrapper module.

Regards
El 13/8/2015 8:30, "Yolanda Robla Mota" 
escribió:

> Hi
> It's great that you expose that because this review passed through a lot
> of eyes and we all +2, we all assumed that the manifest not managing
> the zuul services was a bug.
> From my perspective, i see advantages on puppet managing these
> services, but I can understand that not all end users will want the
> same.
> Advantages I see for managing services are:
>
> 1. Manual intervention. If you don't have any extra orchestration
> layer on top, such as ansible, you need manual steps to spin up these
> services. That can be a blocker for some workflows, such as
> automated testing.
>
> 2. Reliability. It can be better or worse option, but letting puppet
> manage the services can be a life-saver if for some reason the
> service goes down. For example i've had several problems with zuul-merger
> services being down and no one noticing it until reviews started to
> fail. Having puppet watching these cannot be the better solution but
> it works on the simplest environments.
>
> So having said that, i think that the parameter option is a good one.
> Provide a parameter to zuul, to show if we want it to manage the
> services or not, and let end users decide.
>
> Best
> Yolanda
>
> El 12/08/15 a las 23:15, Jeremy Stanley escribió:
>
>> Change https://review.openstack.org/168306 for puppet-zuul came to
>> my attention earlier today when it merged. After a quick discussion
>> on IRC, Spencer proposed a revert which I approved so that we can
>> get a little more discussion going about this topic.
>>
>> First, I'm really sorry I didn't see and weigh in on it sooner (it's
>> not like I didn't have time, it was ~4.5 months old). Second, we've
>> grown lots of new core reviewers and I'm thrilled they're reviewing
>> and approving changes, and I don't want to discourage that in any
>> way, so thank you to those of you who did review that change.
>>
>> In the past, not using ensure=>running on services in our Puppet
>> modules was intentional, particularly for more stateful services,
>> especially for services which trigger other (possibly remote)
>> actions and have a potential to make a mess. It's pretty likely that
>> those of us who were around for the earlier discussions about it
>> failed to write it down anywhere obvious, leading others to assume
>> it's a bug/oversight. I see a couple of obvious solutions though
>> there are no doubt others:
>>
>> 1. Document in each module where we do this, at least in the readme
>> and probably also in an inline comment around the service
>> definition, that it's that way on purpose. Optionally, make the
>> ensure conditional on a class parameter that defaults to unmanaged
>> in case some downstreams want to use Puppet like a service manager.
>>
>> 2. Similar managed/unmanaged parameter, but make it default to
>> running and override the default to unmanaged in our
>> ::openstack_project classes. This means that we cease consuming our
>> modules with the same defaults as downstream users, however if it
>> turns out that our OpenStack Infra root sysadmins really do have a
>> very different preference from the majority of our downstream
>> consumers then at least we can be clear about that.
>>
>
> --
> Yolanda Robla Mota
> Cloud Automation and Distribution Engineer
> +34 605641639
> yolanda.robla-m...@hp.com
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet lint checks for system-config

[Yolanda Robla Mota]

I agree with you Jim, but sadly it's a practice in the reality to -1 for
nitpicks or even for questions.
I'd prefer if that nitpicks can be flagged, but as a comment, so they
can be corrected in future iterations if the patch needs more work,
but not a blocking -1.
Also same as -1 for questions, it's really a problem sometimes, because
even if you answer the question, that -1 remains there until the people
who asked reviews again, and prevents changes to land.
I admit I also do that sometimes, because I have the perception that
if i just add a coment and not flag with -1 or +1, i get less attention
from the person being reviewed. We should find ways to solve it.

So i'm glad that this conversation raised, and that this improves us
on review quality and speed.

Best
Yolanda

El 12/08/15 a las 18:00, James E. Blair escribió:

Paul Belanger  writes:

...

However, recently. I got my hand smacked in 2 different code reviews for arrow
alignment issues. Honestly, I wasn't even mad about the -1 for the alignment.
However, I'm concerned about the wasted effort the -1 caused me. Basically, I
had to wait a few days to get the -1, since it was a human doing the review, not
the gate. Additionally, if I was getting a -1 for style checks, why didn't
jenkins do it?

To me, this is the crux of the problem.  It's okay for us to have a
conversation about whether we want to change the lint rules for
system-config, but for the moment, we have chosen to have them
disabled (let's set that conversation aside for now).

Consider that when you leave a -1 on a code review, you are asking a
contributor to go back and re-do their work.  You are also asking other
reviewers to re-review a change.  It's a lot of work, and to do it
frivolously means we are wasting peoples' time.  So, please, when you
think about whether to leave a -1, don't think "Aha!  I found something
that could be improved!", instead think "I found something, but is it
worth redoing already completed work?"

In particular, many of us have a very strong aversion to nitpicking
about whitespace.  In many cases, we are not in universal agreement on
what constitutes the most aesthetically pleasing indentation.  In these
cases, we often loosen the enforcement of our tools so that a wider
variety of possibilities is accepted.  If we've made such a choice,
consider embracing the philosophy of IDIC and accepting that there may
be more than one way to wrap a line.

I have proposed a change to system-config to document what we look for
in code-review, and what should and should not constitute a -1, so that
new folks have some background:

https://review.openstack.org/#/c/212073/

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hp.com


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [Openstack-Infra][CI][Keystone] Starting keystone failing in Devstack for CI

[Abhishek Shrivastava]

Hi Folks,

In my CI while starting Keystone the service is failing and showing the
following ERROR:

2015-08-13 08:08:58.935 | + export OS_TOKEN=111222333444
2015-08-13 08:08:58.935 | + OS_TOKEN=111222333444
2015-08-13 08:08:58.935 | + export OS_URL=http://127.0.0.1:35357/v2.0
2015-08-13 08:08:58.935 | + OS_URL=http://127.0.0.1:35357/v2.0
2015-08-13 08:08:58.935 | + create_keystone_accounts
2015-08-13 08:08:58.936 | ++ get_or_create_project admin default
2015-08-13 08:08:58.936 | ++ local project_id
2015-08-13 08:08:58.937 | +++ openstack --os-url=http://127.0.0.1:5000/v3
--os-identity-api-version=3 project create admin --domain=default --or-show
-f value -c id
*2015-08-13 08:09:01.806 | ERROR: openstack Missing parameter(s):*
*2015-08-13 08:09:01.807 | Set a service URL, with --os-url, OS_URL or
auth.url*

Can anyone help me to resolve this because if it throwing false ERRORS to
the patches.

-- 


*Thanks & Regards,*
*Abhishek*
*Cloudbyte Inc. *
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra