Giter Site home page Giter Site logo

grnet / synnefo Goto Github PK

View Code? Open in Web Editor NEW
132.0 32.0 45.0 34.63 MB

Synnefo is open source cloud software, used to create massively scalable IaaS clouds.

License: GNU General Public License v3.0

Python 75.27% Makefile 0.23% Shell 0.25% Ruby 0.01% CSS 4.63% JavaScript 16.18% HTML 3.43% Mako 0.01% DIGITAL Command Language 0.01%

synnefo's Issues

Pithos + Archipelago, are flooding file space without restrict.

Fresh installation (install guide) version 0.18rc, pithos + archipelago + nfs share file space.

One user in system.
Limiting 1G for object storage.

Current size on files on nfs - ~0 bytes.

User, through kamaki or web interface, has uploaded files on 500-900Mb, by turn. All files are different. Each by turn was removed after each uploading.

Now nfs size of all files ~2G in directory of blocks.
In DB - user doesn't use files.

HOw to stop this flood??? How to limit or erase objects of user on level acrhipelago or pithos according to limiting in DB???

Seems, It is more then bug, it is big problem. Do you have variants of solving?

0.19: stale dependency on ganeti2?

I'm trying out the packages in snf-dev-0.19

The snf-cyclades-gtools package has a dependency on "ganeti2":

root@nuc1:~# apt-cache show snf-cyclades-gtools | grep Depends
Depends: python, python-daemon, python-puka, python-pyinotify, python-setproctitle, python:any (<< 2.8), python:any (>= 2.7.5-5~), snf-common (= 0.19~dev13534+df.c16e596.718678a-1~jessie), ganeti2, snf-network

However, in Jessie the package "ganeti2" has been renamed to "ganeti". Indeed, snf-ganeti replaces both of these:

root@nuc1:~# apt-cache show snf-ganeti | grep Replaces
Replaces: ganeti, ganeti-haskell, ganeti-htools, ganeti2 (<< 2.7.0-2)
Replaces: ganeti, ganeti-haskell, ganeti-htools, ganeti2 (<< 2.7.0-2)

I wonder if the snf-cyclades-gtools package dependency should be on "ganeti" or "snf-ganeti", not "ganeti2"?

(Actually I'd rather it was a soft 'recommends' because I'd like to be able to try it with other versions of ganeti, but that's a side point)

Cyclades helpdesk tool - IPv6 depiction/search

Using the "Helpdesk" tool in Cyclades we noticed that it does not provide any information when providing the IPv6 of a VM.

This is possibly an omission since we can get the functionality for IPv4 IPs.

snf-ganeti-eventd doesn't automatically ensure it's running on the latest master node

Redacted email thread explaining the issue:

[me] wrote:
While working on a wrapper tool for automating rolling reboots
..[snip]..
after a master-failover, snf-ganeti-eventd needs to be manually stopped on the old
master and started on the new master. This is not such an issue when manually
wrangling a cluster, but becomes a show-stopper when automating the process
..[snip]..
synnefo is not being an entirely "transparent" layer on Ganeti.

[Synnefo dev] wrote:
you are right, currently you have to manually start the snf-ganeti-eventd daemon in
the new Ganeti master. As you mention, because master-failover is not done
automatically, this is not a big issue.

The problem is that master-failover does not run as a Ganeti job and Ganeti does
not provide a hook to run in this case.
..[snip]..

Can you create an issue to track the progress of this feature ?

Also, I should mention that snf-ganeti-eventd can run in more than one
master-candidate nodes, which however results in more messages to the
RabbitMQ broker.

VM graphs only display the first interface of a VM

VM graphs displayed in Cyclades (Single mode) only display the first network interface of a VM. If a VM has multiple interfaces, and synnefo by default creates one interface for IPv6 and second one for IPv4, then only one graph is shown.

Since most VMs use the first interface for IPv6 and the second for IPv4, the majority of traffic is currently not displayed.

Stale Snapshots

Issue

In case snapshot creation fails after the snapshot has been registered to Pithos,
e.g. because the Ganeti job failed, the state of the snapshot will remain forever
as 'unavailable'. The snapshot will appear in the Pithos UI, but the user will
get an error (403) when trying to download the snapshot.

Proposed solution

To fix this issue, snf-dispatcher will be updated to use the PithosBackend in order
to set the state of the snapshot in ERROR state. In this case, Pithos will return an
error (400) indicating that the snapshot is in ERROR state, and Pithos UI will properly
display the snapshot as broken.

Required Steps

  • Add ERROR as a possible state for a Pithos object and handle error messages in such objects
  • Add a method in PithosBackend that will be used by snf-dispatcher in order
    to update the state of a Pithos object.
  • Update Pithos webclient to properly display objects in ERROR state.

Create tool for checking Cyclades updath path

Add a tool to check the state of the Cyclades update path:
Ganeti -> snf-ganeti-eventd -> RabbitMQ -> snf-dispatcher

The tool will have to check that snf-dispatcher can
receive messages from the snf-ganeti-eventd daemon
that is running in each Ganeti cluster.

Document API changes regarding account/project quotas

With the introduction of the updated Projects in Synnefo 0.16, there have
been some undocumented API changes and no updating of the Pithos WebClient app.

Changes regarding the API, i.e., the use of x-account-policy-quota and
x-account-policy-quota-UUID should both be documented in the API guide
and the Changelogs.

Moreover, the Pithos WebClient app should be updated to reflect the above
changes, because as it stands now, in most cases it will display invalid quota
values.

Lack of explanation in image-related 404 error responses

When requesting details for a non-existing image trough the API, the 404 error lacks an explanation.

This is not the case with other cyclades 404 errors, e.g. a server-related 404 will contain something like "server 9999 not found" and the same holds for networks, flavors, ips, etc.

To reproduce the issue:

Assume the image id 9999 does not exist.
Try the following:

$ kamaki image info 9999 -v -o log_data=on
> HEAD https://example.com/image/1.0/images/9999
> [...]
< 404 NOT FOUND
(empty body)

Similarly with compute/image API:

$ kamaki imagecompute info 9999 -v -o log_data=on
> GET https://example.com/compute/v2.0/images/9999
> [...]
< 404 NOT FOUND
< {"itemNotFound": {"message": "", "code": 404, "details": ""}}

CentOS-7 python provides python-argparse version >= python-argparse from synnefo repository.

Hi,

tested on the centos7 image provided on okeanos-global.grnet.gr

# cd /etc/yum.repos.d &&  curl -O http://download.opensuse.org/repositories/home:/GRNET:/synnefo/CentOS_7/home:GRNET:synnefo.repo
# yum install snf-image-creator
...
# /usr/bin/snf-image-creator
Traceback (most recent call last):
  File "/usr/bin/snf-image-creator", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 3007, in <module>
    working_set.require(__requires__)
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 728, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 626, in resolve
    raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: argparse
# yum install python-argparse
-> snf-image-creator works as expected

Cause:
python-argparse from home_GRNET_synnefo is version 1.2.1-6.2
but python-argparse is also provided by python...

# yum provides python-argparse
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
python-2.7.5-48.el7.x86_64 : An interpreted, interactive, object-oriented
                           : programming language
Repo        : file-base
Matched from:
Provides    : python-argparse = 2.7.5-48.el7

Stale RRD files break the network stats

The grapher of snf-stats-app computes the average network traffic for all
interfaces of the VM in order to produce the network graph. Collectd generates
a separate RRD file for each network interface, and then snf-stats-app is
using these RRD files in order to calculate the average traffic.

The problem is that when an interface gets removed the corresponding RRD file
is never removed. These stale RRD files seem to cause problem in the
calculation of the average network traffic.

This easy can easily be observed by watching the weekly network graph while
adding and removing a network interface.

pithos: Problem with tags on pithos files

If someone tries to rename the name field of a tag using the character "" a new tag is automatically created i.e. the renaming of tag "aaaa" to "aa\aa" leads to a new tag creation

Additionaly, someone needs to clear his browser cache so that removed tags are indeed removed from the user's UI

vm stuck in rebooting state

The 'REBOOT' API state for a VM is derived from an 'OP_INSTANCE_REBOOT' Ganeti job which has been reported as in progress. Because the reconciliation mechanism does not clear any fields related to Ganeti jobs, a VM may remain stuck in the 'REBOOT' state forever.

[RFC] Add support for multiple databases

Overview

This RFC document tackles the issue of multiple databases in Synnefo. In the first section, we explain what is the current situation and what limitations it poses. Next, we proceed with an overview of existing Django mechanisms that are used to handle multiple databases and finally, we present the design and implementation of the proposed solution.

Current situation and limitations

Synnefo is designed for installation in an arbitrary number of nodes. Usually, in multi-node installations, the administrators can assign Synnefo components to specific nodes for redundancy, security or performance reasons. This logic also applies to the databases used by Synnefo, which in production environments are usually installed in separate nodes.

Currently, the suggested way of registering a remote database for a Synnefo node is to edit the 10-snf-webproject-databases.conf file and add a "default" database entry:

DATABASES = {
    'default': {
         # 'postgresql_psycopg2', 'postgresql','mysql', 'sqlite3' or 'oracle'
         'ENGINE': 'django.db.backends.postgresql_psycopg2',
         # ATTENTION: This *must* be the absolute path if using sqlite3.
         # See: http://docs.djangoproject.com/en/dev/ref/settings/#name
         'NAME': 'snf_apps',
         'USER': 'synnefo',                      # Not used with sqlite3.
         'PASSWORD': 'example_passw0rd',         # Not used with sqlite3.
         # Set to empty string for localhost. Not used with sqlite3.
         'HOST': '203.0.113.1',
         # Set to empty string for default. Not used with sqlite3.
         'PORT': '5432',
    }
}

So, if we had four nodes, we could do the following:

  • Install the Cyclades database in Node 1.
  • Install the Astakos database in Node 2.
  • Install the Cyclades app in Node 3.
    • Also, register the Cyclades database of Node 1 as "default".
  • Install the Astakos app in Node 4.
    • Also, register the Astakos database of Node 2 as "default".

and that would work perfectly.

However, what would happen if the administrator wanted to install Astakos and Cyclades in the same node? In this case, this node would need to have access to two remote databases, which is not possible if we use only one database in the settings. Thus we need a way of managing multiple databases.

Django database routing 101

Django has introduced the notion of "multiple databases" in version 1.2. You can find detailed documentation on this subject for Django 1.4 here. In the following paragraphs, we'll try to briefly explain how Django handles multiple databases. For a more in-depth explanation, we'd suggest you take a look at the docs.

Multiple databases

In order to have multiple databases, we need to add extra ones in the DATABASES dictionary of Django settings, like so:

DATABASES = {
    'default' : {...}
    'db1': {...}
    'db2': {...}
}

Note1: Django 1.4 always needs a database called "default", so we can't have a database dictionary with only "db1" and "db2" as entries.
Note2: Django does not provide cross-database relations. This means that if a model uses a field of another model as its foreign key, then both models must be in the same database.

Automatic database routing

Having multiple databases means that we need a way to select a database for operations on a model. To assist us in this task, Django suggests using database routers. Now, simply put, database routers are Python classes that have methods which can be called by Django when it needs to operate on a model.

There are four router class methods that Django 1.4 defines:

  1. db_for_read: Expects a model and returns a database to read from.
  2. db_for_write: Expects a model and returns a database to write to.
  3. allow_relation: Expects two models and decides if these two models can point to each other with foreign keys
  4. allow_syncdb: Decides if a model can be synced to a given database.

Moreover, we need a way to enable these routers. To do this, Django provides the DATABASE_ROUTERS list setting. DATABASE_ROUTERS is a list of stringified paths to the router classes, e.g. "path.to.my.router.MyRouter1", "path.to.my.router.MyRouter2". The order is important, as the routers are processed in the order they are listed. This is the same logic that is used in urls.py, so most should be familiar with it.

Finally, if no router has taken a decision, the django falls back to its default routing scheme, e.g. what you would expect if you had only one database.

Note1: Django specifies that not all of the four methods need to exist. If one does not exist, it will continue with the next router.
Note2: A router may choose not to take a decision, e.g. because it knows nothing about a model. In this case, it can return None, and Django will continue with the rest of the routers.

Manual database selection

Django also has a handy "method" called using. It applies to a single Django operation (save/delete/get) and takes as a single argument an existing database. For more information about using, we suggest you take a look at the Django documentation.

Proposed routing scheme

Basic goals

The first goal is to provide the administrator with maximum elasticity. This means that if the administrator wants to split the databases in any imaginable way, the software should offer a basic set of tools to do so.

The second goal is to provide the necessary logic to warn the administrator when he/she attempts an unreasonable setup (e.g. due to cross-database relations).

The third goal is to allow and encourage the power user to plug routers of its own, if he/she uses an exotic database setup.

The fourth and final goal is to do all the above with as few changes as possible :-).

Design

We believe that the right way to go is with database routers. The alternative of using is not flexible enough and it requires to rewrite our codebase or provide custom QuerySets.

So, we suggest that each app defines its own routers. These routers, when queried about one of the app models, should return the appropriate database. Routers should be disabled by default and to enable them, the administrator will need to add them in the DATABASE_ROUTERS list. An interesting feature of this approach is that the administrator can add custom routers, therefore allowing any database setup (as always, within reason).

Implementation details

  1. In the top directory of the cyclades, astakos and pithos apps, we add a routers.py file.

  2. In this file we import the installed_apps setting of the specific app, as well as the global DATABASES setting.

  3. The database router class has the following simple skeleton (you can replace cyclades with pithos or astakos):

    def db_for_read(model):
def db_for_write(model):
    find the app of this model
    if app not in installed_apps:
        return None

    if 'cyclades' in DATABASES:
        return 'cyclades'
    else
        return None

def allow_relation(model1, model2):
    find the apps of the models
    if none of the apps in installed_apps
        return None
    elif both apps in installed_apps:
        return True
    else:
        return False

def allow_syncdb(db, model):
    find the app of this model
    if app not in installed_apps:
        return None

    if 'cyclades' in DATABASES: # We sync only in 'cyclades'...
        if db is 'cyclades':
            return True
    elif db is 'default': # ...unless they don't exist, so we use the defaults
        return None
    return False

  4. On 10-snf-webproject-databases.conf, we add a DATABASE_ROUTERS empty list and in the comments we list the available databases as well as the databases they expect to operate on:

    # Available databases:
# 'synnefo.routers.CycladesRouter':
#     Operates on 'cyclades' database, falls back on 'default'
# 'astakos.routers.AstakosRouter':
#     Operates on 'astakos' database, falls back on 'default'
# 'pithos.routers.PithosRouter':
#     Operates on 'pithos' database, falls back on 'default'
DATABASE_ROUTERS = []

This way, if the database setup is typical, the administrator doesn't need to configure anything. Even if a router is added without a change in DATABASES, the router will fall back to the default database. For more advanced database setups, the user will be able to add the necessary routers in the DATABASE_ROUTERS list, as well as the new databases in the DATABASES list. Finally, for exotic database configurations, the power user can do just about anything using custom routers.

Log all stdout/stderr for snf-manage invocations

Log all stdout and stderr output of every invocation of snf-manage, on unique filename under /var/log/synnefo.

Proposal: Combine timestamp, command name, and PID to form unique name, e.g.: 20140120113432-server-modify-4564, where "4564" was the PID.

Do it globally, for all management commands, in snf-django_lib.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.