cci-moc / moc-public Goto Github PK

Central repo for non-project specific information about the MOC

moc-public's Introduction

Massachusetts Open Cloud

Welcome to the main developer repository for the Massachusetts Open Cloud. You can find out more about the project including news, who is involved, public presentations, etc... here.

Code development

To get started on the development, start here. Then take a look at our workflow.

Our people

You can find some of the developers working on the project here!

Current projects

Hardware As A Service (HaaS): securely automating the provisioning and isolation of systems and networks in a multi-tenant data center
Openstack UI:
- adding extensions to Openstack's Horizon in order to accommodate a multi-provider marketplace
- introducing a "simple" mode for Horizon to support easy deployment and management of VMs
Openstack core: Adding the capability to handle multiple providers of individual services (like compute, object storage, etc).

Documentation

Documentation for the various MOC projects lives on Github in one of three places:

Projects having their own git repo will store longer-lived documentation (like design docs) within their own docs directory.
Longer-lived documents that do not pertain to a particular project under the CCI-MOC account will be placed in the moc-public repo. This could include things like design documents for functionality in repos that are not owned by MOC or papers.
Items that are less formal by nature (like meeting minutes, random notes, or project planning) are kept on the MOC Public Wiki.

moc-public's People

Stargazers

Watchers

Forkers

linzertorte tfhartmann mydaisy2 hoodsy ruoyu111 smahasankabir dkakkar bhpriyanka jsianard philipho11 vineethramakrishnan enterstudio enterstudios rvicentini01 laterdude bonomali

moc-public's Issues

Setup Cinder/Swift etc.

We want to be able to set up Cinder and Swift, as well as any other "extra" services.

Come up with a plan for Stateless compute nodes

We need to decide on an approach to investigate.

Demo head nodes don't use a production webserver for puppet.

The demo head nodes configured as in https://github.com/CCI-MOC/moc-public/wiki/Vlan-Head-Nodes are not currently using a production quality webserver for the puppetmaster.

We already have nginx installed for the boot-default cgi script; we should put puppet behind it as well.

Installing OC commands on mac not callable

When I download and run the commands to install the oc commands on macOS I can't call the commands from anywhere. I can only call the commands from the folder itself (i.e. ./oc --help).

Does anyone know how to fix this?

Partitioning in our ks.cfg is set up incorrectly

The ks.cfg used to create centos nodes in our test setup partitions the disks sub-optimally; / has less than 4GiB, whereas most of the space is allocated to /home. From the names of the volume groups, it looks like this was never intentional.

This is causing problems with e.g. uploading large images to glance.

changing the mailing list mentioned in wiki page

As we are changing the mailing list, the content in the wiki page should be updated as well.

Our REST API violates HTTP conventions.

Several of our API calls modify the database via a GET request. This shouldn't happen - GET is for information retrieval ONLY.

These calls should instead be POST or PUT requests, depending on the nature of the modification.

Migrate to quantum

Currently using nova-network, want to move over to quantum.

Migrate to fuel

We want to be using fuel instaed of packstack

Controller as VM

We want to be able to have our controller node be a virtual machine; We actually have this working, but want to make sure we can reproduce it.

Demo head nodes currently auto-sign puppet cert requests; we may want something more secure.

As stated in the title. We need to discuss how we want the head node to behave in this regard.

Short term development

get PXE boot going
test this

Fully puppetize headnode creation

We'd like to have a set of puppet modules that can be applied to a fresh ubuntu server install, yielding a usable head node. trying to keep track of changes made manually to the vms has proven unmanageable - this is what puppet is for.

Resource leaks in spl_init.py

there are numerous places in spl_init.py with code like:

for x in open(y):
    ...

When we do this, the opened files don't get closed until garbage collection happens. In this simple script it probably doesn't matter, but we should avoid it; if we forget and decide to put the code in a longer-running program this could be a problem - file descriptors are more limited than memory.

If the clock is set incorrectly on a node when kickstarting, it will not be corrected, and puppet will fail.

It would be nice if the install made sure the clock was right. This is currently affecting at least one of our nodes.

deb/rpm packages for moc tools

It would be a good idea to have deb/rpm packages for the various tools we've written. In theory, pulling from github works, but in practice it's hard to make sure everything is up to date. It would be good to be able to fold that work into updating the system in general.

We should also create a repo for these packages.

power_cycle script breaks on 12.04

power_cycle script breaks on ubuntu 12.04

It would seem that the version of python-requests that 12.04 provides does not have the requests.auth.HTTPDigestAuth method.

puppet manifests not installing openstack-nova-network on controller

For some reason, the rpm for openstack-nova-network isn't being installed on the control node by the puppet manifests we're using in conjunction with the head node based setup. This started happening after we relocated the test cluster - it seemed to be working fine beforehand.