Re: [Openstack] Floating IP in OpenStack API
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
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
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
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
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 GoirandDate: 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
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
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
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
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
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
+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?
+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?
+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
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
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
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