[Crowbar] one-shot barclamps

[Sascha Peilicke]

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.

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.

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".

It will be very likely that we will have more one-shot barclamps in the 
future (e.g. evacuate-compute-node), therefore I'd like to get some 
feedback before going further in any direction.


[1] https://github.com/cookbooks/one-shot/blob/master/recipes/default.rb
[2] https://gist.github.com/saschpe/5763924
[3] 
https://github.com/SUSE-Cloud/barclamp-updater/blob/master/crowbar_framework/app/models/updater_service.rb#L41
-- 
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

___
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] one-shot barclamps

[Judd Maltin]

Hi Sascha and Adam,

Adam's on the right track with the flag to exit a recipe if it's "one shot."

We do have a script in /opt/dell/bin called on-node, which will
probably also do what you like.

The larger issue, and especially for Crowbar 2.0, is the very nature
of one-shot vs. continuous, eventual convergence.  There be some
pretty severe demons here once you get into any level of complex
system interdependence. This is a topic we'll be expanding on in the
orchestration design for Crowbar 2.0, hopefully providing some sane
primitives.

I'd be eager to continue fleshing out these ideas on the Community Design call.

-judd



On Wed, Jun 12, 2013 at 7:17 AM, Adam Spiers  wrote:
> 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/



-- 
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] public subnet change

[Bernhard M. Wiedemann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I was wondering what was the reason for this change

https://github.com/crowbar/barclamp-network/commit/a85bb03d7196468c333a58708b42d106d77eaead

but unfortunately the commit message does tell this.


just stumbled over this because our test scripts assume the older
network layout.
I would like to keep our test-script simple and also for users it
would be an advantage to remain consistent with the old version unless
there is a compelling reason to switch.

Ciao
Bernhard M.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlG4e+wACgkQSTYLOx37oWRWiwCfT+MphjS1xqKthAHaqsb5ihs8
YogAoIQMWVwFv6rCi320LT5c6LrVZTyt
=um8g
-END PGP SIGNATURE-

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

Re: [Crowbar] public subnet change

[Arkady_Kanevsky]

Bernard,
192.168.122.1 is used by default by KVM for deployed VM.
I run it on virtual box, but the same issue is on qemu/kvm  on linux.
Thus, the easiest solution was NOT to use 122.x IP address range.
Arkady

Original Message-
From: Bernhard M. Wiedemann [mailto:bwiedem...@suse.de] 
Sent: Wednesday, June 12, 2013 8:47 AM
To: Kanevsky, Arkady
Cc: crowbar
Subject: public subnet change

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I was wondering what was the reason for this change

https://github.com/crowbar/barclamp-network/commit/a85bb03d7196468c333a58708b42d106d77eaead

but unfortunately the commit message does tell this.


just stumbled over this because our test scripts assume the older network 
layout.
I would like to keep our test-script simple and also for users it would be an 
advantage to remain consistent with the old version unless there is a 
compelling reason to switch.

Ciao
Bernhard M.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlG4e+wACgkQSTYLOx37oWRWiwCfT+MphjS1xqKthAHaqsb5ihs8
YogAoIQMWVwFv6rCi320LT5c6LrVZTyt
=um8g
-END PGP SIGNATURE-

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

Re: [Crowbar] public subnet change

[Bernhard M. Wiedemann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/12/2013 03:51 PM, arkady_kanev...@dell.com wrote:
> Bernard, 192.168.122.1 is used by default by KVM for deployed VM. I
> run it on virtual box, but the same issue is on qemu/kvm  on
> linux. Thus, the easiest solution was NOT to use 122.x IP address
> range. Arkady

actually, both VirtualBox and kvm seem to use 10.0.2.15 as default VM
IP in NAT mode (and whatever outside DHCP provides in bridge mode)

http://wiki.libvirt.org/page/VirtualNetworking
mentions 192.168.122.x/24
but the actual default value in virt-manager is 192.168.100.0/24

Ciao
Bernhard M.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlG4f8gACgkQSTYLOx37oWQOuACfQFmKQhQ6lNwY/+DkZIvZ1VsH
3bkAn0j9qf5P7UmAYOj5er5/1UHzKPZg
=mCIG
-END PGP SIGNATURE-

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

[Crowbar] Is the tempest smoketest supposed to work?

[Ralf Haferkamp]

Hi,

I just ran "/opt/dell/bin/smoketest tempest" on a built that had the following
pull requests merged:

https://github.com/crowbar/barclamp-glance/pull/82
https://github.com/crowbar/barclamp-quantum/pull/37
https://github.com/crowbar/barclamp-glance/pull/85
https://github.com/crowbar/barclamp-nova/pull/158
https://github.com/crowbar/barclamp-cinder/pull/27
https://github.com/crowbar/barclamp-cinder/pull/30
https://github.com/crowbar/barclamp-nova/pull/158

Everything seemed to work well apart from the minor issue mentioned in:
https://github.com/crowbar/barclamp-quantum/pull/37#discussion-diff-4654400

After "fixing" that. All smoketest up to tempest were executed successfully.
The tempest test however completely failed. It just repeatedly logged something
like this for all testcases:
==
ERROR: Failure: AttributeError ('module' object has no attribute
'WithAttributes')
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 390, in
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 39, in
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 86, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/opt/tempest/tempest/tests/volume/test_volumes_snapshots.py", line 15,
in 
from tempest.tests.volume import base
  File "/opt/tempest/tempest/tests/volume/base.py", line 24, in 
import tempest.test
  File "/opt/tempest/tempest/test.py", line 52, in 
testtools.testcase.WithAttributes,
AttributeError: 'module' object has no attribute 'WithAttributes'

Is this a know problem? It seem completely unrelated to any of the above pull
requests.

-- 
regards,
Ralf

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

Re: [Crowbar] Is the tempest smoketest supposed to work?

[Ralf Haferkamp]

On Wed, Jun 12, 2013 at 04:55:08PM +0200, Ralf Haferkamp wrote:
> Hi,
> 
[..]
> After "fixing" that. All smoketest up to tempest were executed successfully.
> The tempest test however completely failed. It just repeatedly logged 
> something
> like this for all testcases:
> ==
> ERROR: Failure: AttributeError ('module' object has no attribute
> 'WithAttributes')
> --
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 390, in
> loadTestsFromName
> addr.filename, addr.module)
>   File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 39, in
> importFromPath
> return self.importFromDir(dir_path, fqname)
>   File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 86, in
> importFromDir
> mod = load_module(part_fqname, fh, filename, desc)
>   File "/opt/tempest/tempest/tests/volume/test_volumes_snapshots.py", line 15,
> in 
> from tempest.tests.volume import base
>   File "/opt/tempest/tempest/tests/volume/base.py", line 24, in 
> import tempest.test
>   File "/opt/tempest/tempest/test.py", line 52, in 
> testtools.testcase.WithAttributes,
> AttributeError: 'module' object has no attribute 'WithAttributes'
> 
> Is this a know problem? It seem completely unrelated to any of the above pull
> requests.
I am pretty sure now that this is a problem with the tempest barclamp.
Upgrading python's testtools to the latest release manually on the tempest node
actually fixed the problem for me. It seems that tempest nowadays requires
testtools >= 0.9.30.

See also:
https://bugs.launchpad.net/ubuntu/+source/python-testtools/+bug/1174630

-- 
regards,
Ralf

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

[Crowbar] Dell release branch mesa-1.6

[Arkady_Kanevsky]

Team,
Dell had branch off mesa-1.6 off Pebbles.

Reiterating, Pebbles is open for merges since database barclamp changes has 
completed.
Arkady

[cid:image001.jpg@01CE676F.46755B10]


Arkady Kanevsky, Ph.D.

Director of SW Development

Enterprise Solution Group

+1 512 723 5264 | arkady_kanev...@dell.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

[Arkady_Kanevsky]

#7 is done.
BIOS open sourcing is still going on but will be done on pebbles when ready.
Arkady

From: crowbar-bounces On Behalf Of Kanevsky, Arkady
Sent: Monday, June 03, 2013 3:17 PM
To: crowbar
Subject: [Crowbar] status and merge orchestration

Team,
There are a lot of moving parts and we need to avoid stepping over each other.
We have 6 independent chunks of work:

1.   Open sourcing Dell RAID barclamp

2.   Open sourcing Dell BIOS barclamp

3.   Conversion of all OS barclamp to use database one and deprecating 
MySQL one.

4.   Victor bug fix for "disk allocation to barclamps"

5.   SUSE pulls for bug fixes and features

6.   Other bug fixes and functionality from all.


Here is the order I propose we follow.


1.   Dell RAID barclamp is added to pebble.

2.   Hadoop release branch is cut from Pebbles

3.   OS barclamps are all updated to use database one and my SQL barclamp 
is deprecated from Pebbles.

4.   SUSE review "disk allocation to barclamps" pulls (8).

5.   If they are OK then we will merge it in. If not then we will resolve 
it.

6.   Irrespective of 4-5, DELL BIOS barclamp is added to Pebbles

7.   Once 1,3,6 are done Dell OS release will be cut off Pebbles. If 5 is 
done even better.

8.   Review and Merge SUSE pulls to Pebbles. We can done some of these 
before 6 and 7 after John review but not before 3.

9.   Review and Merge other pulls against Pebbles.

10.   Cherry pick bug fixes into Pebbles for 2 Dell release branches.

1 & 2 will be done today.
3 will be done tomorrow or maybe even tonight.

Please, follow about order.
As always, please, comment on crowbar  mail reflector.

Thanks,
Arkady

[cid:image001.jpg@01CE676F.B9002BB0]


Arkady Kanevsky, Ph.D.

Director of SW Development

Enterprise Solution Group

+1 512 723 5264 | arkady_kanev...@dell.com



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

Re: [Crowbar] Is the tempest smoketest supposed to work?

[Arkady_Kanevsky]

I guess, you cannot run tempest for now on Ubuntu till canonical updates 
library.


-Original Message-
From: crowbar-bounces On Behalf Of Ralf Haferkamp
Sent: Wednesday, June 12, 2013 11:24 AM
To: crowbar
Subject: Re: [Crowbar] Is the tempest smoketest supposed to work?

On Wed, Jun 12, 2013 at 04:55:08PM +0200, Ralf Haferkamp wrote:
> Hi,
> 
[..]
> After "fixing" that. All smoketest up to tempest were executed successfully.
> The tempest test however completely failed. It just repeatedly logged 
> something like this for all testcases:
> ==
> ERROR: Failure: AttributeError ('module' object has no attribute
> 'WithAttributes')
> --
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 390, in 
> loadTestsFromName
> addr.filename, addr.module)
>   File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 39, 
> in importFromPath
> return self.importFromDir(dir_path, fqname)
>   File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 86, 
> in importFromDir
> mod = load_module(part_fqname, fh, filename, desc)
>   File "/opt/tempest/tempest/tests/volume/test_volumes_snapshots.py", 
> line 15, in 
> from tempest.tests.volume import base
>   File "/opt/tempest/tempest/tests/volume/base.py", line 24, in 
> import tempest.test
>   File "/opt/tempest/tempest/test.py", line 52, in 
> testtools.testcase.WithAttributes,
> AttributeError: 'module' object has no attribute 'WithAttributes'
> 
> Is this a know problem? It seem completely unrelated to any of the 
> above pull requests.
I am pretty sure now that this is a problem with the tempest barclamp.
Upgrading python's testtools to the latest release manually on the tempest node 
actually fixed the problem for me. It seems that tempest nowadays requires 
testtools >= 0.9.30.

See also:
https://bugs.launchpad.net/ubuntu/+source/python-testtools/+bug/1174630

--
regards,
Ralf

___
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] Is the tempest smoketest supposed to work?

[Ralf Haferkamp]

Hi,

On Wed, Jun 12, 2013 at 02:27:11PM -0500, arkady_kanev...@dell.com wrote:
> I guess, you cannot run tempest for now on Ubuntu till canonical updates 
> library.
Ok, thanks for clarifying. I guess then I can interpret the test results as
succeeded :).

regards,
Ralf

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

Re: [Crowbar] [barclamp-quantum] Removed vlan option from quantum networking mode selector [1/1] (#45)

[Vincent Untz]

I don't think we should remove it in pebbles if it doesn't work (unless
we also believe the option doesn't make sense in general).

Do we have more details about the issue? Is there a bug opened about it?

Vincent

Le mercredi 12 juin 2013, à 12:45 -0700, cdearborn a écrit :
> Merging to pebbles/master
> 
> This change removes the vlan pick from the quantum add/edit form Networking 
> Mode selector.
> This is being done because vlan mode is not currently working.
> 
> 
>  .../barclamp/quantum/_edit_attributes.html.haml|2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Crowbar-Pull-ID: 8645ccdddfeee8d92c8e372ce0cb20056c9c95b1
> 
> Crowbar-Release: pebbles
> You can merge this Pull Request by running:
> 
>   git pull https://github.com/cdearborn/barclamp-quantum 
> pull-req-release-pebbles-master-8645ccdddfeee8d92c8e372ce0cb20056c9c95b1
> 
> Or you can view, comment on it, or merge it online at:
> 
>   https://github.com/crowbar/barclamp-quantum/pull/45
> 
> -- Commit Summary --
> 
>   * Remove vlan pick from networking mode selector
> 
> -- File Changes --
> 
> M crowbar_framework/app/views/barclamp/quantum/_edit_attributes.html.haml 
> (2)
> 
> -- Patch Links --
> 
> https://github.com/crowbar/barclamp-quantum/pull/45.patch
> https://github.com/crowbar/barclamp-quantum/pull/45.diff
> 

-- 
Les gens heureux ne sont pas pressés.

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