Nexenta Edge Charms to deploy edge cluster

Bug #1515717 reported by ilya grafutko
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juju Charms Collection
Fix Released
Undecided
Nexenta OpenStack Developers

Bug Description

Nexenta Edge Charms that automation provisioning of Edge Management Node, Data Nodes, and Gateway Nodes

ilya grafutko (0-ilya)
Changed in charms:
assignee: nobody → ilya grafutko (0-ilya)
ilya grafutko (0-ilya)
Changed in charms:
assignee: ilya grafutko (0-ilya) → Nexenta OpenStack Developers (nexenta-systems)
Revision history for this message
Review Queue (review-queue) wrote : LXC Test Results: Nexenta Edge Charms to deploy edge cluster

This item has failed automated testing! Results available here http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/1469/

Revision history for this message
Review Queue (review-queue) wrote : AWS Test Results: Nexenta Edge Charms to deploy edge cluster

This item has failed automated testing! Results available here http://juju-ci.vapour.ws:8080/job/charm-bundle-test-aws/1454/

Revision history for this message
Review Queue (review-queue) wrote :

This item has failed automated testing! Results available here http://juju-ci.vapour.ws:8080/job/charm-bundle-test-aws/1817/

Revision history for this message
Charles Butler (lazypower) wrote :

Greetings Anton, I’ve taken some time to review the Nexenta NEDGE stack. This is a great first round submission. I’ve run across some points that will need to be addressed before the charms are ready to pass policy for the charm store. I encourage you to review the submission process documents to familiarize yourself with what we will be checking during the review: https://jujucharms.com/docs/stable/authors-charm-policy

** note about charm proof - Anything above an I: will need to be addressed. W:s and E:s are both treated as errors. This is confusing I know, please send a message to the juju mailing list (<email address hidden>) if you agree and wish this to be changed.

NedgeMGMT

This charm has some lint errors
https://gist.github.com/a04f1545b16a3627dcbf

When proofing the charm, there is a leftover README.example.md file leftover in the repository and can safely be deleted as there is a well formed README in the charm.

I gripped through the license and see you have included an EULA in the file, which is great. There also needs to exist some verbiage about the charm code being licensed under a suitable OSI approved license.

Cinder Nedge

this charm has some lint errors:
https://gist.github.com/bf6088cea347a49e04a5

proof output:

W: summary should be less than 72
W: no README file
E: config.yaml: options section is not parsed as a dictionary

Includes a juju-info relationship. These relationships are implicit in Juju, and the relation should not be named Juju-Info. Perhaps the following is a valid candidate for replacement?

cinder-host:
  interface: juju-info
  scope: container

it also appears that you left in some of the boilerplate metadata. I’ve proposed some updates, left the comment above about the relationship, and proposed some proof cleanups. Its not 100% clean but should get you much closer 😃

Nedge-swift-gw
This charm has some lint errors
https://gist.github.com/e90234057202f8b9a903

Nedge:
charm proof
W: no copyright file

Looks like we are missing the copyright file, each charm must be licensed under an OSD approved license.
https://jujucharms.com/docs/stable/authors-charm-policy

this charm has some lint errors:
https://gist.github.com/fb389568fad15d20aa34

nedge-cinder-gw

This charm has some lint errors:
https://gist.github.com/71acbb0319348b28d333

I'm going to move the status of this bug to "incomplete"

Once you have addressed the above review comments, please move the status of the bug to "fix committed" and someone will be along shortly to give you another review.

ou have any questions/comments/concerns about the review contact us in #juju on irc.freenode.net or email the mailing list <email address hidden>, or ask a question tagged with "juju" on http://askubuntu.com.

Changed in charms:
status: New → In Progress
Revision history for this message
Anton Skriptsov (anton-skriptsov) wrote :

1. CINDER-NEDGE charm

Looks like I can't remove this section

requires:
  juju-info:
    interface: juju-info
    scope: container

If I do it "charm proof" show me error:
    E: subordinates must have at least one scope: container relation

2. Right now I have only one lint error "E402 module level import not at top of file"
   And this error appears in my module and native unit_tests template
   unit_tests/test_actions.py:10:1: E402 module level import not at top of file

    # allow importing actions from the hooks directory
    sys.path.append(resource_filename(__name__, '../hooks'))
    import actions

    My module import some methods from charmhelpers and how I can avoid this error?

Revision history for this message
Review Queue (review-queue) wrote :

This item has failed automated testing! Results available here http://juju-ci.vapour.ws:8080/job/charm-bundle-test-aws/2142/

Revision history for this message
Chris Holcombe (xfactor973) wrote :

+1 lets land this!

Changed in charms:
status: In Progress → Fix Committed
Revision history for this message
Charles Butler (lazypower) wrote :
Download full text (6.2 KiB)

nedge-swift-gw
perhaps a missing relation in the bundle? It only has relations to keystone and nedge-mgmt.. How will Openstack use this object storage?
 README, seems like a leftover paste "You can then deploy nedge cluster with cinder gateway by simple doing"..
Security - configurationSteps/utils.py wgets neadm and nedeploy from arbitrary resources that are not being cryptographically verified. This violates charm store policy. There are charmhelpers available to perform these steps for you such as the charmhelpers.fetch package which offers install_remote. This allows you to specify a payload url (https://somewhere.com/mything.tgz) and the associated sha1sum, and have it installed on your behalf if the SHA1 and the payload match. This mitigates man in the middle attacks, and ensures the end user is receiving the intended payload the charm will fetch if not present in `files/ne*`
Security - utils/configure_user is actively dismantling SSH security on the host by enabling remote root login w/ a password. This seems likely dangerous if ever compromised. There are defaults provided in line which provide an attack vector: - user: ‘nexenta’, and password=’$1$kh4S5TnK$0NKxf09T3TNj.W3ejTgGT1’

cinder-nedge
Simple standup tests are fine for today, but future improvements include verification of ISCSI driver on host.
hooks/configurationSteps/settings.py - Why is none of this configurable in config.yaml? Static config is fine, but increases your maintenance burden that users can circumvent themselves by exposing the installation version as a config option.
Security - configurationSteps/utils.py wgets neadm and nedeploy from arbitrary resources that are not being cryptographically verified. This violates charm store policy. There are charmhelpers available to perform these steps for you such as the charmhelpers.fetch package which offers install_remote. This allows you to specify a payload url (https://somewhere.com/mything.tgz) and the associated sha1sum, and have it installed on your behalf if the SHA1 and the payload match. This mitigates man in the middle attacks, and ensures the end user is receiving the intended payload the charm will fetch if not present in `files/ne*`
Security - utils/configure_user is actively dismantling SSH security on the host by enabling remote root login w/ a password. This seems likely dangerous if ever compromised. There are defaults provided in line which provide an attack vector: - user: ‘nexenta’, and password=’$1$kh4S5TnK$0NKxf09T3TNj.W3ejTgGT1’

nedge-cinder-gw
Simple standup tests are fine for today, but future improvements include verification of configuration for nedge-node, adding/removing relations and verifying behavior of charm (does it go into maintenance mode?) reboot the host and does the service survive a reboot? - just some suggestions of what to test.
License - Contains the EULA for the Nexenta NEDGE software, which is great, but should really contain an OSI approved license clearly stating that the charm itself is OpenSource. - https://opensource.org/licenses - is a listing of some of the most popular open source licenses for you to choose from.
Security - configurationSteps/utils.py wgets...

Read more...

Changed in charms:
status: Fix Committed → In Progress
Changed in charms:
status: In Progress → Fix Committed
Changed in charms:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.