Re: [Openstack] Floating IP in OpenStack API

[Mark Washenberger]

Eldar,
 
I'm having some trouble finding the diff for your implementation of approach 
#1. Any chance you can share it on the list?
 
Thanks
 
"Erik Carlin"  said:

> Cool.  Got it.  Floating IPs or what Amazon calls Elastic IPs.  How are you
> solving the cross L2 problem?
> 
> Erik
> 
> Sent from my iPhone
> 
> On Apr 15, 2011, at 7:28 PM, "Eldar Nugaev" 
> wrote:
> 
> > Hi Erik
> >
> > Thank you for response!
> > Yes, you are absolutely right OpenStack API already support shared IP
> groups.
> > Suppose there are some misunderstanding, because I wrote about floating IPs.
> >
> > I want to have API for association IPs from floating IPs pool with
> > particular VM.
> >
> > At this moment we have #1 implementation as a path in our RPM repo
> > http://yum.griddynamics.net/. And going to make the merge proposal to
> > trunk.
> >
> > Also we going to create blueprint about #3 and attach branch to it.
> >
> > Eldar
> >
> > On Sat, Apr 16, 2011 at 2:34 AM, Erik Carlin
>  wrote:
> >> Eldar -
> >>
> >> The OpenStack API already supports sharing IPs between instances
> (although
> >> this may be an extension?).  What exact behavior are you after?  More
> >> important than the way in which we expose via the API is how it's
> >> implemented.  It's important to note that this is extremely network
> >> topology dependent.  Sharing IPs today requires L2 adjacency so other
> VMs
> >> can GARP for the IP.  L2 doesn't work at scale so you need another
> >> mechanism.  I'm pretty sure the way AWS does it is to have a separate
> pool
> >> of IPs and inject /32 routes higher up that route towards the
> appropriate
> >> VM IP.  What are your thoughts around how this would be implemented?
> >>
> >> Multiple people are working towards an independent Network as a Service
> >> external to nova so it may make sense to plug this requirement in there.
> >>
> >> Erik
> >>
> >> On 4/11/11 8:31 AM, "Eldar Nugaev" 
> wrote:
> >>
> >>> Hello everyone,
> >>>
> >>> We going to add possibility to assigning floating IP addresses in
> >>> OpenStack API.
> >>> Our goal reproduce AWS behavior when creating instance automatically
> >>> assigns any free floating IP or add methods to OpenStack API for
> >>> allocation and association API addresses.
> >>>
> >>> At this time we see three way:
> >>>
> >>> 1. FLAG --auto_assign_floating_ip (default=False)
> >>> 2. Optional parameter "auto_assign_floating_ip" in existing "create"
> >>> method
> >>> 3. OpenStack API add floating_ip - allocate_floating_ip,
> >>> associate_floating_ip
> >>>
> >>> What way is more suitable at this time?
> >>>
> >>> --
> >>> Eldar
> >>> Skype: eldar.nugaev
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >>
> >> Confidentiality Notice: This e-mail message (including any attached or
> >> embedded documents) is intended for the exclusive and confidential use of
> the
> >> individual or entity to which this message is addressed, and unless
> otherwise
> >> expressly indicated, is confidential and privileged information of
> Rackspace.
> >> Any dissemination, distribution or copying of the enclosed material is
> prohibited.
> >> If you receive this transmission in error, please notify us immediately
> by e-mail
> >> at ab...@rackspace.com, and delete the original message.
> >> Your cooperation is appreciated.
> >>
> >>
> >
> >
> >
> > --
> > Eldar
> > Skype: eldar.nugaev
> 
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is
> prohibited.
> If you receive this transmission in error, please notify us immediately by 
> e-mail
> at ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Daemon files packaged in the wrong folder, man pages

[Thomas Goirand]

Hi,

I have noticed that all binaries of Openstack nova / swift / glance, are
going in /usr/bin, including daemons. As per the FSSH, daemons should go
in /usr/sbin. Could we move them in /usr/sbin? If not, why?

In my Debian packaging, I've written few man pages, because it's
forbidden in Debian to package things in /usr/bin or /usr/sbin without
them. I did them in debian/mans, as a temporary solution, because I
didn't want to interfere with current development so close from a
release. But at some point, these man pages should go in the projects
themselves, and not in the debian/mans folder.

I've already noticed that nova has a novamanage.1 which is generated by
Sphinx. What would be the way to write the new man pages I'd like to
add, in the same way? (BTW, as I wrote to Thierry in IRC, it should have
been nova-manage.1 and not novamanage.1) Or would it be seen as
acceptable to write man pages "by hand" (which I am comfortable doing)?
What's the preferred way for the project(s)?

Thomas Goirand (zigo)

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] API for remotely controlling nova-manage

[Thomas Goirand]

Hi,

Subject says it all. How should I do that? Is it planned?

Please forget me if the question seems silly, I currently don't know the
code of Nova well enough (I mainly worked on Debian packaging for the
moment). Let me explain my intentions a bit more. I'd like to create a
central web interface that would control installations of Openstack in
few data centers (currently, at least 2, one in US, one in Europe). This
interface would manage the users credentials, billing (and its
corresponding resource usage monitoring), etc. As I'm more advanced in
my packaging, I'll start diving into the Openstack project itself, and
add these features I need, so that everything can be gathered in a
central unique server, and control different locations (zones in Nova?).
Note that my web interface wont be in Python, so a SOAP service for
controlling nova-manage seems the best way for me. Or maybe, will I be
allowed to directly write in the nova MySQL db (then, I'm scared that
the schema will change...).

Thomas Goirand (zigo)

P.S: I've uploaded already python-novaclient to Debian experimental,
which was the only one clean enough, so I could do it. More will follow.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] API for remotely controlling nova-manage

[Eric Day]

Hi Thomas,

I think ideally nova-manage would simply be a command line client using
the exposed API in bin/nova-api. So what we really need is nova-api
additions to encapsulate the nova-manage functionality, and you could
hit that directly. There has been a lot of API functionality added
in this last release, but it's still not complete. Note that some
functionality will be split off into other projects (for example,
auth management will be moved to a openstack-auth project that can
be used for other projects besides nova).

-Eric

On Mon, Apr 18, 2011 at 01:58:59AM +0800, Thomas Goirand wrote:
> Hi,
> 
> Subject says it all. How should I do that? Is it planned?
> 
> Please forget me if the question seems silly, I currently don't know the
> code of Nova well enough (I mainly worked on Debian packaging for the
> moment). Let me explain my intentions a bit more. I'd like to create a
> central web interface that would control installations of Openstack in
> few data centers (currently, at least 2, one in US, one in Europe). This
> interface would manage the users credentials, billing (and its
> corresponding resource usage monitoring), etc. As I'm more advanced in
> my packaging, I'll start diving into the Openstack project itself, and
> add these features I need, so that everything can be gathered in a
> central unique server, and control different locations (zones in Nova?).
> Note that my web interface wont be in Python, so a SOAP service for
> controlling nova-manage seems the best way for me. Or maybe, will I be
> allowed to directly write in the nova MySQL db (then, I'm scared that
> the schema will change...).
> 
> Thomas Goirand (zigo)
> 
> P.S: I've uploaded already python-novaclient to Debian experimental,
> which was the only one clean enough, so I could do it. More will follow.
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] API for remotely controlling nova-manage

[ksankar]

Couple of points:a)    We do need a North-facing interface that supports headless operation incl billing, reporting and so forthb)IMHO, REST APIs are better than SOAP interfacesc)    Also JSON might be a good choiced)    There are already other cloud APIs available like the vCloud, OCCI et al. OCCI might fit your requirements. We really do not want to yet another cloud API with it's own programming model, if possible.Cheers 


 Original Message 
Subject: [Openstack] API for remotely controlling nova-manage
From: Thomas Goirand 
Date: Sun, April 17, 2011 10:58 am
To: "openstack@lists.launchpad.net" 

Hi,

Subject says it all. How should I do that? Is it planned?

Please forget me if the question seems silly, I currently don't know the
code of Nova well enough (I mainly worked on Debian packaging for the
moment). Let me explain my intentions a bit more. I'd like to create a
central web interface that would control installations of Openstack in
few data centers (currently, at least 2, one in US, one in Europe). This
interface would manage the users credentials, billing (and its
corresponding resource usage monitoring), etc. As I'm more advanced in
my packaging, I'll start diving into the Openstack project itself, and
add these features I need, so that everything can be gathered in a
central unique server, and control different locations (zones in Nova?).
Note that my web interface wont be in Python, so a SOAP service for
controlling nova-manage seems the best way for me. Or maybe, will I be
allowed to directly write in the nova MySQL db (then, I'm scared that
the schema will change...).

Thomas Goirand (zigo)

P.S: I've uploaded already python-novaclient to Debian experimental,
which was the only one clean enough, so I could do it. More will follow.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] API for remotely controlling nova-manage

[Ken Pepple]

On Apr 17, 2011, at 10:58 AM, Thomas Goirand wrote:
> Subject says it all. How should I do that? Is it planned?


I believe work has already started on this at 
http://wiki.openstack.org/NovaAdminAPI … While this isn't everything that you 
want, it's probably a starting point.

/k

---
Ken Pepple
http://ken.pepple.info






___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] API for remotely controlling nova-manage

[Sandy Walsh]

I think part of the problem is there are some operations in nova-manage that 
require nova to not be running:

- creating the initial project
- creating the initial user
etc

for anything beyond these basic bootstrapping operations, layering something on 
the admin-only portion of the OS API is pretty simple.

-S


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Lieutenants / Teams / Blueprints

[Vishvananda Ishaya]

Lieutenants

The number of people contributing code to nova has grown dramatically over the 
last few months, and it is becoming difficult to maintain a clear picture of 
the entire code base.  I'd like to move towards a somewhat more sectioned view 
of the code, where there is at least one person who is responsible for 
maintaining a given section of code.   This is similar to the process 
[http://p2pfoundation.net/Linux_-_Governance#Linux_Organization] used for linux 
development.

Since it isn't exactly clear who should be the point of contact for each 
section of the code, the first step is to collect a list of interested parties. 
 We have a list that maps core members to areas that they are interested in at 
http://wiki.openstack.org/NovaCore

I've created a wiki page at http://wiki.openstack.org/NovaLieutenants to start 
collecting interested parties.  If you feel like you would be a contact point 
for one of the items on the list, please put your name and contact info in that 
section.  For now I can work with all of the self-selected contact points on 
the list.  Ultimately, as PTL, I would like to work towards having a single 
trusted person for each section of the code to manage commits in that area.

These lieutenants will also give us people to act as PTLs for the new projects 
when we split off sections (like Network and Volume) into their own services.

Team Contact

I'm also trying to compile a list of all of the different teams working on 
Nova.  This will allow me to keep track of the development work being done by 
the various groups.  It would really help if all of the teams could add 
themselves to this list and select a point of contact for me to communicate 
with.  Hopefully we can link all of the blueprints on the teams launchpad page, 
but if you can put a brief overview of the current development effort(s) for 
your team on the wiki page, that will make it easier for people to see what is 
being actively worked on at a glance.

The team page is at http://wiki.openstack.org/NovaTeams

Blueprints

I'm currently going through the 40+ Blueprints and organizing them for the 
design summit.  For the last set of releases there wasn't a whole lot of 
insight into what makes a blueprint "approved" and what being "approved" means. 
 The process we're going through now is simply to approve blueprints for 
discussion at the summit.  The purpose of the summit is to hash out the details 
of the blueprint, argue about alternative solutions and generally to decide 
whether it is a good idea.  The hope is that there will be a general consensus 
amongst the developers at the summit as to whether development should move 
forward along the lines proposed in the blueprint.

My job as PTL will be to asses this consensus and approve the blueprints which 
everyone supports.  If there is a great amount of controversy about a 
particular blueprint, I will likely bring it to a vote by nova-core.  I will 
only attempt to dictate a direction when consensus is impossible.

Some of the blueprints are smallish features and may not warrant a discussion 
on their own.  I will attempt to group these where possible into related 
feature sets so that we can talk about them all at once.  Extremely small 
features may not warrant a discussion at all, and I may just throw them into 
the mailing list for feedback before approving them.  I am also working with 
the various groups that have proposed very related features (like the NaaS 
proposals) to try to come together and standardize on one blueprint.

To clarify, as far as I'm concerned, it is not required to have an approved 
blueprint to work on a feature.  If the consensus is against a blueprint and a 
team/person still thinks it is valuable, the team is more than welcome to 
develop the feature and propose it for merge.  It will likely take a really 
killer implementation to swing popular opinion in favor of the feature, but 
sometimes code trumps design.  It is, however, highly recommended to follow the 
blueprint process as much as possible.  That way I can track the features being 
added by different groups and ensure that work is not duplicated and that all 
the features will play nice together.


Vish___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Daemon files packaged in the wrong folder, man pages

[Soren Hansen]

2011/4/17 Thomas Goirand :
> I have noticed that all binaries of Openstack nova / swift / glance, are
> going in /usr/bin, including daemons.

Yeah. That's where distutils puts scripts them by default. I'm sure
there's a way to coerce it into putting them somewhere else.

> As per the FSSH, daemons should go in /usr/sbin.

That was my gut feeling too, but I can't find anything in the FHS that
specicially speaks for daemons. Or is FSSH something else?

> In my Debian packaging, I've written few man pages, because it's
> forbidden in Debian to package things in /usr/bin or /usr/sbin without
> them.

I think "forbidden" is a bit of an exaggeration. It says "should" and
that missing man pages should be considered bugs.

This is actually why I'm generally against stub man pages. They make
it less obvious that there's work to do, but meh.

> I've already noticed that nova has a novamanage.1 which is generated by
> Sphinx. What would be the way to write the new man pages I'd like to
> add, in the same way? (BTW, as I wrote to Thierry in IRC, it should have
> been nova-manage.1 and not novamanage.1) Or would it be seen as
> acceptable to write man pages "by hand" (which I am comfortable doing)?
> What's the preferred way for the project(s)?

nova-manage is a bit special. Every (I think) other binary always does
the same thing (e.g. "act as an API server"), but takes half a
bajillion flags. nova-manage does a number of different things, which
I suppose is the reason it has special documentation magic.

We use python-gflags for our flag parsing and stuff, and gflags2man
can convert the flags descriptions to man pages, but it doesn't really
work for us, because we have a lot of conditional imports and stuff.
Anyway, the point is that there are existing tools that can mostly
generate man pages for us (automatically, so they'll be guaranteed to
be up-to-date), but there's some plumbing missing.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Enhancements to Glance in Diablo? Input welcomed

[Jesse Andrews]

Hi Jay,

Some thoughts about glance:

* There is lots of work/conversations around auth.  Rather than attempt to boil 
the ocean and "fix" authn/authz at once, we are thinking of taking a phased 
approach (1-2 week chunks of contained work to multiple openstack projects, 
followed by a week of review/planning for the next steps). My hope is that we 
have involvement from Nova, Swift and Glance PTLs (or delegates).

* What is the state of private images in glance?  Do we need to do more work in 
Diablo?

* Integration test coverage (end to end testing of openstack reference 
architectures) !  - I see someone else mentioned this, I just wanted to voice 
support :)

-- Sent from my Tandy 1000sx

Jesse Andrews
anotherje...@gmail.com


On Apr 12, 2011, at 11:11 AM, Jay Pipes wrote:

> Hey all,
> 
> We're in the planning stages for Diablo now, working on putting
> together blueprints, which turn into sessions at the design summit.
> 
> I know the Glance team is small and our project narrow in scope, but
> it would be great to get some feedback from the list about stuff you'd
> like to see included in Glance in the Diablo release.
> 
> Some possible thoughts:
> 
> * Authn/authz - This is a big one, but dependent on the overall
> discussion of federated auth going on in the Nova/Swift communities.
> Glance will merely follow suit with what Nova does most likely.
> * Image conversion. This actually already has a blueprint, but maybe
> good for a detailed discussion at the summit? See
> https://blueprints.launchpad.net/glance/+spec/image-file-conversion
> * Metrics - for instance, tracking operations performed (read/write,
> bytes out/in, ?) Would this even be useful?
> * Integration with more backend storage systems?
> * XML support in the API?
> * Having Glance "understand" what is contained in the disk images by
> inspecting them on upload?
> * A Glance dashboard app?
> 
> Please feel free to expand on any of the above and add any suggestions
> you have on the future direction of Glance. Your input is truly
> appreciated.
> 
> Cheers!
> jay
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] API for remotely controlling nova-manage

[Jesse Andrews]

+1

We were hoping to move it to an openstack admin api.  Hopefully now that 
openstack api 1.1 exists we can get traction on flushing it out with commands 
like these (and those contained within the ec2 extensions for administration)

-- Sent from my Tandy 1000sx

Jesse Andrews
anotherje...@gmail.com



On Apr 17, 2011, at 12:47 PM, Sandy Walsh wrote:

> I think part of the problem is there are some operations in nova-manage that 
> require nova to not be running:
> 
> - creating the initial project
> - creating the initial user
> etc
> 
> for anything beyond these basic bootstrapping operations, layering something 
> on the admin-only portion of the OS API is pretty simple.
> 
> -S
> 
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited.
> If you receive this transmission in error, please notify us immediately by 
> e-mail
> at ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Summit Talk: Information session on Zones? Any interest?

[Bryan Sung]

+1
I am very much interested in the session.
 
--- Original Message ---
Sender : Sateesh Chodapuneedi
Date : 2011-04-15 12:18 (GMT+09:00)
Title : Re: [Openstack] Summit Talk: Information session on Zones? Any interest?
 




+1. I am interested as well.
 


From: openstack-bounces+sateesh.chodapuneedi=citrix@lists.launchpad.net [mailto:openstack-bounces+sateesh.chodapuneedi=citrix@lists.launchpad.net] On Behalf Of Sandy WalshSent: Thursday, April 14, 2011 9:38 PMTo: openstack@lists.launchpad.netSubject: [Openstack] Summit Talk: Information session on Zones? Any interest?
 

I've been getting a lot of questions about Zones lately.  

 

How much interest is there for an informational session on Zones and, I guess, Distributed Scheduler and roadmap?

 

(pending an available slot at the summit ... things are filling up quickly I gather)

 

-S Confidentiality Notice: This e-mail message (including any attached orembedded documents) is intended for the exclusive and confidential use of theindividual or entity to which this message is addressed, and unless otherwiseexpressly indicated, is confidential and privileged information of Rackspace.Any dissemination, distribution or copying of the enclosed material is prohibited.If you receive this transmission in error, please notify us immediately by e-mailat ab...@rackspace.com, and delete the original message.Your cooperation is appreciated.
 




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Summit Talk: Information session on Zones? Any interest?

[Lorin Hochstein]

+1

I'm interested in zones as well. 

Lorin
--
Lorin Hochstein, Computer Scientist
USC Information Sciences Institute
703.812.3710
http://www.east.isi.edu/~lorin

On Apr 17, 2011, at 7:45 PM, Bryan Sung wrote:

> +1
> I am very much interested in the session.
>  
> --- Original Message ---
> Sender : Sateesh Chodapuneedi
> Date : 2011-04-15 12:18 (GMT+09:00)
> Title : Re: [Openstack] Summit Talk: Information session on Zones? Any 
> interest?
>  
> +1. I am interested as well.
>  
> From: openstack-bounces+sateesh.chodapuneedi=citrix@lists.launchpad.net 
> [mailto:openstack-bounces+sateesh.chodapuneedi=citrix@lists.launchpad.net]
>  On Behalf Of Sandy Walsh
> Sent: Thursday, April 14, 2011 9:38 PM
> To: openstack@lists.launchpad.net
> Subject: [Openstack] Summit Talk: Information session on Zones? Any interest?
>  
> I've been getting a lot of questions about Zones lately. 
>  
> How much interest is there for an informational session on Zones and, I 
> guess, Distributed Scheduler and roadmap?
>  
> (pending an available slot at the summit ... things are filling up quickly I 
> gather)
>  
> -S
> 
>  
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited.
> If you receive this transmission in error, please notify us immediately by 
> e-mail
> at ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>  
> <201104180845582_BEI0XT4N.gif>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Enhancements to Glance in Diablo? Input welcomed

[Devin Carlen]

Hey Jay,

What are your ideas for a glance dashboard app above and beyond what the 
OpenStack dashboard currently supports?  This would be a great thing for us to 
spend a bit of time talking about at the summit.

- Devin

> On Apr 12, 2011, at 11:11 AM, Jay Pipes wrote:
> 
>> Hey all,
>> 
>> We're in the planning stages for Diablo now, working on putting
>> together blueprints, which turn into sessions at the design summit.
>> 
>> I know the Glance team is small and our project narrow in scope, but
>> it would be great to get some feedback from the list about stuff you'd
>> like to see included in Glance in the Diablo release.
>> 
>> Some possible thoughts:
[snip]
>> 
>> 
>> * A Glance dashboard app?


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Daemon files packaged in the wrong folder, man pages

[Thomas Goirand]

On 04/18/2011 05:44 AM, Soren Hansen wrote:
> 2011/4/17 Thomas Goirand :
>> I have noticed that all binaries of Openstack nova / swift / glance, are
>> going in /usr/bin, including daemons.
>
> Yeah. That's where distutils puts scripts them by default. I'm sure
> there's a way to coerce it into putting them somewhere else.
>
>> As per the FSSH, daemons should go in /usr/sbin.
>
> That was my gut feeling too, but I can't find anything in the FHS that
> specicially speaks for daemons. Or is FSSH something else?

Sorry. File Hierarchy Standard, or File System Hierarchy? I'm not sure,
but anyway, we are talking about the same thing! :)

>> In my Debian packaging, I've written few man pages, because it's
>> forbidden in Debian to package things in /usr/bin or /usr/sbin without
>> them.
>
> I think "forbidden" is a bit of an exaggeration. It says "should" and
> that missing man pages should be considered bugs.

"lintian -Ii" warns about it, so I fix it... As simple as that! :)
Also, for myself, I found difficult to know which binary accepts what
option, and I would have appreciate such documentation as well.

> This is actually why I'm generally against stub man pages. They make
> it less obvious that there's work to do, but meh.

Nobody ever wrote we are going to leave things this way, writing in this
list is precisely to warn everyone that we do need more man pages work.

> other binary [...] takes half a bajillion flags.

Which is what I am worried about. At some point, we got to document that.

> We use python-gflags for our flag parsing and stuff, and gflags2man
> can convert the flags descriptions to man pages, but it doesn't really
> work for us, because we have a lot of conditional imports and stuff.
> Anyway, the point is that there are existing tools that can mostly
> generate man pages for us (automatically, so they'll be guaranteed to
> be up-to-date), but there's some plumbing missing.

Ok, that's exactly what I wanted to know, thanks. I'll have a look in
about a week of time (after a short break this week).

On 04/18/2011 02:54 AM, Anne Gentle wrote:
> Hi Thomas -
> 
> I'd love you to write more man pages for the Nova project. The way I
> wrote the nova-manage man page was my first attempt to write a man page,
> and I basically wanted to keep the documentation in the doc directory,
> so I put it in doc/source. Sorry the file is named incorrectly, I didn't
> realize that.

No worries! :)

lintian (a Debian quality insurance tool) warned me about the
nova-manage binary not being documented, but it took me a long time to
realize what was going on. Not a big deal for me, as I did some renames
on the Debian packaging side of things, but I thought it was important
to write it in this list so that it could be fixed for everyone.

> I don't have a strong opinion on the matter, and I am not
> one to say "well we've always done it this way so..."

I'm ok whatever way you feel more comfortable, either by hand or
generated by some tool. If you are ok with a "by hand" thing, then I'll
right away move my man pages in the doc folder.

Mainly, I had to add at least stub man pages to have the package be
Debian policy compliant.

> If you do write man pages by hand, can they:
> a) be stored with the nova doc source?

Yes, my intention was to fix what I did and put it somewhere there.

> b) be reused across distros? (that is, you're not writing just for
> debian, right?)

That's my hope.

Thomas Goirand

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] API for remotely controlling nova-manage

[Thomas Goirand]

On 04/18/2011 02:30 AM, ksan...@doubleclix.net wrote:
> Couple of points:
> a)We do need a North-facing interface that supports headless
> operation incl billing, reporting and so forth

I will work on that.

> b)IMHO, REST APIs are better than SOAP interfaces

My understanding is that EC2 has both REST and SOAP. Do you think it's
ok to have both again for this kind of API?

> c)Also JSON might be a good choice
> d)There are already other cloud APIs available like the vCloud, OCCI
> et al. OCCI might fit your requirements. We really do not want to yet
> another cloud API with it's own programming model, if possible.

Thanks for that, I'll have a look in that too.

Thomas

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp