Comment 8 for bug 1515717

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 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-mgmt
simple standup test is fine, but it would be nice to see some verification of configuration, eg: configure with nodocker=false and verify it pulled in docker + stood up the management component
Solid readme and description of the options :thumbsup:
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’

With some refactoring - i feel that you can abstract the library you’ve built in configurationSteps, update the security vulnerabilities in one place and profit by packing a python wheel with your charm that you can then track as a shared library.

Just a suggestion though, however - the copy/paste code will need to be corrected before the charms can pass a policy review. Overall the charms have come a long way, i’m happy to see the progress made here, and look forward to approving these charms soon once the minor issues have been resolved.

Great work Anton! Cheers.

Thanks again for the submission. I'm going to change status of this bug to "in progress" and when you're ready switch merge status to 'needs review' and someone will be along shortly to review your work.

If you 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.