Re: [Crowbar] Gemfile.lock in git or not?

[Adam Spiers]

Haselwanter Edmund (edm...@haselwanter.com) wrote:
> On 26.02.2013, at 15:36, andi_a...@dell.com wrote:
> > I think Wayne is just adding Gemfile.lock to the ignore file...
>
> http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

I read that a long time ago.  It's a good, simplistic view which
applies to the majority of Rails apps, but unfortunately not to
Crowbar due to the various ways it needs to be productised.  I wrote
this page to attempt to deal with some of the very complex issues
which arise in this context:

  http://en.opensuse.org/openSUSE:Ruby_Gem_Strategies

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Question abourt multiple proposals

[Adam Spiers]

Guillaume Polaert (gpola...@cyres.fr) wrote:
> Hi,
> 
> Can I have multiple proposals for one BC in the v1.x?

Absolutely.

> For instance, I have two instances of the same service running on my
> cloud. Each has his own configuration (port, directories, etc.). Do
> I have to have 2 BC as "Service1" and "Service2" or can I have on BC
> with 2 proposals?

2 proposals - Crowbar allows this for precisely this use case.  In 2.0
they are called 'deployments', so you could have e.g. a 'test'
deployment and a 'production' deployment.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Using apache (mod_proxy, mod_cache) instead of polipo for the proxy?

[Adam Spiers]

Ralf Haferkamp (rha...@suse.de) wrote:
> Hi,
> 
> currenlty the provisioner barclamps sets up a polipo instance on the admin 
> node
> to act as a proxy for the client nodes (AFAIK to be able to access remote 
> package
> repositories). Is there any specific reason why polipo was choosen for this?
> Instead of e.g. choosing apache2?
> I am asking because I'd like to avoid adding a dependency to yet another web
> server to crowbar (+openstack). Currenlty we already have apache2 and nginx.
> Note: for our 1.x based release we avoided the use of nginx and used apache2
> everywhere). 

+1 for minimising web server dependencies.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] [Still Failing] crowbar/travis-ci-crowbar#25 (master - 0d171b7)

[Adam Spiers]

christopher_dearb...@dell.com (christopher_dearb...@dell.com) wrote:
> This issue is because “dev setup-unit-tests” doesn’t currently copy
> the network helper class into the dev testing area, which it used to
> do before the network barclamp was converted to a rails engine.
> Wayne has a task to fix this in a general way this sprint

Thanks for the info.  Wayne, how is that going to work?  Would be
useful to know for my work on Travis and ./dev.

> but in the interim, Rob has hacked in a temporary fix in this pull:
> 
>   https://github.com/crowbar/barclamp-crowbar/pull/422
> which I just reviewed and merged.
> 
> Try another run, and you should get past the network barclamp issues now…

Still seeing errors - looking into it now.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] barclamp-network unit test failures

[Adam Spiers]

I'm getting test failures due to what looks like a bug in 
network_test_helper.rb:

1) Error:

test_ConduitRule.build_if_remap:_Remap_with_known_product_name(ConduitRuleTest):
ActiveRecord::StatementInvalid: SQLite3::SQLException: unrecognized token: 
"{I" eth0:EF{I"  path;": UPDATE "attribs" SET "jig_run_id" = 0, 
"value_actual" = {I" eth0:EF{I"  
path;FI"&:00/:00:02.0/:02:01:0;FI"   speeds;F[I"   
100m;FI"1g;FI"  eth1;F{I"   path;FI"&:00/:00:04.0/:02:02:0;FI"  
speeds;F[I"1g;FI10g;F', "updated_at" = '2013-03-04 
16:34:20.839885' WHERE "attribs"."type" IN ('BarclampCrowbar::AttribDefault') 
AND "attribs"."id" = 47

This is due to NetworkTestHelper.create_node constructing a nested
Hash called nics which looks like this:

  {
"eth0"=>
{"path"=>":00/:00:02.0/:02:01:0", "speeds"=>["100m", "1g"]},
"eth1"=>
{"path"=>":00/:00:04.0/:02:02:0", "speeds"=>["1g", "10g"]}
  }

and then calling

node.set_attrib("nics", nics)

on it.  ActiveRecord then attempts to serialise this as a string so it
can store it in the database, and then the sqlite3 db adapter barfs on
that string.  I'm not sure how this wasn't noticed before; maybe you
guys are testing with MySQL instead?

Regardless, it seems rather odd to be attempting to serialise nested
data structures in database fields, and I don't see any
deserialization code, so I'm guessing this was unintentional?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] barclamp-network unit test failures

[Adam Spiers]

Adam Spiers (aspi...@suse.com) wrote:
> Regardless, it seems rather odd to be attempting to serialise nested
> data structures in database fields, and I don't see any
> deserialization code, so I'm guessing this was unintentional?

Ah no, I see now it was intentional.  But I still don't understand why
noone else sees this.

By the way, within 48 hours or less of network_test_helper.rb being
copied to crowbar_framework to hack around the tests, it already seems
to have diverged.  We should eliminate this hack ASAP.  Presumably
it's just a question of teaching ./dev where to find helpers from
engines?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] barclamp-network unit test failures

[Adam Spiers]

christopher_dearb...@dell.com (christopher_dearb...@dell.com) wrote:
> Hey Adam,
> 
> Just ran the unit tests via "bundle exec rake test:units" and "dev 
> run-unit-tests", and all the unit tests passed in both cases.  Spoke with 
> Andi, and he ran into the same problem over the weekend.  He believes the 
> issue is a difference between the behavior of Marshal in Ruby 1.8 and 1.9, 
> and the solution is not to use it.
> 
> I believe that Rob's recent pull request will fix the issue:  
> https://github.com/crowbar/barclamp-crowbar/pull/432

Ahh, that would totally explain it!  Thanks ;-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] FW: [Still Failing] crowbar/travis-ci-crowbar#25 (master - 0d171b7)

[Adam Spiers]

Chris is right, they are two separate problems (but no longer - thanks
guys for the quick fixes!)

christopher_dearb...@dell.com (christopher_dearb...@dell.com) wrote:
> This pull doesn't address the original problem that the 
> network_test_helper.rb is not being copied into the crowbar_framework/test 
> directory as a result of running dev setup-unit-tests or dev 
> reload-unit-tests, whichever is supposed to do it.  Rob's temporary hack was 
> to just check in a copy of the file into the crowbar/crowbar_framework/test 
> directory.
> 
> 
> -Original Message-
> From: crowbar-bounces On Behalf Of Abes, Andi
> Sent: Monday, March 04, 2013 3:20 PM
> To: Allen, Wayne; crowbar
> Subject: Re: [Crowbar] FW: [Still Failing] crowbar/travis-ci-crowbar#25 
> (master - 0d171b7)
> 
> So, I believe this is fixed in this pull
> https://github.com/crowbar/crowbar/pull/1734
> 
> 
> 
> > -Original Message-
> > From: crowbar-bounces On Behalf Of Allen, Wayne
> > Sent: Monday, March 04, 2013 1:06 PM
> > To: crowbar
> > Subject: [Crowbar] FW: [Still Failing] crowbar/travis-ci-crowbar#25 
> > (master -
> > 0d171b7)
> > 
> > Copying list...
> > 
> > -Original Message-
> > From: Allen, Wayne
> > Sent: Monday, March 04, 2013 12:06 PM
> > To: 'Adam Spiers'
> > Subject: RE: [Crowbar] [Still Failing] crowbar/travis-ci-crowbar#25 
> > (master -
> > 0d171b7)
> > 
> > I haven't looked at it, yet, Adam, working on some other breakage.  At 
> > the moment network is the only bc with these tests defined in the 
> > barclamp itself. The engine conversion generates a skeleton test dir, 
> > with a test_helper, and they will have to be namespaced somehow if 
> > they are going to be copied in. I just  haven't had time to go there, 
> > yet.  Maybe this afternoon?
> > 
> > Wayne
> > 
> > -Original Message-
> > From: crowbar-bounces On Behalf Of Adam Spiers
> > Sent: Monday, March 04, 2013 8:57 AM
> > To: crowbar
> > Subject: Re: [Crowbar] [Still Failing] crowbar/travis-ci-crowbar#25 
> > (master -
> > 0d171b7)
> > 
> > christopher_dearb...@dell.com (christopher_dearb...@dell.com) wrote:
> > > This issue is because “dev setup-unit-tests” doesn’t currently copy 
> > > the network helper class into the dev testing area, which it used to 
> > > do before the network barclamp was converted to a rails engine.
> > > Wayne has a task to fix this in a general way this sprint
> > 
> > Thanks for the info.  Wayne, how is that going to work?  Would be 
> > useful to know for my work on Travis and ./dev.
> > 
> > > but in the interim, Rob has hacked in a temporary fix in this pull:
> > >
> > >   https://github.com/crowbar/barclamp-crowbar/pull/422
> > > which I just reviewed and merged.
> > >
> > > Try another run, and you should get past the network barclamp issues 
> > > now…
> > 
> > Still seeing errors - looking into it now.
> > 
> > ___
> > Crowbar mailing list
> > Crowbar@dell.com
> > https://lists.us.dell.com/mailman/listinfo/crowbar
> > For more information: http://crowbar.github.com/ 
> > ___
> > Crowbar mailing list
> > Crowbar@dell.com
> > https://lists.us.dell.com/mailman/listinfo/crowbar
> > For more information: http://crowbar.github.com/
> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/
> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] barclamp-network unit test failures

[Adam Spiers]

christopher_dearb...@dell.com (christopher_dearb...@dell.com) wrote:
> Hey Adam,
> 
> FYI: I just took an update and diffed the two network_test_helpers:
> 
> crowbar/barclamps/network/crowbar_engine/barclamp_network/test/network_test_helper.rb
> 
> and
> 
> crowbar/barclamps/crowbar/crowbar_framework/test/network_test_helper.rb
> 
> and they are identical.

Nope, they're definitely different AFAICS.  You didn't do 'git diff'
by any chance, did you?  That wouldn't show anything unless you had
local modifications.

Anyway, it sounds like the appropriate ./dev tweak and removal of the
hacked copy is imminent (thanks Wayne :-) so no need to worry.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] ./dev push still used?

[Adam Spiers]

What's the difference between ./dev push and ./dev backup?  And does
anyone still use / need it?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] ./dev push still used?

[Adam Spiers]

Victor Lowther (victor_lowt...@dell.com) wrote:
> ./dev push is mostly unused these days.
> The use case I had in mind for it never really materialized.

Shall we kill it then?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] status update on openSUSE based Crowbar 2 iso

[Adam Spiers]

Ralf Haferkamp (rha...@suse.de) wrote:
> Hi,
> 
> this Mail is to give a brief overview on the status of our openSUSE based 
> builts.

Thanks!  Please can you put this on the wiki and link from

  https://github.com/crowbar/crowbar/wiki/Development

?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Attribute injection

[Adam Spiers]

Judd Maltin (j...@newgoliath.com) wrote:
> Hi Ralf!
> 
> > a)  With pure Chef - via the default attributes in the cookbook, the
> > environments facility of Chef, or roles
> >
> > b)  In Crowbar - crowbar will compute and inject override values for
> > these attributes, at runtime, via chef  API's.
> Just out of curiousity. How will that be done? Will crowbar create roles
> with
> the attributes via the API or directly assigne the attributes to the node
> objects? Or is there another approach?
> 
> > c)   In other deployment systems - in a manner either like a) or b) or
> > telepathically.
>   ^^ I'd like to see the source code for that :)
> 
> FWIW, telepathy will not be necessary.

Phew, I always sucked at that.

> Andi omits in option (a) a very
> common pattern for many Chefs - "data bags."  In fact, data bags are
> generally preferred over roles for attribute injection.  I'd recommend that
> we create an "eventual consistency knob" pattern.  It would allow the user
> to dial in "search," "data_bag," or "Crowbar" as desired.

Makes sense (as much as any of this stuff does to my little brain).

> More coming on my blog soon.. soon.

Cool!  Where's your blog?  BTW I'd vote for having the wiki as the
target for this kind of extremely valuable design info.  Nothing wrong
with blogging to begin with, but I think it's much better if we can
aggregate in the wiki soon after and polish.  Wading through old blog
archives for important info is not fun.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] OpenSUSE build of Crowbar

[Adam Spiers]

john_terps...@dell.com (john_terps...@dell.com) wrote:
> Ralf,
> 
> Thank you for this feedback. I understand that integration of the
> build process into the dev utility is a nice-to-have feature.

I'd say that it's higher priority than that, since until it exists,
noone in Dell except yourself is likely to be testing their changes on
openSUSE - please correct me if I'm wrong.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] OpenSUSE build of Crowbar

[Adam Spiers]

Ralf Haferkamp (rha...@suse.de) wrote:
> Hi,
> 
> CCing the list as this might be of broader interest.
> 
> On Thu, Mar 07, 2013 at 01:07:49PM -0600, john_terps...@dell.com wrote:
> > Ralf,
> > 
> > What parameters do you specify to dev to build crowbar on an OpenSUSE base?
> We are currently not using the dev tool to build the openSUSE ISO. Everything 
> is
> done in the build service. The process for that is detailed here:
> https://en.opensuse.org/OpenStack_and_Crowbar_development_process
> 
> Basically. we have Jenkins job (currently being migrated to ci.opensuse.org)
> that regulary pulling the crowbar github repos, and submitting them to the
> systemsmanagement:crowbar:2.0:staging project here:
> (https://build.opensuse.org/project/monitor?project=systemsmanagement%3Acrowbar%3A2.0%3Astaging)
> 
> In the project there is also the special package "Crowbar_2.0" which contains
> a kiwi configuration (that's the tool we use to create all our 
> distribution/product images
> with: http://en.opensuse.org/Portal:KIWI). The build service is able to use
> that a build a working ISO images for that. You can also build that image
> locally by just checking out the Crowbar_2.0 package using the osc tool and
> running "osc build images" inside the checked out directory.

I have added this info (and more) to

  https://en.opensuse.org/openSUSE:OpenStack_and_Crowbar_development_process

(Note the location change; thanks to Henne who also added a redirect.)

> Just don't do that
> on a 12.3 RCs system currently, because the kernel there seems to have a bug
> that cause the machine to freeze when building images :(
> (https://bugzilla.novell.com/show_bug.cgi?id=805732)

Is this likely to be fixed soon?  If not, I guess we need to document
that too.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Quick connect to admin node

[Adam Spiers]

Andi Abes (andi_a...@dell.com) wrote:
> >From: crowbar-bounces On Behalf Of Judd Maltin
> >Sent: Friday, March 08, 2013 10:46 AM
> >To: Abes, Andi
> >Cc: crowbar
> >Subject: Re: [Crowbar] Quick connect to admin node
> >
> >Never save host keys for the admin box:
> >
> >judd@judd-m6600:~/useful$ cat ~/.ssh/config
> >Host admin 192.168.124.10
> >StrictHostKeyChecking no
> >UserKnownHostsFile=/dev/null
> >
> >write your key to the new admin box:
> >
> >judd@judd-m6600:~/useful$ ssh-copy-id crowbar@admin
> >
> 
> Cool ! didn't use that before...
> But they can be even better together ;)
> 
> sshpass -pcrowbar ssh-copy-id crowbar@admin
> 
> my Admin install per hour number is pretty high (~5) so, it gets pretty 
> repetitive

Nice tricks :-)  I didn't know about sshpass, that's handy but also
pure evil ;-)  Currently there only experimental packages for openSUSE:

  http://software.opensuse.org/package/sshpass

Please can you document these tricks in the devguide?  At risk of
sounding like a broken record, the mailing list is not a good location
for docs ;-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] obsolete config.gem lines

[Adam Spiers]

These are left-overs from Rails 2, right?

https://github.com/crowbar/barclamp-crowbar/blob/master/crowbar_framework/config/application.rb#L65

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Quick connect to admin node

[Adam Spiers]

Andi Abes (andi_a...@dell.com) wrote:
> > Please can you document these tricks in the devguide?  At risk of sounding 
> > like
> > a broken record, the mailing list is not a good location for docs ;-)
> 
> True, and will do. Was looking to fish out additional better tricks - like 
> the one Judd brought up (I didn't know about ssh id copy either... )

Cool, thanks.  Yeah, ssh-copy-id is useful; I have a slightly fancier
equivalent which I should probably upstream:

  https://github.com/aspiers/ssh-config/blob/master/bin/ssh-auth

According to the history I wrote that in 2006, which may have predated
ssh-copy-id :-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] testing and pull requests

[Adam Spiers]

"What testing do we run before submitting?" is a key question; thanks
for bringing it up.  Unfortunately the answer is currently "only
whatever we run manually", since Travis only runs on a merged
repository containing master from each barclamp repository, due to
barclamps currently being unable to run their unit tests standalone.
(There are Trello cards to address this, but it's unlikely to get
fixed soon.)

That means we all need to be as conscientous as possible by running
tests before every pull request, otherwise master is likely to break
often.  I just spoke with James and agree with his proposal to
prototype barclamps as gems which can run their unit tests standalone
(I get the impression engines should help with this but I am not an
expert in the area).  That would allow Travis to run on pull requests
to individual barclamp repos.

However unfortunately we can't prioritise that over the current dev
work, so for the next few weeks at very least I expect we will just
all have to be self-disciplined and not submit pulls for untested code ;-)

- Forwarded message from arkadykanevsky  -

Date: Mon, 11 Mar 2013 10:40:31 -0700
From: arkadykanevsky 
To: crowbar/barclamp-crowbar 
Subject: Re: [barclamp-crowbar] fix BDD tests around node create [1/1] (#455)
Reply-To: crowbar/barclamp-crowbar 


> @@ -72,21 +72,25 @@ def show
>  
># RESTful DELETE of the node resource
>def destroy
> -n = Node.find params
> -unless n.nil?
> -  Jig.all.each {|j| j.delete_node(n)}
> -end
> +n = find_ndoe(params)

What testing do we run before submitting?

From: Victor Lowther [mailto:notificati...@github.com]
Sent: Monday, March 11, 2013 12:39 PM
To: crowbar/barclamp-crowbar
Subject: Re: [barclamp-crowbar] fix BDD tests around node create [1/1] (#455)


In crowbar_framework/app/controllers/nodes_controller.rb:

> @@ -72,21 +72,25 @@ def show

>

># RESTful DELETE of the node resource

>def destroy

> -n = Node.find params

> -unless n.nil?

> -  Jig.all.each {|j| j.delete_node(n)}

> -end

> +n = find_ndoe(params)

I am referring to the name of the function, not what it does (which was obvious 
at a glance) -- you have it spelled as find_ndoe instead of find_node.

—
Reply to this email directly or view it on 
GitHub.


---
Reply to this email directly or view it on GitHub:
https://github.com/crowbar/barclamp-crowbar/pull/455/files#r3321508

- End forwarded message -

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] how to debug Travis failures

[Adam Spiers]

christopher_dearb...@dell.com (christopher_dearb...@dell.com) wrote:
> I submitted a pull request that should resolve most of these issues 
> (https://github.com/crowbar/barclamp-network/pull/158).  That pull was merged 
> on Friday, but does not appear to be in this build.
> 
> Could whoever is managing the Travis builds take a look?

I realise that this is probably going to make me sound very lazy /
selfish / difficult to work with etc. ;-)  So apologies in advance, but ...

I'm really keen that I (or James, or anyone else) don't become the
bottleneck on Travis builds.  I really think it needs to be a
team-wide responsibility, e.g. if anyone sees test failures and thinks
they may have caused them, that they take the lead in resolving them.
That's especially true right now based on the other mail I just sent
to the list, since we're in a situation where pull requests are not
automatically tested prior to merge, and consequently trunk is at much
higher risk than it should be.

To this end, I have already spent quite a bit of effort trying to
ensure that the whole testing setup is properly documented in a way
that everyone can understand, e.g.

https://github.com/crowbar/crowbar/blob/master/doc/devguide/testing/travis.md
https://github.com/crowbar/crowbar/blob/master/doc/devguide/testing.md

That said, I do admit that it is currently missing a "how to
troubleshoot Travis test failures" section, and that is a sore
omission - thanks for helping me realise that!  However I have no time
to write this since I have to start preparing the rspec talk for
tomorrow, and anyway, I think I've done far more than my fair share of
documentation work recently ;-)  So can I suggest that someone else
take ownership of writing this, and use it as a good exercise in
learning about the Travis builds in the process?  Shouldn't be a big
job, and of course I'm happy to answer any questions which may arise.

Thanks!

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] how to debug Travis failures

[Adam Spiers]

Adam Spiers (aspi...@suse.com) wrote:
> I'm really keen that I (or James, or anyone else) don't become the
> bottleneck on Travis builds.  I really think it needs to be a
> team-wide responsibility, e.g. if anyone sees test failures and thinks
> they may have caused them, that they take the lead in resolving them.
> That's especially true right now based on the other mail I just sent
> to the list, since we're in a situation where pull requests are not
> automatically tested prior to merge, and consequently trunk is at much
> higher risk than it should be.
> 
> To this end, I have already spent quite a bit of effort trying to
> ensure that the whole testing setup is properly documented in a way
> that everyone can understand, e.g.
> 
> https://github.com/crowbar/crowbar/blob/master/doc/devguide/testing/travis.md
> https://github.com/crowbar/crowbar/blob/master/doc/devguide/testing.md
> 
> That said, I do admit that it is currently missing a "how to
> troubleshoot Travis test failures" section, and that is a sore
> omission - thanks for helping me realise that!  However I have no time
> to write this since I have to start preparing the rspec talk for
> tomorrow, and anyway, I think I've done far more than my fair share of
> documentation work recently ;-)  So can I suggest that someone else
> take ownership of writing this, and use it as a good exercise in
> learning about the Travis builds in the process?  Shouldn't be a big
> job, and of course I'm happy to answer any questions which may arise.

Oh well, for some reason I ended up doing this myself %-)

https://github.com/crowbar/crowbar/pull/1747

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] removing non-engine files?

[Adam Spiers]

cdearborn (notificati...@github.com) wrote:
> Yes (I can't wait!).  This helper should only be in the network
> barclamp.  Rob checked a copy of it into the crowbar barclamp as a
> stop-gap to make the unit tests run.  Wayne is working on updating
> dev setup-unit-tests or barclamp_install or whatever to correctly
> copy any test helpers that are defined in the engines to the correct
> dev test location.  Once he finishes that work, we can delete this
> helper from the crowbar barclamp.

Great.  Talking of duplicated code, it seems that

  crowbar_engine/barclamp_$BC/

is a modified and restructured copy of

  crowbar_framework/

for some or all of the barclamp engines.  Whilst I know we still need
to keep one or two of the old files in the very short term, such as
the network helper referenced above, can't we already remove most of
the non-engine files?  Having a whole load of duplicated code hanging
around risks someone reading or changing the wrong version by mistake,
or worse, the old code actually being used somewhere ... sorry for
being annoying or if I misunderstood something, but I'm even more
religious about DRY than I am about emacs ;-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] testing and pull requests

[Adam Spiers]

Andi Abes (andi_a...@dell.com) wrote:
> > -Original Message-
> > From: crowbar-bounces On Behalf Of Adam Spiers
> > Sent: Monday, March 11, 2013 2:24 PM
> > To: crowbar
> > Subject: [Crowbar] testing and pull requests
> > 
> > "What testing do we run before submitting?" is a key question; thanks for
> > bringing it up.  Unfortunately the answer is currently "only whatever we run
> > manually", since Travis only runs on a merged repository containing master
> > from each barclamp repository, due to barclamps currently being unable to 
> > run
> > their unit tests standalone.
> > (There are Trello cards to address this, but it's unlikely to get fixed 
> > soon.)
> 
> The general pattern we've been following is to have barclamps extend 
> framework provided classes, and that code currently resides in 
> crowbar/crowbar_framework... so to get to a point where we can run unit tests 
> for standalone barclamps will require copying in the framework (chicken, 
> meet egg...).

Hmm ... hopefully there is an industry-wide best practice for reusing
shared code between engines which we can follow?

> > That means we all need to be as conscientous as possible by running tests
> > before every pull request, otherwise master is likely to break often.  I 
> > just spoke
> > with James and agree with his proposal to prototype barclamps as gems which
> > can run their unit tests standalone (I get the impression engines should 
> > help
> > with this but I am not an expert in the area).  That would allow Travis to 
> > run on
> > pull requests to individual barclamp repos.
> 
> A possible short term approach that would give us testing prior to
> pull requests being merged would be to reflect Pull requests from
> the different repo, into the travis repo.

Right, I created https://trello.com/c/6qn6cd0z for this a few weeks ago.
Sorry if I didn't publicise this enough at the time.

> How is this different from what's happening now?
> Now, the update-git script checks for changed files between the travis repo 
> (as checked-out locally on the server running the script) and the main 
> crowbar repo. If it finds differences, it pushes an update to the 
> travis-ci-crowbar repo.
> This process will only catch all the merged pull requests.
> 
> The approach I proposing works differently:
> On a periodic basis, pull the crowbar repos (crowbar and each barclamp) for 
> pending pull requests. For each open pull request, create a pull request 
> against the travis-ci-crowbar repo. This in turn will trigger travis to test 
> the pull request, before it is actually merged.

No, I think we want to stick with handling bundles in a single pass,
so that each Travis pull request corresponds to a bundle, or to a
singleton if there is no bundle.

> There are a few complications that need to be handled (but I believe a 
> solution exists for both):
> a) Bundles - often there are sets of pull requests against different 
> barclamps (or framework + barclamp) that will only pass tests if 
>  they're evaluated as a 'bundle' (i.e. both sets of changes are required). 

I already outlined a solution for this in the Trello card and in fact
even took the first steps towards implementing.  One approach is to
iterate over the ids provided by "./dev ci open-ids" and ensure that
for each, a branch called (say) pull-req/$ID exists.  If not, create
it via "./dev pull-requests switch" followed by the normal rsync.
Then use something like "hub" to issue the pull request to the Travis
repo.  I have already forked the repo to the Travis commit-bot's
account to allow this.

The other approach is to merge into a non-flat tree using git subtree,
and perform the tree merging at test-time by telling Travis to do the
"./dev tests setup" bit.  This has the advantage of preserving commit
history, authorship etc.

See also https://trello.com/c/tqCDVLgH

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] [barclamp-crowbar] add a rake task to run the travis tests in one go, so we can more easily... (#464)

[Adam Spiers]

aabes (notificati...@github.com) wrote:
> You can merge this Pull Request by running:
> 
>   git pull https://github.com/aabes/barclamp-crowbar rake-travis
> 
> Or you can view, comment on it, or merge it online at:
> 
>   https://github.com/crowbar/barclamp-crowbar/pull/464
> 
> -- Commit Summary --
> 
>   * add a rake task to run the travis tests in one go, so we can more easily 
> do that locally
> 
> -- File Changes --
> 
> M crowbar_framework/Rakefile (5)
> 
> -- Patch Links --
> 
> https://github.com/crowbar/barclamp-crowbar/pull/464.patch
> https://github.com/crowbar/barclamp-crowbar/pull/464.diff

Posthumous +1 for the great idea!  However there is a caveat that
`db:drop` with `RAILS_ENV=development` will drop not only
`development.sqlite3` but also `test.sqlite3`.  That means that
running "rake travis" with the development environment (the default)
will break your test environment.  I very recently tweaked ./dev's
reload_test_env() to cater for this but I'm not sure what the best
approach here is.  Having said that, the test environment is in a
dedicated tree in /tmp so maybe it doesn't matter too much?  Ideas:

- exclude `db:drop` from this new task
- override db:drop with something which only drops the current
  environment's db
- issue some kind of warning / ask for confirmation if interactive
- do nothing and try to be aware of this corner case

I believe there are only 3 use cases for this task:

1) Called by Travis via .travis.yml
2) Called by dev's reload_test_env()
3) Called manually from the CLI

This new task lets us eliminate small amount of duplication between
.travis.yml and ./dev, which is cool.

Any other use cases?  FWIW 1) is always non-interactive, 2) is
typically interactive but could be non-interactive, and 3) is almost
always interactive.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] removing non-engine files?

[Adam Spiers]

Andi Abes (andi_a...@dell.com) wrote:
> I think we're talking about a few days, not as an ongoing
> pattern. Surely we're living with much bigger warts than this
> one...;)

Sorry, but TBH I haven't seen much bigger warts in this project ;-) 

In my experience the "negative break-even point" for duplicated code
and docs (i.e. the point at which the disadvantages start outweighing
the benefits) is typically hours or days, not weeks, especially when
there are a lot of people working on the project and several of them
(e.g. me) aren't close enough to the core code to confidently
distinguish between new code and retired old code.

One of the major points of using revision control is to eliminate the
need to keep unnecessary code/docs hanging around.  It's incredibly
simple to use git to examine the old code, e.g.

$ git tag duplicated

[... remove duplicates, commit, send pull request ...]

$ git show duplicated:crowbar_framework/app/models/network.rb
or
$ git checkout duplicates
or
$ gitk duplicates  # and then click on the "Tree" radio button

so I really can't see a good reason to keep it (except of course for
where stuff would still break without it due to the engines migration
not being finished yet).

IIRC the Pragmatic Programmers wrote something like this in their
famous first book:

 Don't Repeat Yourself!

 This rule is so important that it's worth breaking to show how
 important it is.

 Don't Repeat Yourself!

;-)

> From: crowbar-bounces On Behalf Of Darrel O'Pry
> Sent: Wednesday, March 13, 2013 3:32 PM
> To: James Tan
> Cc: crowbar; Allen, Wayne
> Subject: Re: [Crowbar] removing non-engine files?
> 
> 
> I have to second James here. I just came off a project where they insisted on 
> keeping historic stuff in the repo. It only served to confuse people coming 
> onboard who weren't already familiar with the project.  Its really easy to 
> make a branch in you own repository and switch back to it or view it on 
> github if you need it for reference.
> On Mar 13, 2013 2:04 PM, "James Tan" mailto:ja...@suse.de>> 
> wrote:
> On 03/13/2013 04:54 PM, wayne_al...@dell.com 
> wrote:
> > I would like to keep the old versions around for quick reference and delete 
> > them as each barclamp is fully integrated into the new system.
> 
> While I understand the convenience of keeping these files around during
> integration, it's really confusing for everyone else. Can you remove
> them and refer via the git history instead?
> 
> Thanks,
> James T.
> 
> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/

> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] gemcanary

[Adam Spiers]

Andi's comment on IRC about gemnasium reminded me of this:

https://gemcanary.com

but unfortunately only works when Gemfile is at the top-level of the
repository.  I sent them a feature request :-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] testing and pull requests

[Adam Spiers]

James Tan (ja...@suse.de) wrote:
> On 03/13/2013 11:32 AM, Adam Spiers wrote:
> >>>"What testing do we run before submitting?" is a key question; thanks for
> >>>> >bringing it up.  Unfortunately the answer is currently "only whatever 
> >>>> >we run
> >>>> >manually", since Travis only runs on a merged repository containing 
> >>>> >master
> >>>> >from each barclamp repository, due to barclamps currently being unable 
> >>>> >to run
> >>>> >their unit tests standalone.
> >>>> >(There are Trello cards to address this, but it's unlikely to get fixed 
> >>>> >soon.)
> >>>
> >>>The general pattern we've been following is to have barclamps extend 
> >>>framework provided classes, and that code currently resides in 
> >>>crowbar/crowbar_framework... so to get to a point where we can run unit 
> >>>tests for standalone barclamps will require copying in the framework 
> >>>(chicken, meet egg...).
> 
> The root of all evil here is really the tight coupling we have
> between the Crowbar framework itself and the barclamps. We really
> need to focus on decoupling them so that can be standalone.

Well, I still don't see how it's possible to decouple them 100%:

> >Hmm ... hopefully there is an industry-wide best practice for reusing
> >shared code between engines which we can follow?
> 
> A gem? :-)

Sure, but each barclamp model will still inherit from the Barclamp
base class, for instance, so there is still coupling.  I don't think
that's a bad thing - it's just a dependency.  The thing we really need
to eliminate is the need to copy files around.  We should be able to
take a similar approach to Rails gems for this - when you install a
Rails gem, you don't need to manually copy all its models,
controllers, views, helpers, assets etc. into your own tree :-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] [Still Failing] crowbar/travis-ci-crowbar#60 (master - ac51708)

[Adam Spiers]

Hi Chris,

christopher_dearb...@dell.com (christopher_dearb...@dell.com) wrote:
> I took a look at this issue, and the problem is that translation is not 
> working properly in the Travis test setup.
> 
> A new migration was added that creates the default network barclamp 
> deployment.  In that migration, I initially used 
> Barclamp::DEFAULT_DEPLOYMENT_NAME for the name of the deployment.  I later 
> used the same constant to look up the default deployment.  This failed in the 
> dev test environment because the I18n.t call was failing during the database 
> migration and defaulting to "default", while it was succeeding in the I18n.t 
> call while the unit tests were running, which caused it to try to look up a 
> deployment with the name "Default".  This caused the lookup to fail, and 
> resulted in errors in the dev test environment that were identical to those 
> seen in Travis.  To work around this problem (I think translation failing 
> during DB migration is probably understandable - correct me if you think 
> otherwise), I hard coded the Deployment name to "Default" in the DB 
> migration, and everything worked.
> 
> What we are seeing in the Travis errors are exactly the opposite problem.  
> The network barclamp default deployment name is hard coded to "Default" in 
> the DB migration.  When the Barclamp::DEFAULT_DEPLOYMENT_NAME constant is 
> used while the unit tests are running, the I18n.t translation is failing and 
> defaulting the name to "default".  As a result, the deployment lookup by name 
> fails which causes the unit tests to fail.

Thanks again for spending time on this!

> At any rate, I can easily fix this by not using I18n.t() to get/set the name 
> of the deployment, which is probably fine in this instance since the network 
> barclamp can have only one deployment, and its name will most likely not be 
> shown in the GUI as a result.  But, I think we have a bigger issue here in 
> that translation is not working when running unit tests on Travis.  
> Unfortunately, I know very little about Travis or how translation is set up.

I can't help with translation but don't hesitate to fire any Travis
questions my way.  However hopefully it should be very simple to
understand because Travis isn't really doing anything significantly
different from "./dev tests run".  There's just a small amount of
trickery to assemble all the code from the various repositories into a
single unified tree which has the same structure as
/tmp/crowbar-dev-test/opt/dell/crowbar_framework/

Details here in case you didn't see yet:

https://github.com/crowbar/crowbar/blob/master/doc/devguide/testing/travis.md

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] BDD Training

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> All,
> 
> I recorded a 90 minute BDD training session last week: 
> http://www.youtube.com/watch?v=DBtHheWt04c&list=UU0CVIIVkyPTlTUWIZl21D9A&index=1
> 
> As Adam pointed out on the call this morning, we really need people listening 
> to the training to help convert this to written docs!
> 
> The docs for BDD are under:
> https://github.com/crowbar/barclamp-crowbar/tree/master/doc/devguide/testing
> 
> It would also be great to have people create a time annotated notes for the 
> video(s) on the wiki.

Thanks.  Does this session cover the simulator?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] BDD Training

[Adam Spiers]

Judd Maltin (j...@newgoliath.com) wrote:
> https://github.com/crowbar/crowbar/wiki/Videos
> 
> I dumped a bunch of Rob's videos here.  The list needs curating.  But it's
> really lots of great stuff.

Thanks.  However this overlaps to some extent with

  https://github.com/crowbar/crowbar/wiki/Meetings

so we need a way of reconciling the two which doesn't confuse newbies.
I'm also concerned about the risk of propagating outdated information;
videos are useful short-term tools, but are not maintainable and so do
not have the longevity of proper documentation.  Some of these videos
are really old.

Any thoughts on how to address?  I'm thinking it would probably make
sense to firstly group videos by subject area and then sort reverse
chronologically within each list, so that older videos which are more
likely to be out of date occupy a less prominent position in the list.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] BDD Training

[Adam Spiers]

Adam Spiers (aspi...@suse.com) wrote:
> Judd Maltin (j...@newgoliath.com) wrote:
> > https://github.com/crowbar/crowbar/wiki/Videos
> > 
> > I dumped a bunch of Rob's videos here.  The list needs curating.  But it's
> > really lots of great stuff.
> 
> Thanks.  However this overlaps to some extent with
> 
>   https://github.com/crowbar/crowbar/wiki/Meetings
> 
> so we need a way of reconciling the two which doesn't confuse newbies.
> I'm also concerned about the risk of propagating outdated information;
> videos are useful short-term tools, but are not maintainable and so do
> not have the longevity of proper documentation.  Some of these videos
> are really old.
> 
> Any thoughts on how to address?  I'm thinking it would probably make
> sense to firstly group videos by subject area and then sort reverse
> chronologically within each list, so that older videos which are more
> likely to be out of date occupy a less prominent position in the list.

I started to clean up the structure of this wiki page, but I got stuck
with the lower half of the Markdown because I couldn't understand what
the intended section structure should be.  My goal was to convert each
talk into a bulleted list item, since having each talk as its own 
or  section resulted in the page being way too long, rendering it
impossible to visually parse the section structure.  Judd, please can
you help with this?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] documentation and website (was Re: BDD Training)

[Adam Spiers]

Judd Maltin (j...@newgoliath.com) wrote:
> Thanks for putting an eye to this, guys.
> 
> The top of the page, with my h1 and h2, are my new additions.  The bolds
> are Robs originals towards the bottom.

Ah, I see.

> Deeper curation is definitely required.  This was a first pass at enriching
> and updating.  I wish the github wiki would allow html embedding.

It does allow embedding of some HTML -  at least ...

> Youtube has nice rich tagging, etc.  Plus, there no TOC features, except the
> sidebar plugin.

The lack of ToC is tracked here:

  https://github.com/gollum/gollum/issues/380

and it looks like someone might implement it soon due to a sudden
burst of energy:

  https://github.com/gollum/gollum/issues/648

However there are other solutions, e.g. this looks pretty nice:

  https://github.com/hybridgroup/GitHub-Wikifier

> I think it would take a few hours to get it just right.

Maybe, but it would only take 20 mins to make some vast improvements.
"If a thing is worth doing, it is worth doing badly." ;-)

> Time I'm not assigned.

I understand that right now we're all feeling the heat at the moment
due to the aggressive release schedule - and please take the following
remarks as general observations on the project rather than any kind of
comment on your own great work! - but I believe it's a false economy
to deprioritise documentation tasks even when under pressure to
accomplish other goals.

As well as the immediate benefits which good documentation brings to
existing contributors (where the break-even point always happens
earlier than I expect), there is a potentially huge but currently
untapped community out there who could help us move a *lot* faster.
But one of the big reasons that Crowbar has not seen widespread
community adoption yet is that we still don't have friendly
documentation (although we got a *lot* closer in the last few months).
Look at:

http://crowbar.github.com/

and now compare it with:

https://juju.ubuntu.com/

The difference is *so* enormous that if someone is looking for a
solution in this space, currently they are almost guaranteed to pick
Juju regardless of any technical considerations, simply because the
Juju website portrays Juju as an incredibly active, healthy, credible,
friendly project with significant momentum, with backing from a strong
community.  In contrast, our website is more like what you'd expect to
see from a project run by a small bunch of hackers in their spare
time, and I wouldn't expect most newcomers to delve deeply enough to
realise that's far from the reality.

In November I submitted a Trello card to address the public website:

https://trello.com/c/dBW9dlVu

but despite it being on the current sprint board ever since, AFAICS
there's been zero progress so far.  Didn't we have someone assigned to
work on this?

So in summary, I believe we are vastly under-estimating the importance
of having a decent documentation, or at least under-prioritising it.
Sorry for the rant, but I think we really need to address this now if
we want "market" Crowbar and attract new contributors at imminent
events such as the Havana summit.

If you made it this far, thanks for listening, and sorry for raising
an uncomfortable issue ;-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] RESTful Crowbar API

[Adam Spiers]

Andreas Jaeger (a...@suse.com) wrote:
> Btw. to render a markdown file locally, install redcarpet as root with 
> e.g. (or install the openSUSE rpm from the build service):
> gem install redcarpet

Yep, there are several gems which can do this.  Others include:

  - BlueCloth
  - maruku
  - kramdown
  - BlueFeather

> and then just run redcarpet file.md > file.html

or write a Makefile, e.g.

%.html: %.md
@redcarpet $< > $@

and then run `make file.html'.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] RESTful Crowbar API

[Adam Spiers]

James Tan (ja...@suse.de) wrote:
> On 03/16/2013 09:23 PM, Ward Harold wrote:
> >James, thanks for the note on your workflow. I'd like to stick
> >with the ./dev mechanism as much as possible.
> 
> You're welcomed, and sure whatever works best for you. :-)

Indeed, although I would personally recommend avoiding ./dev for
creating feature branches until this issue is resolved:

  https://github.com/crowbar/crowbar/issues/1708

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] RESTful Crowbar API

[Adam Spiers]

James Tan (ja...@suse.de) wrote:
> Hi Ward,
> 
> (CC-ing the list, as it might be useful to others too. Hope you don't mind!)

This is great James, thanks a lot for writing it up.  Glad to see that
your workflow is nearly identical to mine :-)

[snipped]

> 6) Done with the rebase, I now force push the changes back to my fork:
> 
> > git push -f personal
> 
> WARNING: Be very careful when doing a forced push, and NEVER force push
> to main branches in the Crowbar repos (eg. master branch in all
> github.com/crowbar/xxx repos).

I'd say never force push to *any* branches in the github.com/crowbar
repos, let alone the main branches.

> 7) I double check my changes on the Github web UI, and then submit a pull
> request from there. Make changes and rebase again if necessary.

8) If necessary, update your existing pull request(s) via

$ git push -f personal

As previously mentioned on this list, github handles this nicely, and
it keeps the audit trail for any given issue in a single place.

> Hope this helps! I'll move this to the devguide after collecting comments
> and feedback here.

That would be great, thanks!  I submitted a Trello card for this:

https://trello.com/c/3MPzzpgr

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] RFC: Add RailsConfig gem to manage application settings

[Adam Spiers]

James Tan (ja...@suse.de) wrote:
> Hi everyone,
> 
> I've recently submitted the following pull request:
> 
>https://github.com/crowbar/barclamp-crowbar/pull/483
> 
> Victor suggested that we discuss this change here as it involves adding 
> a new dependency.
> 
> Thoughts/comments?

Didn't know about that gem but it looks like a nice idea to me.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] new ownership Trello board

[Adam Spiers]

Hi all,

Last week in Portland, we agreed to create a new Trello board to track
ownership of the various components of the Crowbar project.
Explicitly declaring ownership clarifies responsibilities, makes it
easier for people to find assistance from the right person, and
highlights any potential blind spots the project may currently have.
For example, who is responsible for triaging bugs in barclamp-nova?
Until now that has been a somewhat open question.

Here is the board:

https://trello.com/board/crowbar-ownership/51707e870c84c6fe29001af0

Please join any card which you think you should take ownership of, and
feel free to add/amend cards too.  If there are multiple owners per
card, then one person should be marked as the primary owner by
updating the card's description field.

Thanks!
Adam

Andreas Jaeger wrote:
> Hi Adam,
> 
> what's the purpose of this board? I'm missing some context here...
> 
> Thanks,
> Andreas
> 
> On Fri, Apr 19, 2013 at 3:00 AM, Trello  wrote:
> 
> >Notifications
> > --
> > On Crowbar 
> > ownership<https://trello.com/board/crowbar-ownership/51707e870c84c6fe29001af0>
> > *Adam Spiers* added you to the board Crowbar ownership
> > <https://trello.com/board/crowbar-ownership/51707e870c84c6fe29001af0>
> >
> > Change how often you get email on your account 
> > page<https://trello.com/my/account>
> >
> > Follow Trello on 
> > Twitter<https://twitter.com/intent/follow?user_id=360831528>,
> > Facebook <https://www.facebook.com/TrelloApp>, and 
> > Google+<https://plus.google.com/103127084407107005900/posts>
> >
> > Get the Trello app for iPhone or iPad <http://itunes.com/apps/trello>,
> > Android <https://play.google.com/store/apps/details?id=com.trello>, or 
> > Windows
> > 8<http://apps.microsoft.com/windows/en-us/app/trello/bd4fa6c1-0994-4caa-b0e1-04eec135667b>

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Is there a "What is Working" vs "What is broken" for Pebbles?

[Adam Spiers]

James Tan (ja...@suse.de) wrote:
> Hi Arkady,
> 
> On 04/22/2013 03:47 PM, arkady_kanev...@dell.com wrote:
> > CB2.0 is in early stages.
> > I am working on the list.
> > The first main item is attribute injection.
> 
> Thanks for the reply. Yes I know Crowbar 2.0 is still under development 
> as I'm involved in that as well. It's just unclear what's supposed to be 
> working and what not, so other non-Dell Crowbarians can figure out which 
> areas to focus on or contribute to.

+1.  Maybe an etherpad serving as a whiteboard status would help?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] compare-crowbar-upstream.sh update

[Adam Spiers]

[This is probably only interesting to SUSE folks, but I'm posting it
on the Crowbar list to alert everyone to the fact that we'll probably
be pushing git-notes(1) refs to the crowbar github repos in order to
collaborate on upstreaming blacklists ...]

  
https://github.com/SUSE-Cloud/automation/blob/master/scripts/compare-crowbar-upstream.sh

is now ready for convenient reporting of how far Crowbar branches have
diverged.  By default it compares essex-hack-suse with pebbles.  It
needs my git-icing hack:

  https://github.com/aspiers/git-config/blob/master/bin/git-icing

Just download and place that somewhere on your $PATH first.  

Here's some sample output:

Comparing crowbar barclamp: release/essex-hack-suse/master with 
crowbar/release/pebbles/master ...
+ 2949781c761dbf5b3ce42ef10138f4c78f33424d Add new attribute "group"
+ 7aa2b41188ca6d26c9be0a2f82cf7a440e6289de Bring apache cookbook into a 
shape that allow openstack deployment on SUSE
+ 951b345d87b7a0673ecd2234f80a5388aaad754c Fix re-adding a role to a node.
+ 96eeeda0862c0a3b6dea3c6adb5271789103b993 Add SUSE specific mappings for 
the apache2 service
+ 0c79b7ff7f34f774ed2cf1fa48749d641445227e Fixed typo
+ 58288c2755cebe125182abe59d8fb4e2ac0d6bc6 Install rabbitmq package before 
touching any of its files

[snipped]

Comparing tempest barclamp: release/essex-hack-suse/master with 
crowbar/release/pebbles/master ...
release/essex-hack-suse/master does not exist in tempest barclamp

Comparing test barclamp: release/essex-hack-suse/master with 
crowbar/release/pebbles/master ...
+ 361fa8d0d0b453c5e1ded1592f94d8d7b7b83032 Add crowbar-status and 
crowbar-failed in schema

Comparing ubuntu-install barclamp: release/essex-hack-suse/master with 
crowbar/release/pebbles/master ...
crowbar/release/pebbles/master does not exist in ubuntu-install barclamp

Comparing zookeeper barclamp: release/essex-hack-suse/master with 
crowbar/release/pebbles/master ...

Total patches to upstream
-

99  crowbar barclamp
93  nova barclamp
86  provisioner barclamp
39  glance barclamp
36  nova_dashboard barclamp
32  keystone barclamp
31  swift barclamp
16  network barclamp
 8  nagios barclamp
 8  dns barclamp
 7  deployer barclamp
 3  ntp barclamp
 3  mysql barclamp
 3  logging barclamp
 3  ipmi barclamp
 1  test barclamp
 1  ganglia barclamp

You can also see from the git-icing comments that blacklisting of
commits which should never be upstreamed is now supported, e.g.

  git notes --ref=upstreaming add -m'skip: all' $sha

Sharing git notes across repositories isn't the most convenient thing
in the world, but it shouldn't be hard.  I think we can push notes
via:

  git push crowbar 'refs/notes/*:refs/notes/*'

and then pull / merge via:

  http://vmiklos.hu/blog/git-notes-merge.html

but I'm still trying to wrap my head around that bit.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] compare-crowbar-upstream.sh update

[Adam Spiers]

Adam Spiers (aspi...@suse.com) wrote:
> You can also see from the git-icing comments that blacklisting of
> commits which should never be upstreamed is now supported, e.g.
> 
>   git notes --ref=upstreaming add -m'skip: all' $sha
> 
> Sharing git notes across repositories isn't the most convenient thing
> in the world, but it shouldn't be hard.  I think we can push notes
> via:
> 
>   git push crowbar 'refs/notes/*:refs/notes/*'
> 
> and then pull / merge via:
> 
>   http://vmiklos.hu/blog/git-notes-merge.html
> 
> but I'm still trying to wrap my head around that bit.

I figured it out and documented it here:

http://stackoverflow.com/questions/12055303/merging-git-notes-when-there-are-merge-conflicts-in-them/

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] compare-crowbar-upstream.sh update

[Adam Spiers]

[reminder: this thread is still probably mostly interesting only to
 SUSE folk, although the described toolchain could be applied to
 any upstreaming work on any project which uses git]

Adam Spiers (aspi...@suse.com) wrote:
> Adam Spiers (aspi...@suse.com) wrote:
> > You can also see from the git-icing comments that blacklisting of
> > commits which should never be upstreamed is now supported, e.g.
> > 
> >   git notes --ref=upstreaming add -m'skip: all' $sha
> > 
> > Sharing git notes across repositories isn't the most convenient thing
> > in the world, but it shouldn't be hard.  I think we can push notes
> > via:
> > 
> >   git push crowbar 'refs/notes/*:refs/notes/*'
> > 
> > and then pull / merge via:
> > 
> >   http://vmiklos.hu/blog/git-notes-merge.html
> > 
> > but I'm still trying to wrap my head around that bit.
> 
> I figured it out and documented it here:
> 
> http://stackoverflow.com/questions/12055303/merging-git-notes-when-there-are-merge-conflicts-in-them/

I've just been through this with Ralf and it turns out there are quite
a few gotchas to bear in mind.  So we wrote a wrapper to make it easy
for everyone to collaborate on upstreaming blacklists:

https://github.com/aspiers/git-config/blob/master/bin/git-rnotes

Download the raw version to somewhere on your $PATH and chmod +x.

We decided to store the notes in the https://github.com/SUSE-Cloud
repositories, since the commit objects for essex-hack-suse are not
present in https://github.com/crowbar.  So if your local Crowbar tree
doesn't yet have this remote, you should first add it:

./dev remote add suse https://github.com/SUSE-Cloud

Firstly you need to tell git notes to use the 'upstreaming' refs
namespace:

export GIT_NOTES_REF=refs/notes/upstreaming

or

git config [--global] core.notesRef refs/notes/upstreaming

according to your personal tastes.

The first time you want to blacklist commits in a repository, you
should first fetch the existing blacklist:

git rnotes fetch suse

Then you can add new commits to the blacklist, e.g.:

git notes add -m"skip: all

<<< insert explanation for why we don't want to upstream
this commit here >>>" $sha

[N.B. Occasionally you have to blacklist a commit even after you've
upstreamed it, because the process of cherry-picking a commit into the
upstream branch results in a different git patch-id due to changes in
the unified diff context.  If you cherry-pick a change and it doesn't
go grey in the output from "git icing" or compare-crowbar-upstream.sh,
you can see why via:

diff -u <(git show $sha1) <(git show)
]


Now push the updated blacklist back to SUSE-Cloud:

git rnotes push suse

During future work, you can also do

git rnotes pull suse

which is equivalent to

git rnotes fetch suse &&
git rnotes merge suse

Here's another useful trick for seeing the history of a given
blacklist entry:

git log -p notes/[suse/]upstreaming -- `git rev-parse $sha1`

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] sprint 5/92013

[Adam Spiers]

James Tan (ja...@suse.de) wrote:
> Hi Arkady,
> 
> Thanks for sending the details. Unfortunately it's a public holiday
> in Germany today, so I (and probably Ralf) won't join the Crowbar
> community call later today. Not sure about Adam (in UK) though.

I'll join.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] [barclamp-provisioner] installation of gems in sledgehammer

[Adam Spiers]

Hi all,

Whilst upstreaming our provisioner changes to Pebbles, I noticed that
we have a couple of commits which change run-time installation of gems
in Sledgehammer to build-time installation:

https://github.com/crowbar/barclamp-provisioner/commit/756e8f9a3
https://github.com/crowbar/barclamp-provisioner/commit/a232a69de

Is there any reason why they should not be included at build-time
rather than run-time?  It would be good to converge on this if
possible.

- Forwarded message from "J. Daniel Schmidt"  
-

Date: Thu, 16 May 2013 06:23:52 -0700
From: "J. Daniel Schmidt" 
To: crowbar/barclamp-provisioner 
Cc: Adam Spiers 
Subject: Re: [barclamp-provisioner] adaptions to allow the script also for SUSE 
based images
(756e8f9)
Reply-To: crowbar/barclamp-provisioner



This was done to allow the script to run in the SUSE sleshammer image. This 
image is very stripped down and no gem installs are possible at runtime - all 
needed gems have to be added to the image itself.
There was some other magic in the original sledghammer image that put some gem 
files to /root and this script was meant to install them. With this patch we 
disabled the behaviour for suse but kept it for other distributions resp. 
sles/slege-hammer images.

So if this feature is still present, we should definitely port this patch - or 
a similar functionality to disable gem installs.

---
Reply to this email directly or view it on GitHub:
https://github.com/crowbar/barclamp-provisioner/commit/756e8f9a3289b9b264513fadb010ed004a9ca1ea#commitcomment-3226553

- End forwarded message -

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] How Openstack Networking works in Pebbles

[Adam Spiers]

Victor Lowther (victor.lowt...@gmail.com) wrote:
> Here is an incomplete doc that describes how we configure network
> interfaces to let the Openstack component formerly known as Quantum do its
> thing:
> https://github.com/crowbar/crowbar/wiki/Openstack-Networking-in-Pebbles
> 
> It is not complete yet, as I have not fooled around enough with tenant VLAN
> support to be able to fill it out.
> 
> Feedback and edits welcome!

Thanks a lot Victor, this looks really useful and will be even more so
when the gaps are filled in!  Hopefully we can contribute feedback and
edits soon.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] [barclamp-provisioner] installation of gems in sledgehammer

[Adam Spiers]

Isn't it slower?  And seems like unnecessary moving parts, so more
chance of something going wrong than bundling them in the image.
But maybe I'm missing something.

Victor Lowther (victor_lowt...@dell.com) wrote:
> What is wrong with installing the packages at run-time?
> 
> > -Original Message-
> > From: crowbar-bounces On Behalf Of Adam Spiers
> > Sent: Monday, May 20, 2013 6:43 AM
> > To: crowbar
> > Subject: Re: [Crowbar] [barclamp-provisioner] installation of gems in
> > sledgehammer
> > 
> > Hi all,
> > 
> > Whilst upstreaming our provisioner changes to Pebbles, I noticed that we 
> > have a
> > couple of commits which change run-time installation of gems in Sledgehammer
> > to build-time installation:
> > 
> > https://github.com/crowbar/barclamp-provisioner/commit/756e8f9a3
> > https://github.com/crowbar/barclamp-provisioner/commit/a232a69de
> > 
> > Is there any reason why they should not be included at build-time rather 
> > than
> > run-time?  It would be good to converge on this if possible.
> > 
> > - Forwarded message from "J. Daniel Schmidt"  
> > -
> > 
> > 
> > Date: Thu, 16 May 2013 06:23:52 -0700
> > From: "J. Daniel Schmidt" 
> > To: crowbar/barclamp-provisioner  > provisio...@noreply.github.com>
> > Cc: Adam Spiers 
> > Subject: Re: [barclamp-provisioner] adaptions to allow the script also for 
> > SUSE
> > based images
> > (756e8f9)
> > Reply-To: crowbar/barclamp-provisioner
> >  > 100...@reply.github.com>
> > 
> > This was done to allow the script to run in the SUSE sleshammer image. This
> > image is very stripped down and no gem installs are possible at runtime - 
> > all
> > needed gems have to be added to the image itself.
> > There was some other magic in the original sledghammer image that put some
> > gem files to /root and this script was meant to install them. With this 
> > patch we
> > disabled the behaviour for suse but kept it for other distributions resp.
> > sles/slege-hammer images.
> > 
> > 
> > So if this feature is still present, we should definitely port this patch - 
> > or a similar
> > functionality to disable gem installs.
> > 
> > ---
> > Reply to this email directly or view it on GitHub:
> > https://github.com/crowbar/barclamp-
> > provisioner/commit/756e8f9a3289b9b264513fadb010ed004a9ca1ea#commitco
> > mment-3226553
> > 
> > - End forwarded message -
> > 
> > ___
> > Crowbar mailing list
> > Crowbar@dell.com
> > https://lists.us.dell.com/mailman/listinfo/crowbar
> > For more information: http://crowbar.github.com/


___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Crowbar for non-PXE deployments

[Adam Spiers]

Hi Tim,

Timothy Rees (reestr...@gmail.com) wrote:
> This project recently came to my attention when I was looking for a generic
> application that could be used to push OS deployments to Dell PowerEdge
> bare-metal without the requirement of PXE.  However, of course I now see
> that this project depends depends on PXE and it was originally intended to
> push a complete cloud environment, not just one off OS deployments.
> 
> My question is, could the work to incorporate deployments using the
> PowerEdge Lifecycle controller (wsman) be incorporated into this project
> and if so, would that be of interest?  Back to my specific use case, we've
> already got management systems such as SCCM/Satellite that can manage the
> OS through its lifecycle once it has been deployed, we're only looking for
> a single deployment tool that can be used without the requirement for PXE.
> 
> Although I have more of a python background, I would be happy to try and
> port to Perl and contribute if this is something that would be seen to add
  
You mean Ruby, I hope ;-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Version number for Pebbles

[Adam Spiers]

Simon Jakesch (simon_jake...@dell.com) wrote:
> Pebbles is version 1.6

https://github.com/crowbar/crowbar/wiki/Roadmap says:

v1.6 "Wilma": Cloudera Hadoop Update

Is that no longer true?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] [barclamp-provisioner] First batch of forward-porting of SUSE-specific patches to Pebbles (#125) (fwd)

[Adam Spiers]

Please could someone from Dell review this?  We have many more
provisioner commits to upstream but cannot submit until this is
merged.  Thanks!

- Forwarded message from rhafer  -

Date: Tue, 21 May 2013 09:18:12 -0700
From: rhafer 
To: crowbar/barclamp-provisioner 
Cc: Adam Spiers 
Subject: Re: [barclamp-provisioner] First batch of forward-porting of 
SUSE-specific patches to
Pebbles (#125)
Reply-To: crowbar/barclamp-provisioner



I just finshed a successful smoke test run for this on ubuntu (together with 
https://github.com/crowbar/barclamp-crowbar/pull/515)

---
Reply to this email directly or view it on GitHub:
https://github.com/crowbar/barclamp-provisioner/pull/125#issuecomment-18219479

- End forwarded message -

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Confession - I just merged a pull-request without testing

[Adam Spiers]

John Terpstra (john_terps...@dell.com) wrote:
> Folks,
> 
> I bad fingered a merge of  
> https://github.com/crowbar/barclamp-provisioner/pull/125 - Apologies for bad 
> action.  Will test immediately and will report back.  If this broke anything 
> I will revert the merge.

We already tested it on Ubuntu, so hopefully it won't!  But thanks
anyway, a test on RH would be a great help.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Version number for Pebbles

[Adam Spiers]

I thought it would be more useful to update it than ignore it ...
so I did ;-)

Simon Jakesch (simon_jake...@dell.com) wrote:
> Yeah, ignore that.
> 
> -Original Message-
> From: crowbar-bounces On Behalf Of Adam Spiers
> Sent: Wednesday, May 22, 2013 11:11 AM
> To: crowbar
> Subject: Re: [Crowbar] Version number for Pebbles
> 
> Simon Jakesch (simon_jake...@dell.com) wrote:
> > Pebbles is version 1.6
> 
> https://github.com/crowbar/crowbar/wiki/Roadmap says:
> 
> v1.6 "Wilma": Cloudera Hadoop Update
> 
> Is that no longer true?
> 
> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/


___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Confession - I just merged a pull-request without testing

[Adam Spiers]

John Terpstra (john_terps...@dell.com) wrote:
> It appears that this pull is OK.  It has been merged.

Thanks a lot John :)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Version number for Pebbles

[Adam Spiers]

Hi Mike, thanks although I don't see any changes showing up yet - did
you maybe forget to push commits from your clone of the wiki repo?

https://github.com/crowbar/crowbar/wiki/Roadmap/_history

michael_pitt...@dell.com (michael_pitt...@dell.com) wrote:
> Thanks- I cleaned up some of the hadoop info on that page, to make it clearer.
> 
> The confusion was that the Crowbar and Hadoop releases are not sync'ed 
> together.  A given Hadoop release includes a specific crowbar release, so I 
> updated the page to indicate which hadoop releases were based on which 
> Crowbar branches.
> 
> mike
> 
> -Original Message-----
> From: crowbar-bounces On Behalf Of Adam Spiers
> Sent: Wednesday, May 22, 2013 5:25 PM
> To: crowbar
> Subject: Re: [Crowbar] Version number for Pebbles
> 
> I thought it would be more useful to update it than ignore it ...
> so I did ;-)
> 
> Simon Jakesch (simon_jake...@dell.com) wrote:
> > Yeah, ignore that.
> > 
> > -Original Message-
> > From: crowbar-bounces On Behalf Of Adam Spiers
> > Sent: Wednesday, May 22, 2013 11:11 AM
> > To: crowbar
> > Subject: Re: [Crowbar] Version number for Pebbles
> > 
> > Simon Jakesch (simon_jake...@dell.com) wrote:
> > > Pebbles is version 1.6
> > 
> > https://github.com/crowbar/crowbar/wiki/Roadmap says:
> > 
> > v1.6 "Wilma": Cloudera Hadoop Update
> > 
> > Is that no longer true?
> > 
> > ___
> > Crowbar mailing list
> > Crowbar@dell.com
> > https://lists.us.dell.com/mailman/listinfo/crowbar
> > For more information: http://crowbar.github.com/
> 
> 
> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/


___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Version number for Pebbles

[Adam Spiers]

michael_pitt...@dell.com (michael_pitt...@dell.com) wrote:
> It helps when the changes are made in the correct repo; I accidentally 
> updated the old cloudedge repo...the changes are in the right place now.

Ah :-)  Cheers Mike!

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Tomorrow's Design Meeting

[Adam Spiers]

Simon Jakesch (simon_jake...@dell.com) wrote:
> Everyone,
> 
> for tomorrow's design meeting, we will discuss various topic around
> Crowbar 2.0. The detailed topics are documented and available at
> http://www.fileswap.com/dl/H4seAxa4o/.

Thanks - greatly appreciate the effort that went into writing this
document and sharing thoughts on it in the call earlier.  Brief
feedback follows (with the caveat that my understanding of the area is
still fairly shallow relative to those of you who have been working
closely on this design and code for a long time!)

  - I'm either in favour of most numbered points in the document (very
strongly in the case of 1. and 2.), and unable to comment (through
lack of understanding) on the others.  IOW, I don't disagree with
any of them.

  - It would be *much* easier to understand the design if some
fictitious "real world" scenarios were mapped out as examples
showcasing how this model would handle them.

  - Not yet convinced we need to number states as in point 1., but
am interested to hear arguments for.

  - I'd like to see some examples of how dependencies on networking
roles would be expressed.  In particular do we want to allow
policy- or constraint-based resolution of network dependencies
based on the characteristics of the network resource(s) available
(e.g. speed, redundancy etc.) ?  Or is that overkill?

  - How do we handle removal of nodes from roles?

Also, one minor point on process: I'd prefer that design documents
were shared either as an etherpad, wiki page, or plain-text email.
Read-only PDF is not too conducive to collaboration ;-)

Thanks again!
Adam

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Change in sledgehammer-common impacting more than Pebbles

[Adam Spiers]

Vincent Untz (vu...@suse.com) wrote:
> Hi,
> 
> I just realized that one of my commits that got merged will impact
> non-Pebbles branches, and might be an issue requiring changes in these
> branches too. This is the following commit:
>   
> https://github.com/crowbar/crowbar/commit/29b97580c42bdfe1e0b548cff773811eaeea16d9
> 
> In short, this is changing /install-logs to
> /var/log/crowbar/sledgehammer.

+1

> Other branches that are using the sledgehammer-common/start-up.sh file
> from crowbar master should probably be updated with commits like these
> ones:
> 
>  
> https://github.com/crowbar/barclamp-provisioner/commit/0290fc89b4ca8d446eac9c3140247f18166fd6f1
>  
> https://github.com/crowbar/barclamp-logging/commit/9410dd876fc7603e0ed9f34cefd78d7a4dcd4633
> 
> FWIW, I find it a bit confusing that sledgehammer-common/start-up.sh
> isn't tracked in a Pebbles branch...

Indeed!

This is one of the things that I proposed to work on with Victor
during my visit to Austin (i.e. changing the top-level crowbar repo to
have the same branches as the barclamp repos).  IIRC he's on board
with the idea :-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] CB2 Design Notes & Video from Call

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> All,
> 
> The notes have been moved to 
> https://github.com/crowbar/crowbar/wiki/Sprint-2013-05-24 for collaborative 
> editing.

Thanks!  I fixed the broken image and some other minor formatting issues.

> The updated DB schema w/ a reference example is here: 
> https://github.com/cloudedge/barclamp-crowbar/blob/master/doc/devguide/model/crowbar_model.png

Thanks again!  The reference example is very useful.  I think the
arrows to the Test Deployment are going in the wrong direction though?
Or maybe they should be bi-directional.

> I'd encourage a discussion on the list (please limit to one card per thread!).
> 
> NEW CONCEPT NOTE! In review of these notes with Victor, he made a
> very interesting suggestion to have deployments ABOVE barclamps.
> This would mean that users would have a logical deployment group
> (e.g.: test, dev, prod) that includes all the barclamps they are
> using.

Interesting idea, I'll have to think more about it but my first
instinct is to be worried about the reduced granularity that this
would result in.  For example if you modify the parameters of a
deployment (e.g. just to tweak something in keystone) then presumably
it is going to trigger chef runs on a *lot* more nodes than it needs
to?

> Since ROLES are the really container, you'd choose the roles that you wanted 
> to include in a deployment and Crowbar would use the dependency graph to 
> include all the needed barclamps to implement that role.
> 
> For example, if you choose the Nova Compute role then it would add the Nova 
> Controller, Keystone, SQL, Message Bus, Network...etc roles.
> 
> Hmmm... that would also mean that the node available in a deployment would be 
> added to the Crowbar Role.
> 
> I'm really excited about this suggestion.  I think it makes coding/using 
> Crowbar simpler and natural.

I'm not convinced yet (but willing to be persuaded).  From a UX
perspective it seems less intuitive to me because there's more "magic"
happening.  I would expect that the UI should present the user with
all the components they are going to deploy, and request assignment of
roles to nodes, rather just present and request assignment for a
single role which would then result in a sort of "oh by the way, if
you want nova-compute then you'll also need these other ones - where
do you want to put them?" experience from the UI.

I'm also not sure how having deployments above barclamps would tie in
with the OpenStack grouping barclamp?  There still needs to be some
way to templatize the workflow into "give me a complete OpenStack
cloud, and along the way ask me to assign stuff to nodes in the right
order", so I'd be interested in how this would work with higher-level
deployments.

Another way of viewing the move of deployments to be above barclamps
rather than below is to consider it as allowing multiple barclamps per
deployment.  But maybe you could achieve something similar by allowing
deployments to contain (multiple) other deployments, e.g. via a type
of barclamp that exists purely as a container for other deployments
(template-based or otherwise).

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Change in sledgehammer-common impacting more than Pebbles

[Adam Spiers]

Victor Lowther (victor_lowt...@dell.com) wrote:
> > -Original Message-
> > From: crowbar-bounces On Behalf Of Vincent Untz
> > Sent: Thursday, May 30, 2013 7:57 AM
> > To: crowbar
> > Subject: Re: [Crowbar] Change in sledgehammer-common impacting more than
> > Pebbles
> > 
> > Le jeudi 30 mai 2013, à 07:03 -0500, Victor Lowther a écrit :
> > > On Thu, May 30, 2013 at 3:28 AM, Vincent Untz  wrote:
> > >
> > > > Hi,
> > > >
> > > > I just realized that one of my commits that got merged will impact
> > > > non-Pebbles branches, and might be an issue requiring changes in
> > > > these branches too. This is the following commit:
> > > >
> > > >
> > https://github.com/crowbar/crowbar/commit/29b97580c42bdfe1e0b548cff7
> > > > 73811eaeea16d9
> > > >
> > > > In short, this is changing /install-logs to
> > > > /var/log/crowbar/sledgehammer.
> > > >
> > >
> > > That is going to break rather a lot of stuff.
> > >
> > >
> > > > Other branches that are using the sledgehammer-common/start-up.sh
> > > > file from crowbar master should probably be updated with commits
> > > > like these
> > > > ones:
> > > >
> > > >
> > > > https://github.com/crowbar/barclamp-provisioner/commit/0290fc89b4ca8
> > > > d446eac9c3140247f18166fd6f1
> > > >
> > > > https://github.com/crowbar/barclamp-logging/commit/9410dd876fc7603e0
> > > > ed9f34cefd78d7a4dcd4633
> > >
> > >
> > > No -- that is all the builds in all the releases, as Sledgehammer is
> > > globally applicable to them all.  Your changes modifying these paths
> > > will have to be reverted and applied in a way that is Pebbles
> > > specific, preferably by modifying control.sh in the provisioner.
> > 
> > I'm sorry, I just don't get how we can change start-up.sh, then.
> > Whatever we change there will always break a past release. If we revert this
> > change, then it means we need to keep /install-logs/ as a NFS export, even 
> > in
> > Pebbles.
> >
> > Is there a good reason all this sledgehammer stuff is not per-branch like
> > everything else?
> 
> There are reasons that seemed like a good idea at the time when we
> did it a year and a half ago,

So what are those reasons, and are they still considered good ideas?

> and not everything else is per-branch -- the rest of the build
> system and the test framework is also global.

... which means that every time we want to touch the build system or
the test framework, we risk breaking them for every single release
(where by "release" I mean Fred, Pebbles etc.).  So the same question
applies, is there a good reason for that?  Because AFAICS unless it's
a really really good one, it doesn't outweigh the drastic
disadvantages of the status quo.

If there *is* a really good reason, then the per-branch code should
*not* live in the same repo as the globally-applicable code.

> > Or alternatively: why do we even have a lot of stuff in start-up.sh? Why 
> > don't we
> > move nearly all of this in control.sh, except for the mount for the one NFS
> > export that will make control.sh accessible?
> 
> Having control.sh take over from start-up.sh is in fact the direction I have 
> been going. 

Cool :)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Change in sledgehammer-common impacting more than Pebbles

[Adam Spiers]

Victor Lowther (victor.lowt...@gmail.com) wrote:
> On Thu, May 30, 2013 at 3:50 AM, Adam Spiers  wrote:
> > Vincent Untz (vu...@suse.com) wrote:
> > > Other branches that are using the sledgehammer-common/start-up.sh file
> > > from crowbar master should probably be updated with commits like these
> > > ones:
> > >
> > >
> > https://github.com/crowbar/barclamp-provisioner/commit/0290fc89b4ca8d446eac9c3140247f18166fd6f1
> > >
> > https://github.com/crowbar/barclamp-logging/commit/9410dd876fc7603e0ed9f34cefd78d7a4dcd4633
> > >
> > > FWIW, I find it a bit confusing that sledgehammer-common/start-up.sh
> > > isn't tracked in a Pebbles branch...
> >
> > Indeed!
> >
> > This is one of the things that I proposed to work on with Victor
> > during my visit to Austin (i.e. changing the top-level crowbar repo to
> > have the same branches as the barclamp repos).  IIRC he's on board
> > with the idea :-)
>
> Not really

OK, I guess I misunderstood our conversation in Portland then.

> I despise having to maintain n copies of the build system,

What do you mean by "maintain" and by "n" here, exactly?  The whole
point of branching for each release is to make a copy so that ongoing
work on the next release doesn't destabilise the last.  That's an
industry-standard practice, and I don't see why it makes any less
sense here.

Yes, I appreciate that that means occasionally fixes to build_lib.sh
etc. would have to be backported to the (n-1) release, or maybe even
(n-2) but generally not to *all* n releases, and even if that was the
case, git cherrypick or similar make this easy to automate.  

This seems *far* preferable to me than the situation we currently have
where every single time we make a change to the build system, the only
way we can be really sure it won't break stuff is to retest every
single build from every single release going back to the beginning of
time, which would be an unmanageable amount of work.  What am I
missing here?

> and that is what doing that will currently entail.

Actually we already have plenty of duplication under the releases/
hierarchy.  Its symlink-based approach is essentially a poor-man's
implementation of a copy-on-write scheme which git handles much better
via tree objects which point to blobs.

This versioning issue is precisely what modern DVCS such as git were
designed to solve, so I don't understand why we should continue
relying on "cp" and "ln -s" instead, which is a bit like the dark ages
approach svn takes to maintaining branches in parallel trees ;-)

> Rearchitecting what
> repo has responsibility for what (which we will have to do in any case) in
> such a way that does not result in  a combinatorial explosion of
> identical-execpt-for-bug-inducing-differences code is OK

Agreed, I am certainly not proposing anything which would cause in
such a combinatorial explosion!

It sounds like we are at very least aligned on the need to split up
the top level repo.  I'd be interested to hear your thoughts on the
best order / approach for this.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] crowbar check-ins

[Adam Spiers]

John Terpstra (john_terps...@dell.com) wrote:
> -Original Message-
> From: crowbar-bounces On Behalf Of Vincent Untz
> Sent: Thursday, May 30, 2013 11:16 AM
> To: crowbar
> Subject: Re: [Crowbar] crowbar check-ins
> 
> Le jeudi 30 mai 2013, à 10:58 -0500, arkady_kanev...@dell.com a écrit :
> > Dear team,
> > Over the last few days pebbles code base become very unstable.
> > Two biggest issues right now are logging changes and 2 versions of mysql 
> > cookbooks, one in mysql barclamp and one in database one.
> > 
> > Victor fixed the logging issue in sledgehammer and Wayne is working on the 
> > second issue.
> > Please, make sure you test your check-ins before submission.
> 
> To be fair, the logging issue was tested and functional, and didn't cause any 
> unstability for Pebbles.
> 
> But with the current setup of the toplevel crowbar repo, testing has to be 
> done not just on Pebbles, but on virtually all releases. I don't think this 
> is a reasonable expectation and this is something that should get fixed at 
> some point.
> 
> [JohnT] I agree most vehemently!

This is exactly what my mail earlier today was saying, and one of the
high priority items to address during my visit to Austin.  Victor, I
won't be able to do it without help from you, so I hope you are going
to be there for those 3 days! ;-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] multi-proposal in pebbles

[Adam Spiers]

Arkady Kanevsky (arkady_kanev...@dell.com) wrote:
> Team,
> Currently multi-proposal does not work in pebbles.

Out of curiosity, what goes wrong?  I haven't tried it yet.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] CB2 Core Design update

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> Victor and I were kicking around the DB models a little more.  The result was 
> a further refinement/simplification for discussion.
> 
> 
> 1)  Deployment is the top level thing.  Basically, all the roles hang off 
> the deployment (through the snapshot pointer).  When a role has a 
> prerequisite, that prerequisite is always resolved from within the 
> deployment.  The discussion image shows the role prereq chain in blue.

Just checking you saw my feedback yesterday?  I'm not yet convinced
how well this will work, but I'm very willing to be persuaded via
answers to my questions :)  Also, the arrows are still wrong.

> 2)  Each role is linked to a one (and only one) jig.  That means
> it is very clear which jig owns the operation of any role and the
> inbound data values related to that role.  The consequence of that
> design choice is that we may have "duplicate" roles that are
> implemented by different jigs.  For example, the SQL barclamp could
> have roles for the Puppet and Chef jigs.  While that seems
> redundant, it is much clearer and reduces a lot of ambiguity.

Sounds reasonable, although it's not immediately obvious to me why
it's clearer / less ambiguous.

> It would be OK for a role tied to the Chef jig to have a Puppet jig
> role as a prereq

Why?  That sounds weird to me.

> however, we expect that most roles will be chained within a single jig type.

When would it make sense for a role to be tied to multiple jig types?

> 3)  The jig is responsible to updating the state of the node-role after 
> any activity.  Having roles tied to jigs makes that ownership very clear.
> 
> Schema:
> https://github.com/crowbar/barclamp-crowbar/blob/master/doc/devguide/model/crowbar_model.png
> Example:
> https://github.com/crowbar/barclamp-crowbar/blob/master/doc/devguide/model/crowbar_model_discussion.png

Without cardinality markings for each association, the schema is of
limited use.  For example, how many Chef jigs will there be?  One
globally, or one per deployment, or one per barclamp?

> Remember: the node-role relationship is proposed as the core atomic unit in 
> CB2 core.  It's the action handle that's passed to a jig and also the place 
> where state is updated.

Yep, strongly in favour of this.

> Overall, I feel like we're moving towards a model that is more
> explicit and direct than before.

I don't have any reason to disagree with that yet, but I feel like a
large part of the reasoning behind that sentiment has not been widely
shared yet, until which time I can't really agree either ;-)

Perhaps we can cover this during my visit?

> Our design objective is that Crowbar operations are more transparent
> and easier to track.

Amen! :-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] CB2 Core Design update

[Adam Spiers]

Adam Spiers (aspi...@suse.com) wrote:
> Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> > Victor and I were kicking around the DB models a little more.  The result 
> > was a further refinement/simplification for discussion.
> > 
> > 
> > 1)  Deployment is the top level thing.  Basically, all the roles hang 
> > off the deployment (through the snapshot pointer).  When a role has a 
> > prerequisite, that prerequisite is always resolved from within the 
> > deployment.  The discussion image shows the role prereq chain in blue.
> 
> Just checking you saw my feedback yesterday?  I'm not yet convinced
> how well this will work, but I'm very willing to be persuaded via
> answers to my questions :)

Just as an aside, I'm sort of puzzled that we're going through another
fundamental iteration of redesign of 2.0 at this point.  Have the
timescales for release shifted sufficiently far into the future to
make this feasible?  I haven't been too involved in those discussions
so maybe I missed something, but I thought the goal was to aim for a
2.0 release relatively soon after Pebbles?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] CB2 Core Design update

[Adam Spiers]

Thanks Rob / Judd / Simon for the clarification.  Which of you will be
in Austin when I'm there (June 24-26)?  Seems like a good opportunity
to continue this discussion.

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> Adam / Chris / CB Community,
> 
> I tried to frame this during the design call and it's worth repeating -> the 
> original scope for CB2 was overly ambitious and I believe we need a more 
> practical target ("CB2 core") for our next iteration.
> 
> We've accomplished a lot in CB2 trunk from database schema, jig framework, 
> Chef 11, Rails 3, Ruby 1.9, automated testing, integrated docs, improved 
> packaging and much other real progress.  
> 
> Most importantly, we have LEARNED a lot.  With the pause for Pebbles, we've 
> had a chance to reflect.  The #1 lesson for me is that our orchestration 
> plans were incomplete and too large.  It is now clear to me that the 
> orchestration complexity was a major factor in our delivery slips.
> 
> My objective is to start bringing these lessons learned to the community for 
> discussion.   I think a dialog about them is important; however, we need to 
> accept that the code base will be "down-factored" to achieve a core 
> functionality set.  These functions will include work from above that we've 
> accomplished and should also deliver important CB2 objectives like late-bound 
> networking, heterogeneous O/S, online cache mode, scale, multiple CMDBs, and 
> the ability share/upstream cookbooks.
> 
> I've seen some great discussion on this topic so far.  I hope my $0.02 helps 
> add clarity.
> 
> I'm going offline for a week - I'm looking forward to seeing where you've 
> taken this when I return.
> 
> Rob
> 
> -Original Message-
> From: crowbar-bounces On Behalf Of Adam Spiers
> Sent: Friday, May 31, 2013 5:38 AM
> To: crowbar
> Subject: Re: [Crowbar] CB2 Core Design update
> 
> Adam Spiers (aspi...@suse.com) wrote:
> > Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> > > Victor and I were kicking around the DB models a little more.  The result 
> > > was a further refinement/simplification for discussion.
> > > 
> > > 
> > > 1)  Deployment is the top level thing.  Basically, all the roles hang 
> > > off the deployment (through the snapshot pointer).  When a role has a 
> > > prerequisite, that prerequisite is always resolved from within the 
> > > deployment.  The discussion image shows the role prereq chain in blue.
> > 
> > Just checking you saw my feedback yesterday?  I'm not yet convinced 
> > how well this will work, but I'm very willing to be persuaded via 
> > answers to my questions :)
> 
> Just as an aside, I'm sort of puzzled that we're going through another 
> fundamental iteration of redesign of 2.0 at this point.  Have the timescales 
> for release shifted sufficiently far into the future to make this feasible?  
> I haven't been too involved in those discussions so maybe I missed something, 
> but I thought the goal was to aim for a
> 2.0 release relatively soon after Pebbles?
> 
> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/


___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] status and merge orchestration

[Adam Spiers]

arkady_kanev...@dell.com (arkady_kanev...@dell.com) wrote:
> Vincent, you cannot have both database and MySQL barclamps at the same time.

I could be wrong but I think he was suggesting having two parallel
branches for a short period of time.

> The goal is have all changes in Pebble.
> If we (all parties) work in their private repos we lose community.

Sure, but multiple topic branches in the same public repo is a
different thing :-)

But again I may have misunderstood ...

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] status and merge orchestration

[Adam Spiers]

arkady_kanev...@dell.com (arkady_kanev...@dell.com) wrote:
> Adam and Vincent,
> I fully understand and appreciate your suggestion.
> 
> The real question is how to handle major code refactoring that affects all 
> barclamps (in this case OS ones).
> Testing of refactoring takes a long time (multiple days). Every time a change 
> happens to any barclamp the long poll testing needs to be restarted.
> 
> I am aware of 3 ways to proceed.
> One, is to be able to break refactoring into smaller pieces. (This is what we 
> tried to do with database barclamp refactoring. But we were not successful 
> with running both database and MySQL barclamps concurrently.) That would 
> allow all work to proceed without blocking.
> Second, to complete refactoring testing without changing any barclamps under 
> it.  
> Third, to merge it as is and fix consequential breakage.
> 
> I am completely open to any suggestion, except for repeated testing of 
> database refactoring for any change in OS barclamps.

I still don't understand why there would *ever* be a need to block, if
we use topic branches.  However, now that steps 1--3 are done I guess
we don't need to worry too much about this right now.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Database barclamp merges....

[Adam Spiers]

arkady_kanev...@dell.com (arkady_kanev...@dell.com) wrote:
> Thanks Wayne and Chris for staying late and finishing the merge.

Great work guys!

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Differences between "Delete" and "Reset" actions?

[Adam Spiers]

Vincent Untz (vu...@suse.com) wrote:
> Le jeudi 30 mai 2013, à 13:10 +0200, Vincent Untz a écrit :
> > Hi,
> > 
> > While investigating a bug, I wondered about the differences between the
> > "Delete" and "Reset" (which also seems to be called "Deallocate")
> > actions in Crowbar.
> > 
> > The only doc I could really find is at
> > https://github.com/crowbar/travis-ci-crowbar/blob/master/barclamps/crowbar/doc/userguide/using-crowbar.md
> > and it says:
> > 
> > Delete: Completely removes all records of the node from the Crowbar/Chef
> > database. If a node is deleted, it is rediscovered when it reboots.
> > 
> > Reset: Removes all the roles assigned to the node and re-image it back
> > to an unallocated node.
> > 
> > Do I understand it right that Reset is more or less like Delete, except
> > that it re-allocates the node on next discovery? If that's correct, the
> > Deallocate name is, hrm, kind of weird because it's re-allocated. If
> > that's not correct, then what's the difference?
> 
> So, nobody knows? I guess it means we should just drop deallocate in
> that case ;-)

Does this help?

https://github.com/crowbar/barclamp-crowbar/commit/43aab2

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Differences between "Delete" and "Reset" actions?

[Adam Spiers]

My memory is beginning to trickle back on this one ...

Vincent Untz (vu...@suse.com) wrote:
> Le lundi 10 juin 2013, à 17:44 +0100, Adam Spiers a écrit :
> > Vincent Untz (vu...@suse.com) wrote:
> > > Le jeudi 30 mai 2013, à 13:10 +0200, Vincent Untz a écrit :
> > > > Hi,
> > > > 
> > > > While investigating a bug, I wondered about the differences between the
> > > > "Delete" and "Reset" (which also seems to be called "Deallocate")
> > > > actions in Crowbar.

Right - as you saw by now, I wrote the below patch (43aab2) a long
time ago to try to make this clearer, obviously with limited success ;-/
But at least the ambiguity around "Reset" is gone, since normally
"Reset" just means "press the Big Red Button on the front".

> > > > The only doc I could really find is at
> > > > https://github.com/crowbar/travis-ci-crowbar/blob/master/barclamps/crowbar/doc/userguide/using-crowbar.md
> > > > and it says:
> > > > 
> > > > Delete: Completely removes all records of the node from the Crowbar/Chef
> > > > database. If a node is deleted, it is rediscovered when it reboots.
> > > > 
> > > > Reset: Removes all the roles assigned to the node and re-image it back
> > > > to an unallocated node.
> > > > 
> > > > Do I understand it right that Reset is more or less like Delete, except
> > > > that it re-allocates the node on next discovery?

Yeah I think that's probably right.  control.sh has:

case $DHCP_STATE in
reset|discovery) discover && hardware_install;;

and NodeObject#set_state doesn't behave differently for either.

> > > > If that's correct, the Deallocate name is, hrm, kind of weird
> > > > because it's re-allocated.

OK, so maybe I chose the wrong replacement word.  Maybe "Rebuild",
although that's too close to "Reinstall" for comfort.  "Reallocate"?
Open to ideas ...

> > > > If that's not correct, then what's the difference?
> > > 
> > > So, nobody knows? I guess it means we should just drop deallocate in
> > > that case ;-)
> > 
> > Does this help?
> > 
> > https://github.com/crowbar/barclamp-crowbar/commit/43aab2
> 
> Not really :-) What's the difference between:
> 
> "This will remove the current allocation from the node.  Any subsequent
> allocation will rebuild the node from scratch, causing any data to be
> lost."
> 
> and
> 
> "This will remove all records of the node from the Crowbar / Chef
> database.  It will be rediscovered if it reboots."
> 
> In both cases, the node will be rebuilt from scratch next time it gets
> allocated.

Yes but in the "Forget" case (formerly "Delete") you have to first
manually allocate it.  It's as if it was never part of Crowbar before,
hence why I renamed it to "Forget".  That could be useful if you
aren't yet sure whether you want to re-add it into the cluster,
whereas you'd use "Deallocate" if you know you want it immediately
re-added.

> Or does deallocate mean "if I'm reallocated, I will keep the
> exact same roles as I had before", in which case this means "temporarily
> disable".

Ah, that's a different issue.  I suspect that neither button will
remove the node roles from any existing proposals.  But my memory is
still very shakey on this stuff, so all the above could be wrong ...

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] one-shot barclamps

[Adam Spiers]

Sascha Peilicke (speili...@suse.com) wrote:
> Hi guys,
> 
> I recently wrote a barclamp to update system packages on deployed nodes. 
> We will need this for SUSE Cloud to be able to deploy maintenance / 
> security updates to customers. However, due to the nature of the 
> barclamp, it isn't supposed to run all time. Instead, a cloud operator 
> wants to trigger the federated update for a specific set of machines at 
> a specific point in time.

Very nice :)

> In essence, this means the wrapped cookbook is a one-shot one. With only 
> Chef-means, you would simply remove the updater recipe from a node's 
> run-list afterwards [1]. However, since Crowbar doesn't store the 
> run-list in the node object but a special role (crowbar-$FQDN) we seem 
> to run out of luck with only chef means. Chef-client running on a node 
> simply lacks the rights to modify a global role (i.e. remove a recipe 
> from the role's run-list).
> 
> The simplest approach would be to just use a special attribute in the 
> cookbook that acts as the 'actually-do-something' switch, e.g. 
> "defaults[:updater][:first-run] = true" which is then set to false after 
> the recipe was applied. This way, the barclamp would end up in "ready" 
> state showing success. But it's totally unclear for the user that the 
> thing is actually one-shot or that he has to edit / re-apply the proposal.

I think this could be solved by including a flag in the barclamp which
indicates that it's one-shot, e.g. in crowbar.yml or just

  def oneshot?
true
  end

in the model or something, and then extending the UI to adjust to this
accordingly: changing button names, maybe even exposing info about
previous runs.

> So the idea was to deactivate the proposal immediately after it was 
> applied so that it is obvious to the admin that he has to re-apply it 
> (with a potentially different set of nodes). A first shot was to add a 
> callback that is run after ServiceObject#apply_role [2],[3]. However, we 
> won't end up in ready state thus no green bubble, thus there's no 
> mechanism left to actually notify about success or failure. This could 
> be mitigated somewhat with a new state that signals "I ran successfully 
> and disabled myself".

But how would that interact with other roles being applied on the same
node, without resulting in confusion?  The state is per node, not per
node role (in contrast to current design proposals for Crowbar 2.0).

> It will be very likely that we will have more one-shot barclamps in the 
> future (e.g. evacuate-compute-node)

Agreed, this is good functionality to have for sure.

> therefore I'd like to get some 
> feedback before going further in any direction.

I think I prefer the first approach above rather than introducing a
new state for the reasons given.  But I could be missing something.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Make sure the Couchdb instance Chef uses does not grow without bound.

[Adam Spiers]

Victor Lowther (victor.lowt...@gmail.com) wrote:
> One of the common pieces of feedback we have gotten is that we do not
> garbage-collect the couchdb databases and views that Chef uses, which
> eventually leads to large amounts of wasted disk space and degraded Chef
> performance.
> 
> https://github.com/crowbar/barclamp-crowbar/pull/526 addresses that issue
> by having Crowbar run a GC cycle on the CHef databases and views once they
> have grown too large.  This patch should be applied to Pebbles and Hadoop
> 2.3 releases.

We fixed this in SUSE Cloud 1.0 a different way.  I provided the info here:

https://github.com/crowbar/barclamp-crowbar/pull/526#issuecomment-19320333

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Trello for Resolving Community Documentation Issues (Help request!)

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> All,
> 
> HELP REQUEST: We need your help to create a catalog of doc issues on 
> http://bit.ly/crowbar-maladocs
> 
> We had a discussion today about the high community cost for errors and 
> omissions in our documentation, wiki and other information.
> 
> First - I apologize for the impact of this.  As one of the longest active 
> maintainers, I know first-hand the expense and frustration for these gaps; 
> however, I also acknowledge that I am often a culprit in failing to leave 
> behind sufficient instructions.
> 
> To remedy the problem, I believe that we first need to create a catalog of 
> issues to resolve.  While we could create defects for these, our current 
> tracking process is not ready to handle these types of issues.  Instead, I'd 
> like to offer a Trello board (http://bit.ly/crowbar-maladocs ) where you can 
> add new issues as you find them.   Sometime in the next few weeks, I'm 
> recommending a "docs hack day" where we burn down the issues.
> 
> Of course, you're welcome to grab doc issue cards right away.  I just wanted 
> to set an expectation that we're not going to jump on each issue - our first 
> priority is to find them.
> 
> Suggestions and corrections to this approach are appreciated!

Thanks for kicking off some fresh impetus on this much-needed area.

We already have several documentation cards in the Community List of
the 2.0 backlog board.  Should those be moved to this new board?

I'm slightly worried that having a dedicated board for doc issues will
make it easier than ever for them to remain "out of sight, out of
mind".  However, I'd be delighted to be proven wrong ;-)
+100 for a docs hack day ...

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] new library needed for the build

[Adam Spiers]

Arkady Kanevsky (arkady_kanev...@dell.com) wrote:
> sudo apt-get install cabextract and re-run the build

Is this dependency documented somewhere?  Thanks...

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Pull-Request Review and Merge Process

[Adam Spiers]

[Sorry for the slow reply on this - I've been on vacation.]

John Terpstra (john_terps...@dell.com) wrote:
> I would like to initiate a discussion to secure an agreeable process for 
> handling of pull-requests for the Crowbar community project.
> Please respond to this email with your suggestions, recommendations, and 
> concerns.

[snipped]

Thanks for initiating this discussion - all sounds pretty good to me,
and I agree with all the feedback which has been raised so far.  I
think pull request discussions are largely working very well so far,
and should overflow into IRC / the mailing list when necessary.
I also agree that we should be careful not to introduce any
significant new overhead into the process.

> IV.  How should SME appointments be handled?
> 
> a.  Community vote?
> 
> b.  Organizational appointment?

Well, we already have: https://trello.com/b/dHi6lDYL/crowbar-ownership
the purpose of which was pretty much the same thing - to assign areas
of ownership to individuals.  Note however that it's not just the core
codebase that needs to be owned, e.g. places like the website, wiki,
Jenkins etc. too.

> c.  How are individual contributor efforts protected in this structure?

What do you mean exactly?  Efforts are already protected by the
licensing, right?  There's no copyright assignment required to
contribute IIRC, so I think contributors retain copyright.  See also
the CLAs (although I don't understand why these are necessary ...)

https://github.com/crowbar/crowbar/blob/master/doc/devguide/CLA.md

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Trello for Resolving Community Documentation Issues (Help request!)

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> Adam,
> 
> I agree on the concern about too many Trello's.  Right now the 2.0
> Backlog is not being managed.

Ah I see, is there a plan for when to start managing it again?

> My concern would be that people would not add 1.x doc issues to that backlog.

Well, there is also a 1.6 backlog board :-)

> I'm open to suggestions!

It's probably not so important to worry about which board these cards
should live on - the main thing is to actually address them.  The main
problems right now are a) that most of the doc tasks are unassigned
and/or completely neglected, and b) the documentation is utterly
bewildering for newcomers ;-/

We need to prioritise fixing the first documentation which a newcomer
to Crowbar first encounters or would like to encounter, since the main
objective is to grow the community.  The first port of call is most
likely http://crowbar.github.io/ and I guess most people are likely to
click on the Find Out More button first which leads to:

http://crowbar.github.io/docs/getting-started/

Unfortunately AFAICS that page is currently useless, since it doesn't
provide any download links.  The first item listed is "Configuring the
Network" - hardly appropriate for the beginning of a quickstart guide!
Even the 3rd item "Installing Crowbar" doesn't explain how to install
Crowbar.  Whilst glaring gaps such as these remain, I can't imagine
the Crowbar community ever growing :-/  So yes, a Docs Hack Day is much
needed.

Thanks for being open to this discussion!!

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] [pebbles] Allow passing an incomplete json when creating a proposal

[Adam Spiers]

Vincent Untz (vu...@suse.com) wrote:
> I just submitted this pull request, which I guess is worth discussing
> here:
>   https://github.com/crowbar/barclamp-crowbar/pull/589
> 
> Here's a copy and paste from the commit message:
> 
> ===
> Until now, when creating a proposal with some existing json, it was
> required that the json contained a full proposal definition. Two big
> downsides of this are:
> 
> a) it's easy to break stuff by accident when changing a proposal
> b) if the schema changes to add new mandatory attributes, people can
> not simply re-use old json they had around; they have to update them
> 
> This commit allows passing an incomplete json with only a subset of
> attributes. It will take the default json, and overwrite any attribute
> there with the ones from the incomplete json.
> 
> Note that this is note using Chef::Mixin::DeepMerge::deep_merge! as a
> deep merge is also merging arrays in attribute values, which is
> something not desired here. The hash_only_merge! API is actually
> available in Chef 11 in Chef::Mixin::DeepMerge, so this is just a
> backport.
> 
> For all that matters, this is backwards-compatible.
> ===
> 
> The main benefit I see is that it makes it really easy to use a json
> like this to create a database proposal using postgresql:
> 
> {
>   "id": "mydbproposal",
>   "attributes": {
> "database": {
>   "sql_engine": "postgresql"
> }
>   }
> }
> 
> All the missing attributes will be fetched from the database databag.
> 
> Any objection?

This sounds really nice to me - it cleanly separates out what the
admin wants to be different from the defaults, rather than mixing
those values with the defaults.  This should make upgrades smoother in
the future as you say, although I expect a forward-port to CB2.0 is
non-trivial.  Thanks!

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] CB2 Jig API patterns - starting from the basics on Script Jig

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> All,
> 
> We're working on core CB2 functions as per the design discussion from last 
> week.  Our objective is to code incrementally to validate the design.  I 
> believe this approach gives the community concrete examples for discussion 
> and makes it possible to update the design based on learning and new 
> viewpoints.
> 
> Currently, I've stripped out a lot of legacy code and rebuilt the very basics 
> of the model we discussed.  See DIA file 
> https://github.com/crowbar/barclamp-crowbar/blob/master/doc/devguide/model/crowbar_model.dia
> 
> In the next weeks, we are taking the first steps to define the Jig model API 
> and test it using the Script jig.  Here are some initial thoughts:

[snipped]

> * Crowbar will create a "run" handle when it transfers control of 
> node-roles to the Jig for operation
> 
> * The Jig will expose a run method that takes the run handle from 
> Crowbar
> 
> * When the Jig takes over the run, it will change the run status and 
> also update the node-role states to TRANSISTIONING
> 
> * The node-role's in a run will also have the run handle
> 
> * A node-role only be managed by one jig at a time (so a run handle 
> will be per jig)
> 
> There will be other items, but this is a good start.

How will the run handle be implemented?  Persisted in the DB?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] two questions about admin_ip

[Adam Spiers]

In pebbles, barclamps/network/chef/data_bags/crowbar/bc-template-network.json 
contains:

"admin": {

[snipped]

  "ranges": {
"admin": { "start": "192.168.124.10", "end": "192.168.124.11" },

What's the point of this /31 range?  Is 192.168.124.11 ever used, or
is it reserved for future releases which might have an HA setup?

Secondly, in 2.0, line 16 of:


https://github.com/crowbar/barclamp-provisioner/blob/master/chef/cookbooks/provisioner/recipes/update_nodes.rb#L16

seems to duplicate line 29 slightly further down.  Bug?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Barclamp import not available in gui anymore in mesa version?

[Adam Spiers]

volkan_satir...@dell.com (volkan_satir...@dell.com) wrote:
> Hi,
> 
> I believe "barclamp import" is not done through the GUI anymore in the mesa 
> version of the crowbar. Does anybody know how to import a barclamp in the new 
> version of the crowbar? Through cli? Which script does it? What is the syntax 
> for that?

/opt/dell/bin/barclamp_install.rb --help

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] [pebbles] Allow passing an incomplete json when creating a proposal

[Adam Spiers]

I just looked at this again in the light of my current work on 

https://github.com/crowbar/barclamp-provisioner/pull/177

...

Vincent Untz (vu...@suse.com) wrote:
> Hi,
> 
> I just submitted this pull request, which I guess is worth discussing
> here:
>   https://github.com/crowbar/barclamp-crowbar/pull/589
> 
> Here's a copy and paste from the commit message:
> 
> ===
> Until now, when creating a proposal with some existing json, it was
> required that the json contained a full proposal definition. Two big
> downsides of this are:
> 
> a) it's easy to break stuff by accident when changing a proposal
> b) if the schema changes to add new mandatory attributes, people can
> not simply re-use old json they had around; they have to update them
> 
> This commit allows passing an incomplete json with only a subset of
> attributes. It will take the default json, and overwrite any attribute
> there with the ones from the incomplete json.
> 
> Note that this is note using Chef::Mixin::DeepMerge::deep_merge! as a
> deep merge is also merging arrays in attribute values, which is
> something not desired here. The hash_only_merge! API is actually
> available in Chef 11 in Chef::Mixin::DeepMerge, so this is just a
> backport.

Why is merging of arrays not desired?  There are plenty of arrays
scattered around the JSON schema:

$ grep -c sequence barclamps/*/chef/data_bags/crowbar/bc-template-*.schema 
| sort -t: -k2 -nr  
barclamps/network/chef/data_bags/crowbar/bc-template-network.schema:9
barclamps/dns/chef/data_bags/crowbar/bc-template-dns.schema:8
barclamps/glance/chef/data_bags/crowbar/bc-template-glance.schema:7
barclamps/deployer/chef/data_bags/crowbar/bc-template-deployer.schema:7
barclamps/swift/chef/data_bags/crowbar/bc-template-swift.schema:6
barclamps/quantum/chef/data_bags/crowbar/bc-template-quantum.schema:6
barclamps/ntp/chef/data_bags/crowbar/bc-template-ntp.schema:6

barclamps/nova_dashboard/chef/data_bags/crowbar/bc-template-nova_dashboard.schema:6
barclamps/nova/chef/data_bags/crowbar/bc-template-nova.schema:6
barclamps/logging/chef/data_bags/crowbar/bc-template-logging.schema:6
barclamps/keystone/chef/data_bags/crowbar/bc-template-keystone.schema:6
barclamps/crowbar/chef/data_bags/crowbar/bc-template-crowbar.schema:6
barclamps/cinder/chef/data_bags/crowbar/bc-template-cinder.schema:6
barclamps/ceph/chef/data_bags/crowbar/bc-template-ceph.schema:6
barclamps/test/chef/data_bags/crowbar/bc-template-test.schema:5
barclamps/tempest/chef/data_bags/crowbar/bc-template-tempest.schema:5
barclamps/rabbitmq/chef/data_bags/crowbar/bc-template-rabbitmq.schema:5

barclamps/provisioner/chef/data_bags/crowbar/bc-template-provisioner.schema:5
barclamps/nagios/chef/data_bags/crowbar/bc-template-nagios.schema:5

barclamps/loadbalancer/chef/data_bags/crowbar/bc-template-loadbalancer.schema:5
barclamps/ipmi/chef/data_bags/crowbar/bc-template-ipmi.schema:5
barclamps/git/chef/data_bags/crowbar/bc-template-git.schema:5
barclamps/ganglia/chef/data_bags/crowbar/bc-template-ganglia.schema:5
barclamps/database/chef/data_bags/crowbar/bc-template-database.schema:5

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Migration of proposals/roles on schema updates

[Adam Spiers]

Vincent Untz (vu...@suse.com) wrote:
> A few weeks ago, I started the work on allowing schema changes in
> pebbles, without breaking existing proposals. In short, there's a
> migration rake task that will update the proposal (and its matching
> role, if committed) to the updated schema.

[snipped]

Looks good to me except for the point I already made:

>   - there are migration scripts in
> /opt/dell/chef/data_bags/crowbar/migrate/$barclamp/. The scripts
> must be named $rev_$somedescription.rb; the filename can have
> 0 (001_foobar.rb will work as well as 1_foobar.rb). There can be
> multiple scripts per revision; they will be executed by alphabetical
> order (or reverse alphabetical order in case of downgrades).

https://github.com/crowbar/barclamp-crowbar/pull/613#issuecomment-21722923

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Migration of proposals/roles on schema updates

[Adam Spiers]

Vincent Untz (vu...@suse.com) wrote:
> Le lundi 05 août 2013, à 12:39 +0100, Adam Spiers a écrit :
> > Vincent Untz (vu...@suse.com) wrote:
> > > A few weeks ago, I started the work on allowing schema changes in
> > > pebbles, without breaking existing proposals. In short, there's a
> > > migration rake task that will update the proposal (and its matching
> > > role, if committed) to the updated schema.
> > 
> > [snipped]
> > 
> > Looks good to me except for the point I already made:
> > 
> > >   - there are migration scripts in
> > > /opt/dell/chef/data_bags/crowbar/migrate/$barclamp/. The scripts
> > > must be named $rev_$somedescription.rb; the filename can have
> > > 0 (001_foobar.rb will work as well as 1_foobar.rb). There can be
> > > multiple scripts per revision; they will be executed by alphabetical
> > > order (or reverse alphabetical order in case of downgrades).
> > 
> > https://github.com/crowbar/barclamp-crowbar/pull/613#issuecomment-21722923
> 
> Ah, I had forgotten about that one :-)
> 
> As the migration scripts will be provided by the barclamp, and most
> barclamps won't need more than one migration script per revision, such a
> requirement on the naming of the migration scripts is, imho, not needed.
> People can do it, but forcing this is a bit too much to my taste. Don't
> know how others feel, though?

I agree it's not pretty.  I was just worried about engineering
ourselves into a corner with no obvious way out.  

If we were ever in a position where we originally thought only one
script xxx_foo.rb would be required for a given (barclamp, revision)
combination, and then we realised we needed more than one, and the
order mattered, then I guess we could rename xxx_foo.rb to
xxx_01_foo.rb before introducing xxx_02_bar.rb?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Crowbar and Openstack HA

[Adam Spiers]

Tim Cook (tcoo...@gmail.com) wrote:
> Can anyone provide any input on how Crowbar should or can handle stateful
> services failures like Horizon or Openstack database.
> 
>  Lets say for instance the node that I have allocated the mysql barclamp
> and nova dashboard barclamp dies, what are folks doing at this time ensure
> recoverability ?
> 
> Openstack.org suggest using Pacemaker with Corosync for Active/Passive
> recovery , which would be fine but integrating Pacemaker into Crowbar would
> pretty much defeat the purpose of the ease of use of Crowbar .

Why?  If the barclamps are extended in the right way, it should not be
much extra effort to deploy an architecture which uses Pacemaker.

stephen_fri...@dell.com (stephen_fri...@dell.com) wrote:
> We are working on an OpenStack HA solution. The document is being
> updated over the next week with more information.
> 
> https://github.com/crowbar/crowbar/wiki/Openstack-High-Availability

This is news to me!  Did I miss a big announcement somewhere?  Please
keep the Crowbar community updated on what you are working on with HA,
since this is a critical piece, and we are very interested in this
too.  We have quite a bit of Pacemaker / Corosync experience in-house
(e.g. we employ some of the core developers) which could be harnessed
to help move this forward.

Thanks a lot for publically documenting this though - the architecture
looks very promising.  By the way, the diagram at

  
https://github.com/crowbar/crowbar/wiki/Openstack-High-Availability-Logical-Architecture

is unreadably small.  Is there a larger version available?

Regards,
Adam

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Crowbar and Openstack HA

[Adam Spiers]

stephen_fri...@dell.com (stephen_fri...@dell.com) wrote:
> We presented this architecture on a Crowbar meetup about a month
> ago.

Ah, I was probably on vacation then.

> Any help people wish to provide on this would be great.
> 
> As we move forward we will be sure to email to this group on our progress.

Please do!  To clarify, currently you are still at the stage of
fleshing out the architecture - or have you already started writing
code?

Thanks!
Adam

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] new Cisco UCS integration barclamp

[Adam Spiers]

Hi all,

I recently took a SUSE-owned barclamp providing integration with Cisco
UCS Manager, and polished it up for pebbles.  It's currently here:

https://github.com/SUSE-Cloud/barclamp-cisco-ucs/tree/release/pebbles/master
https://github.com/aspiers/barclamp-cisco-ucs/tree/release/pebbles/master

The SUSE-Cloud one is currently forked from the aspiers repo.  I would
like to transfer the aspiers repo into the github.com/crowbar
organization, so that the SUSE-Cloud one becomes a fork of that
instead.  I have checked this end, and the code is all Apache 2.0
and owned by SUSE.  Any objections to the transfer?

Thanks,
Adam

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] new Cisco UCS integration barclamp

[Adam Spiers]

Good spot - fixed.

Simon Jakesch (simon_jake...@dell.com) wrote:
> I still see a bunch of Dell Copyrights in some of the files, but other than 
> that, no objections from my end.
> 
> Simon
> 
> -Original Message-
> From: crowbar-bounces On Behalf Of Adam Spiers
> Sent: Wednesday, August 28, 2013 10:44 AM
> To: crowbar
> Subject: [Crowbar] new Cisco UCS integration barclamp
> 
> Hi all,
> 
> I recently took a SUSE-owned barclamp providing integration with Cisco UCS 
> Manager, and polished it up for pebbles.  It's currently here:
> 
> https://github.com/SUSE-Cloud/barclamp-cisco-ucs/tree/release/pebbles/master
> https://github.com/aspiers/barclamp-cisco-ucs/tree/release/pebbles/master
> 
> The SUSE-Cloud one is currently forked from the aspiers repo.  I would like 
> to transfer the aspiers repo into the github.com/crowbar organization, so 
> that the SUSE-Cloud one becomes a fork of that instead.  I have checked this 
> end, and the code is all Apache 2.0 and owned by SUSE.  Any objections to the 
> transfer?
> 
> Thanks,
> Adam
> 
> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/


___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] build of pebbles missing nics?

[Adam Spiers]

Not entirely ;-)  There's the immediate cost on people's time which is
small but non-zero.  But then there's also the knock-on effect of
minor brokenness:

  
http://www.rtuin.nl/2012/08/software-development-and-the-broken-windows-theory/

Victor Lowther (victor_lowt...@dell.com) wrote:
> It is harmless.
> 
> > -Original Message-
> > From: crowbar-bounces On Behalf Of Judd Maltin
> > Sent: Wednesday, August 28, 2013 11:36 PM
> > To: crowbar
> > Subject: [Crowbar] build of pebbles missing nics?
> > 
> > 2013-08-29 00:25:08 -0400: Adding all nic drivers
> > ar: /VMs/.crowbar-build-cache/ubuntu-12.04/image/pool/main/l/linux/nic-*-
> > generic-*.udeb:
> > No such file or directory
> > tar (child): data.tar.gz: Cannot open: No such file or directory tar 
> > (child): Error is
> > not recoverable: exiting now
> > tar: Child returned status 2
> > 
> > It still makes an ISO.
> > 
> > Any insight?
> > 
> > --
> > Judd Maltin
> > T: 917-882-1270
> > F: 501-694-7809
> > what could possibly go wrong?
> > 
> > ___
> > Crowbar mailing list
> > Crowbar@dell.com
> > https://lists.us.dell.com/mailman/listinfo/crowbar
> > For more information: http://crowbar.github.com/
> 
> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/
> 

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] new Cisco UCS integration barclamp

[Adam Spiers]

Dell guys - did you discuss this as a team yet?  Thanks.

Adam Spiers (aspi...@suse.com) wrote:
> Good spot - fixed.
> 
> Simon Jakesch (simon_jake...@dell.com) wrote:
> > I still see a bunch of Dell Copyrights in some of the files, but other than 
> > that, no objections from my end.
> > 
> > Simon
> > 
> > -Original Message-
> > From: crowbar-bounces On Behalf Of Adam Spiers
> > Sent: Wednesday, August 28, 2013 10:44 AM
> > To: crowbar
> > Subject: [Crowbar] new Cisco UCS integration barclamp
> > 
> > Hi all,
> > 
> > I recently took a SUSE-owned barclamp providing integration with Cisco UCS 
> > Manager, and polished it up for pebbles.  It's currently here:
> > 
> > https://github.com/SUSE-Cloud/barclamp-cisco-ucs/tree/release/pebbles/master
> > https://github.com/aspiers/barclamp-cisco-ucs/tree/release/pebbles/master
> > 
> > The SUSE-Cloud one is currently forked from the aspiers repo.  I would like 
> > to transfer the aspiers repo into the github.com/crowbar organization, so 
> > that the SUSE-Cloud one becomes a fork of that instead.  I have checked 
> > this end, and the code is all Apache 2.0 and owned by SUSE.  Any objections 
> > to the transfer?
> > 
> > Thanks,
> > Adam
> > 
> > ___
> > Crowbar mailing list
> > Crowbar@dell.com
> > https://lists.us.dell.com/mailman/listinfo/crowbar
> > For more information: http://crowbar.github.com/
> 
> 
> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/
> 

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] new Cisco UCS integration barclamp

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> Adam,
> 
> Yes (and we're excited).  It's on the agenda topics for the community 
> planning call - would it be possible for you to demo?

Don't get too excited ;-)  Very limited functionality right now.
However it should be pretty easy to extend.

Yes I can demo.  Which call is that - Thursday 12th?

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Sprint Planning Recording

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> All,
> 
> I'm trying out a new feature of join.me that records our meetings.  Can 
> someone please validate that the recording is accessible?
> 
> Recording: 
> https://www.cubby.com/pl/Instant+meeting+2013-08-29.webm/_a61abacd45794e0d8ecf8911c1ea1c0e

Not for me - seems to require a logmein account.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] What's with the "Dell - Internal Use - Confidential" Header?

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> Crowbar Community,
> 
> In the last week, Dell IT added a "data protection feature" to our email 
> system that labels all emails as "Internal Use - Confidential" by default.
> 
> While we make every effort to remove this header before we send to the 
> community, we sometimes overlook it.
> 
> Please do not be confused - we are NOT sending confidential items into the 
> community by accident.  It is far more likely that we are simply forgetting 
> to turn off the default header.  We are not able to disable the default 
> setting of this feature - it is a company-wide policy.
> 
> If you have any questions about the intended audience of an email, please 
> feel free to contact the author directly.

Thanks for the explanation, and I offer my sympathies ;-)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Crowbar 2.0 Status Report

[Adam Spiers]

Victor Lowther (victor.lowt...@gmail.com) wrote:
> As of the latest set of pushes to development release, Crowbar 2.0 is now
> able to deploy an admin node that can then boot other nodes into
> Sledgehammer.  Unlike the last time CB2.0 was able to do this, the Crowbar
> framework is performing all the work needed to bootstrap itself into
> usefulness without manual intervention.  With the current codebase, you
> should be able to:
> 
>- Build a Crowbar ISO using the usual ./dev build --os ubuntu-12.04
>method.
>- Boot a VM (or real machine, if you have one to spare) to the generated
>ISO, and let it install
>- Once the admin node is installed, log in as crowbar/crowbar, sudo -i
>to root, and run /opt/dell/bin/install-crowbar your.admin.fqdn
>- Watch the script output with screen -r
>- Once screen terminates, log in to the Crowbar webui at
>http://192.168.124.10:3000 with crowbar/crowbar
>- Poke around all the new UI bits and see all the new shininess
>- Boot other nodes into sledgehammer and then watch them drop to a login
>prompt instead of doing something useful
> 
> While that does not sound like much on the surface

Actually, it sounds like a lot to me, bearing in mind the deep
structural overhaul.  Congrats on getting to this milestone!

> Design difference between CB 1.x and CB 2.0:

[snipped]

THANK YOU for writing these key changes up.  This should be
tremendously useful - both as a memory refresher for myself, and also
for colleagues who haven't yet been made aware of recent CB 2.0
design.

This info is too valuable to be allowed an undignified passive burial
in the mailing list archives.  Please can we find a new home for it
where it can be expanded, refined etc.?  I'm not sure the dev guide is
entirely the right place, because it's important that normal users are
also able to learn the high-level architecture.  So maybe in the user
guide?

>   - Node-role bindings (called noderoles for short -- please suggest a
>   better name for this!)

Assignments?  That's about the best I've managed so far ...

http://thesaurus.com/browse/assignment

> Next Steps for Crowbar 2.0 (in rough dependency order):
> 
>- Make framework side of the Network barclamp operate properly, instead
>of working in rigged demo mode.
>Right now, the Crowbar framework side of things is just smart enough to
>allocate an IP to the admin node to exercise the network recipe and
>bootstrap the rest of the admin node roles.  It needs to be able to track
>IP address allocations in a generic fashion, and it needs to be able to
>support other networks besides the admin network.
>- Flesh out node discovery.
>We can boot nodes into Sledgehammer, but we need to wire in more
>functionality to allow node discovery and configuration to take place.
>- Come up with a reasonable OS installation story, and implement it.
>- De-cruft the Crowbar-specific Chef cookbooks.
>While the current Chef cookbooks work with minimal changes, a
>side-effect of how the Crowbar framework manages configuration data via the
>node-role graph is that it is very easy for most of our core cookbooks to
>operate in an entirely attribute-driven fashion.  Refactoring them and
>stripping out the CB 1.x specific cruft would be a good way to learn the
>framework.
> 
> Questions?  Comments?  Flames?  Pull requests?  I am at your service.

Sounds great!

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Crowbar 2.0 Status Report

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> All,
> 
> I’m sorry to report that Join.Me did not manage to record the audio :/
> If you’d like to review the screen cast, it’s available 
> https://www.youtube.com/watch?v=OPWTI6EC-AE

Thanks.  Sorry to sound negative, but it seems to me that pretty much
every single call we lose the first 10 minutes or so due to audio
issues, and even when it works quite often I find the audio quality
poor.  Is there any chance of finding a more reliable solution than
join.me?  Or have I got the wrong end of the stick?

> I will grab Victor for a recasting of the demo and will send a link
> when we have a more complete version.

Having this would be a really nice bonus, although such a demo will
quickly become out of date, so IMHO I think it would be of more
lasting value if any spare time was first spent on documenting the new
architecture.  For example, the great info Victor sent out the other
day could be turned into real documentation, and a couple of simple
diagrams explaining how the annealer handles node-role state
transitions would be very useful in the long-term.  Actually this
could even be done by using a series of HTML tables interspersed with
text, to show how the states in the node-role matrix change over time
during an example deployment.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Crowbar 2.0 Status Report

[Adam Spiers]

michael_pitt...@dell.com (michael_pitt...@dell.com) wrote:
> I'm currently working on the devguide, and will merge this content end.
> I expect to have a pull request for some significant doc updates within a 
> week.

Awesome, thanks a lot Mike!

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Crowbar 2 Simulator / Test Jig Video

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> All,
> 
> John Terpstra and I spent a while going over how to use the Crowbar 2 test 
> server with the simulator to exercise the Test Jig.   These tools allow you 
> to play with Crowbar2 directly from your dev/build environment without having 
> to spin up additional VMs.
> 
> Video: https://www.youtube.com/watch?v=0ttU0V-jI9A

Cool, thanks.

> PLEASE CREATE NOTES: http://crowbar.sync.in/simulatorvideonotes 

Great idea.

> Note: I'm adding a video page/space on Crowbar Docs 
> https://github.com/crowbar/barclamp-crowbar/tree/master/doc

Why?  We already have

https://github.com/crowbar/crowbar/wiki/Videos
https://github.com/crowbar/crowbar/wiki/Introductory-Videos
https://github.com/crowbar/crowbar/wiki/Developer-Videos (strangely empty)

and IMHO the wiki is a much more suitable place for videos, because
they're not strongly coupled to a particular revision of code.  If a
list of videos goes in the repo, then git diff between branches will
show differences in the list of videos, which doesn't make any sense
to me.  Sorry to be picky, but proliferation of semi-duplicated
documentation seems to be a common problem with Crowbar in general,
so it'd be great to avoid making it worse.  Feel free to correct me if
I missed something.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Crowbar 2 Simulator / Test Jig Video

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> > Why?  We already have 
> > https://github.com/crowbar/crowbar/wiki/Videos 
> > https://github.com/crowbar/crowbar/wiki/Introductory-Videos 
> > https://github.com/crowbar/crowbar/wiki/Developer-Videos (strangely empty) 
> > and IMHO the wiki is a much more suitable place for videos, because they're 
> > not strongly coupled to a particular revision of code.  If a list of videos 
> > goes in the repo, then git diff between branches will show differences in 
> > the list of videos, which doesn't make any sense to me.  Sorry to be picky, 
> > but proliferation of semi-duplicated documentation seems to be a common 
> > problem with Crowbar in general, so it'd be great to avoid making it worse. 
> >  Feel free to correct me if I missed something.
> 
> Adam, that's a good point.  Here's my dilemma -> the notes from those videos 
> are documentation that's persisted.  I think that should be in the docs, not 
> on the wiki.  The videos are helpful to backstop the docs but age.  We need 
> to have a system that encourages the text to be written and I don't see that 
> from the wiki pages.

Totally agree - if the notes from the videos evolve into documentation
that is standalone and does not refer to the videos from which they
came, then the repo is the correct home for it.  I was just objecting
to the idea of a list of links to soon-to-be-outdated videos being
checked into the repo.  

If the above "evolution" happens in a single step, then the notes can
be checked directly into the repo as 1st class docs.  But another
valid workflow pattern is to make rough notes on the video in the
wiki, then once they are polished and de-coupled from the original
video they can be moved to the repo.  

Sounds like we are probably on the same page but I just misunderstood
your intention.

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Trello for Resolving Community Documentation Issues (Help request!)

[Adam Spiers]

Did anything happen with producing a useful Getting Started guide yet?
We're still haemorrhaging potential community members ...

23:50:23  Hi! I am testing out Crowbar and have downloaded
   the Crowbar Grizzly 1.6 Alpha iso from crowbar.zehicle.com
   Question: what is the default user/password?  Also, where do
   I find instructions on getting started? The Newbie guide on
   the wiki doesn't offer much help.
23:54:01  Help?  

Simon Jakesch (simon_jake...@dell.com) wrote:
> FYI,
> 
> I've revised the build instructions, I intend on tackling the Getting Started 
> Guide next.
> 
> Simon
> 
> 
> -Original Message-
> From: crowbar-bounces On Behalf Of Adam Spiers
> Sent: Friday, July 19, 2013 12:13 PM
> To: crowbar
> Subject: Re: [Crowbar] Trello for Resolving Community Documentation Issues 
> (Help request!)
> 
> Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> > Adam,
> > 
> > I agree on the concern about too many Trello's.  Right now the 2.0 
> > Backlog is not being managed.
> 
> Ah I see, is there a plan for when to start managing it again?
> 
> > My concern would be that people would not add 1.x doc issues to that 
> > backlog.
> 
> Well, there is also a 1.6 backlog board :-)
> 
> > I'm open to suggestions!
> 
> It's probably not so important to worry about which board these cards should 
> live on - the main thing is to actually address them.  The main problems 
> right now are a) that most of the doc tasks are unassigned and/or completely 
> neglected, and b) the documentation is utterly bewildering for newcomers ;-/
> 
> We need to prioritise fixing the first documentation which a newcomer to 
> Crowbar first encounters or would like to encounter, since the main objective 
> is to grow the community.  The first port of call is most likely 
> http://crowbar.github.io/ and I guess most people are likely to click on the 
> Find Out More button first which leads to:
> 
> http://crowbar.github.io/docs/getting-started/
> 
> Unfortunately AFAICS that page is currently useless, since it doesn't provide 
> any download links.  The first item listed is "Configuring the Network" - 
> hardly appropriate for the beginning of a quickstart guide!
> Even the 3rd item "Installing Crowbar" doesn't explain how to install 
> Crowbar.  Whilst glaring gaps such as these remain, I can't imagine the 
> Crowbar community ever growing :-/  So yes, a Docs Hack Day is much needed.
> 
> Thanks for being open to this discussion!!
> 
> ___
> Crowbar mailing list
> Crowbar@dell.com
> https://lists.us.dell.com/mailman/listinfo/crowbar
> For more information: http://crowbar.github.com/


___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

[Crowbar] "rescue Exception" considered harmful

[Adam Spiers]

*** PUBLIC HEALTH AND SAFETY ANNOUNCEMENT ***

I notice Crowbar has a lot of

  rescue Exception => e

clauses.  AFAIK, this is widely considered to be a bad idea:

  
http://stackoverflow.com/questions/10048173/why-is-it-bad-style-to-rescue-exception-e-in-ruby

Next time you encounter this, please consider either changing it to
rescue a much narrower scope within the Exception hierarchy, or (in
some cases) rewriting it to avoid the need to catch exceptions at all.

This announcement was prompted by observing a horrible bug in pebbles
where the *only* evidence that something went wrong was seeing
"undefined method `[]’ for nil:NilClass" in the flash.  Not a single
helpful stacktrace or error message in the logs :-(  I can't be sure
yet, but I suspect the guilty code is this:

  def save_node
...
begin
  ...
  @node.save
  true
rescue Exception=>e
  flash[:notice] = @node.name + ": " + t('nodes.list.failed') + ": " + 
e.message
  false
end
  end

That's quite evil, because it a) catches a huge range of exceptions
which it shouldn't, b) guarantees near-silent failure, and c)
eliminates any reasonable chance of debugging the failure.

Thanks for your attention :)

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] "rescue Exception" considered harmful

[Adam Spiers]

Adam Spiers (aspi...@suse.com) wrote:
> *** PUBLIC HEALTH AND SAFETY ANNOUNCEMENT ***
> 
> I notice Crowbar has a lot of
> 
>   rescue Exception => e
> 
> clauses.  AFAIK, this is widely considered to be a bad idea:
> 
>   
> http://stackoverflow.com/questions/10048173/why-is-it-bad-style-to-rescue-exception-e-in-ruby
> 
> Next time you encounter this, please consider either changing it to
> rescue a much narrower scope within the Exception hierarchy, or (in
> some cases) rewriting it to avoid the need to catch exceptions at all.
> 
> This announcement was prompted by observing a horrible bug in pebbles
> where the *only* evidence that something went wrong was seeing
> "undefined method `[]’ for nil:NilClass" in the flash.  Not a single
> helpful stacktrace or error message in the logs :-(  I can't be sure
> yet, but I suspect the guilty code is this:
> 
>   def save_node
> ...
> begin
>   ...
>   @node.save
>   true
> rescue Exception=>e
>   flash[:notice] = @node.name + ": " + t('nodes.list.failed') + ": " + 
> e.message
>   false
> end
>   end
> 
> That's quite evil, because it a) catches a huge range of exceptions
> which it shouldn't, b) guarantees near-silent failure, and c)
> eliminates any reasonable chance of debugging the failure.

I have made a start on fixing this for Pebbles:

  https://github.com/crowbar/barclamp-crowbar/pull/693

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] New names for NodeRole > suggesting "Tack"

[Adam Spiers]

Rob Hirschfeld (rob_hirschf...@dell.com) wrote:
> 
> Yes and no.  All the noderoles together make up the noderole graph, which by 
> itself does not care about deployments.  However, when a noderole is created 
> (and gets its initial configuration) and bound to the noderole graph, it is 
> always created in the context of a deployment, which determines what 
> configuration it will get and determines what noderoles it will be bound to 
> to satisfy the dependencies of the role it is binding to the node.
> 
> *   Node-role bindings (called noderoles for short -- please suggest a 
> better name for this!), which represent a specific instance of a role bound 
> to a node.  Noderoles have their own configuration in addition to the role 
> configuration at a deployment level and the default role configuration.
> What is the configuration that a node role owns?  Would this configuration be 
> user visible, or something that would be set by the barclamp associated with 
> the role?
> 
> I’m going to suggest “Tack” for this.   There are several other ideas (Nail, 
> Grain, Binding, etc).

I already suggested "assignment".  Since node roles are closely
related to deployments, IMHO it feels wrong to have one term (tack)
aligning with the building tools metaphor and the other (deployment)
not.  An assignment can intuitively be part of a deployment, but a
tack can't.  My £0.02 ...

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Re: [Crowbar] Branch from Pebbles, discussion kick-off (for OpenStack Havana work and other new dev)

[Adam Spiers]

Simon Jakesch (simon_jake...@dell.com) wrote:
> I know it's fun to come up with branch names, however, I don't think they're 
> very helpful to people that aren't involved on a day to day basis. Maybe I am 
> missing something, but why can't we just stick to version numbers. Pebbles 
> would be 1.x branch, we just released 1.6.0 and are going to release 1.6.1 
> soon. Both of those are children of the 1.6.x branch. The work on Crowbar 2 
> happens on the 2.x branch.
> In my opinion that strategy is a lot clearer than using code names, that just 
> means only insiders know how elefante, betty, fred, fledermaus, pebbles and 
> mesa align chronologically.

I sort of agree but I think it's fine to give each release a nickname
as long as it's also given a release number.  The number makes the
ordering clear to outsiders, and the nickname keeps insiders happy,
since assigning names seems to fit how most of our brains work
(presumably because we didn't evolve from cavemen who called each
other "1" / "2" etc.)  This double scheme seems to work very well with
Ubuntu, for example.  Although many other distributions do just fine
without the nicknames, of course :-)

BTW if we were sticking strictly to the family tree rules then Roxy is
the next generation from Pebbles so should be saved for 2.0, not a
minor 1.6.x release :-p  But we'll run out of Flintstones names pretty
soon either way ...

___
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/