Re: [Openstack] openstack dashboard default page changing

[Atul Jha]

Hi,


We created a new site for explaining our cloud research work.
But when we deployed that html page to openstack dashboard folder 
then the page shows some permission problem like

   The page you were looking for doesn't exist

   You may have mistyped the address or the page may have moved.


How can I change the default page of dashboard to home page of our 
web page



What exactly are you trying to do? Customize the Openstack-Dashboard(Horizon)

Atul Jha
http://www.csscorp.com/common/email-disclaimer.php
___
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] openstack dashboard default page changing

[sarath zacharia]

Hi,

Not Customizing openstack dashboard only adding new static pages (Simple
HTML pages ) like about us home page etc.

On Tue, Aug 21, 2012 at 12:29 PM, Atul Jha  wrote:

>  Hi,
>
>  
> We created a new site for explaining our cloud research work.
> But when we deployed that html page to openstack dashboard
> folder then the page shows some permission problem like
>
>The page you were looking for doesn't exist
>
>You may have mistyped the address or the page may have
> moved.
>
> How can I change the default page of dashboard to home page of
> our web page
>
>  
>
> What exactly are you trying to do? Customize the
> Openstack-Dashboard(Horizon)
>
> Atul Jha
>   http://www.csscorp.com/common/email-disclaimer.php
>



-- 
with regards

Sarath !
___
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] openstack dashboard default page changing

[Atul Jha]

Hi,

Not Customizing openstack dashboard only adding new static pages (Simple 
HTML pages ) like about us home page etc.

See if this helps
http://docs.openstack.org/developer/horizon/topics/customizing.html




On Tue, Aug 21, 2012 at 12:29 PM, Atul Jha 
mailto:atul@csscorp.com>> wrote:
Hi,


We created a new site for explaining our cloud research work.
But when we deployed that html page to openstack dashboard folder 
then the page shows some permission problem like

   The page you were looking for doesn't exist

   You may have mistyped the address or the page may have moved.


How can I change the default page of dashboard to home page of our 
web page



What exactly are you trying to do? Customize the Openstack-Dashboard(Horizon)

Atul Jha
http://www.csscorp.com/common/email-disclaimer.php



--
with regards

Sarath !
http://www.csscorp.com/common/email-disclaimer.php
___
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] openstack dashboard default page changing

[sarath zacharia]

Hi ,

Thanks for the help . But I want to give add simple html page in
the login page i have to give the link in that login page
like giving href link


On Tue, Aug 21, 2012 at 12:44 PM, Atul Jha  wrote:

>  Hi,
>
>   Not Customizing openstack dashboard only adding new static pages
> (Simple HTML pages ) like about us home page etc.
> 
> See if this helps
> http://docs.openstack.org/developer/horizon/topics/customizing.html
>
>
>
>
>  On Tue, Aug 21, 2012 at 12:29 PM, Atul Jha  wrote:
>
>>  Hi,
>>
>>  
>> We created a new site for explaining our cloud research work.
>> But when we deployed that html page to openstack dashboard
>> folder then the page shows some permission problem like
>>
>>The page you were looking for doesn't exist
>>
>>You may have mistyped the address or the page may have
>> moved.
>>
>> How can I change the default page of dashboard to home page
>> of our web page
>>
>>  
>>
>> What exactly are you trying to do? Customize the
>> Openstack-Dashboard(Horizon)
>>
>> Atul Jha
>>   http://www.csscorp.com/common/email-disclaimer.php
>>
>
>
>
>  --
> with regards
>
> Sarath !
>   http://www.csscorp.com/common/email-disclaimer.php
>



-- 
with regards

Sarath !
___
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] multiple interfaces for floating IPs

[Juris]

Greetings everyone,

Just a quick question.
Is it possible to assign floating IPs to multiple nova node interfaces?
For instance if I have a server with 4 NICs and I'd like to use NIC1
for private network, NIC2 for data and management, NIC3 for one of my
public IP subnets and NIC4 for another public IP subnet?

Best wishes,
Juris

___
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] openstack libvirt lxc

[Daniel P. Berrange]

On Tue, Aug 21, 2012 at 10:19:34AM +0800, 廖南海 wrote:
> Who use the lxc virtual machine？
> Please give me some advices?

My advice would be not to use LXC since, as it exists today, it is not
secure. ie root within the container can break out & compromise the
entire host. This is not really the fault of OpenStack, but rather the
fact that the Linux kernel container support is still under development
and does not provide all the pieces required to form a secure solution.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
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] openstack libvirt lxc

[Pádraig Brady]

On 08/21/2012 03:19 AM, 廖南海 wrote:
> 
> Who use the lxc virtual machine？
> Please give me some advices?
> I encountered some problems.
> Thank you!

Essex had some fundamental issues with LXC,
that are addressed with:
https://review.openstack.org/#/c/10962/

thanks,
Pádraig.

___
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] Multiple Floating IPs per multiple instance interfaces

[Juris]

Hi all,

Is it possible to assign floating IP to some particular instance's interface.
Let's say we have Instance1 with 2 interfaces (nic1 and nic2) and two
pools of floating IP addresses (pool1 and pool2). So how can I assign
IP from pool1 to point to nic and IP from pool2 to nic2?

Thank you in advance.

___
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] Translating REST API response data based on Accept-Language header

[boden]

All,

Although I'm still ramping up on OpenStack in general, it appears (via
visual code inspection and reading https://gist.github.com/2969337#id18)
there is no support from a REST API perspective to return translated
data to REST consumers by honoring the 'Accept-Language' in the request
header -- true?

As a non-horizon REST API consumer, I would expect (I do expect a lot,
just ask my wife :) my Accept-Language to be honored as best as possible
for localized data returned by the software system.

For example a software system (OpenStack) error which returns an error
message (response) "You can't pass in this junk" -- I would expect to be
translated into the locale specified by my Accept-Language header when
possible.

I do realize that not all response data is applicable to this construct.
For example data returned by alien calls (for example - to the
hypervisor) is out of the software's control (unless you can cascade the
locale down on the alien call) and hence is at the mercy of the alien
system.

Are there any plans (quick google didn't turn up anything useful) to add
support for honoring the Accept-Language??

Thanks


___
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] multiple LDAPs in OpenStack

[pat]

Yes, you are right, but I want to collect information first ;-)

Thanks to all

 Pat

 On Mon, 20 Aug 2012 18:07:45 -0500, Dolph Mathews wrote
 > While there's no implementation of this in keystone today, I'm sure you
could write your own LDAP driver in keystone, heavily leveraging the existing
LDAP driver.
 >
 > -Dolph
 >
 > On Mon, Aug 20, 2012 at 4:19 PM, Ryan Lane  wrote:
 >  
 > On Mon, Aug 20, 2012 at 1:52 PM, pat  wrote:
 > > Hello,
 > >
 > > I'm new to this list and OpenStack at all. I want to ask a question: I
want to
 > > ask if it's possible to use one LDAP per tenant. I've searched the web, but
 > > didn't found the answer.
 > >
 >
 > In keystone this is not currently possible.
 >
 > - Ryan
 >



Freehosting PIPNI - http://www.pipni.cz/


___
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] [Glance] Windows image password customize?

[Everett Toews]

I've come across a couple of projects that do this. Neither of them have much 
documentation so you'll have to dig into the code.

https://github.com/jordanrinke/openstack

http://code.google.com/p/cips/

Regards,
Everett


From: openstack-bounces+everett.toews=rackspace@lists.launchpad.net 
[openstack-bounces+everett.toews=rackspace@lists.launchpad.net] on behalf 
of 한승진 [yongi...@gmail.com]
Sent: Monday, August 20, 2012 10:14 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] [Glance] Windows image password customize?

Hi

I'm studying how to regenerate or customize windows instance when the instance 
boot. However, I cannot get an answer still now.

Linux image doesn't have to regenerate the password because of keyfile login.

Do you have any idea ??


___
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] Hyper-V meeting adgenda

[Peter Pouliot]

Today should be a quick meeting.   The following are topics for discussion?


1.   The code is now part of the mainline.

a.   Filing bugs

2.   CI Status

3.   Summit Planning

a.   Blueprints for Grizzly





Peter J. Pouliot, CISSP
Senior SDET, OpenStack

Microsoft
New England Research & Development Center
One Memorial Drive,Cambridge, MA 02142
ppoul...@microsoft.com | Tel: +1(857) 453 6436

___
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] Hyper-V meeting Minutes

[Peter Pouliot]

Minutes:
http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-21-15.00.html
Minutes (text): 
http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-21-15.00.txt
Log:
http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-21-15.00.log.html


Peter J. Pouliot, CISSP
Senior SDET, OpenStack

Microsoft
New England Research & Development Center
One Memorial Drive,Cambridge, MA 02142
ppoul...@microsoft.com | Tel: +1(857) 453 6436

___
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] openstack libvirt lxc

[Robbie Williamson]

On 08/21/2012 04:15 AM, Daniel P. Berrange wrote:
> On Tue, Aug 21, 2012 at 10:19:34AM +0800, 廖南海 wrote:
>> Who use the lxc virtual machine？
>> Please give me some advices?
> 
> My advice would be not to use LXC since, as it exists today, it is not
> secure. ie root within the container can break out & compromise the
> entire host. This is not really the fault of OpenStack, but rather the
> fact that the Linux kernel container support is still under development
> and does not provide all the pieces required to form a secure solution.
> 
> Daniel
> 
This is all true, but depending on your environment and the level of
trust you give to your users, this might not be an issuealso if you
are testing on ARM server, this is all you have for now ;)

-Robbie

-- 
Robbie Williamson 
robbiew[irc.freenode.net]

"Don't make me angry...you wouldn't like me when I'm angry."
 -Bruce Banner

___
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] [Glance] Windows image password customize?

[Peter Pouliot]

You should look into the following for customizing your Windows VM Images.

SYSPREP
http://technet.microsoft.com/en-us/library/cc783215(v=ws.10).aspx

Unattend.xml

Here’s some docs and a sample.

http://technet.microsoft.com/en-us/library/ee441262(v=ws.10).aspx



From: openstack-bounces+ppouliot=microsoft@lists.launchpad.net 
[mailto:openstack-bounces+ppouliot=microsoft@lists.launchpad.net] On Behalf 
Of ???
Sent: Monday, August 20, 2012 11:15 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] [Glance] Windows image password customize?

Hi

I'm studying how to regenerate or customize windows instance when the instance 
boot. However, I cannot get an answer still now.

Linux image doesn't have to regenerate the password because of keyfile login.

Do you have any idea ??


___
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] Translating REST API response data based on Accept-Language header

[Vishvananda Ishaya]

This is currently not supported by OpenStack. We have localization support
but it is host-configured and it doesn't vary based on an accept-header.
This seems like a very useful feature to get in for the next release, however.

Vish

On Aug 21, 2012, at 6:36 AM, boden  wrote:

> All,
> 
> Although I'm still ramping up on OpenStack in general, it appears (via
> visual code inspection and reading https://gist.github.com/2969337#id18)
> there is no support from a REST API perspective to return translated
> data to REST consumers by honoring the 'Accept-Language' in the request
> header -- true?
> 
> As a non-horizon REST API consumer, I would expect (I do expect a lot,
> just ask my wife :) my Accept-Language to be honored as best as possible
> for localized data returned by the software system.
> 
> For example a software system (OpenStack) error which returns an error
> message (response) "You can't pass in this junk" -- I would expect to be
> translated into the locale specified by my Accept-Language header when
> possible.
> 
> I do realize that not all response data is applicable to this construct.
> For example data returned by alien calls (for example - to the
> hypervisor) is out of the software's control (unless you can cascade the
> locale down on the alien call) and hence is at the mercy of the alien
> system.
> 
> Are there any plans (quick google didn't turn up anything useful) to add
> support for honoring the Accept-Language??
> 
> Thanks
> 
> 
> ___
> 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] Glance Folsom Release

[Brian Waldon]

As the feature phase of Folsom has closed, I went ahead and wrote up some notes 
about Glance. I included it all in this email, but you can see the pretty 
version at http://bcwaldon.cc/2012/08/20/openstack-folsom-glance-overview.html.

Brian Waldon

--

As we are coming up on the Folsom OpenStack release, I thought it would be a 
good idea to cover what landed in Glance over the last several months. It is 
becoming increasingly difficult to keep up with all of our projects, so I hope 
this overview helps!

## Python Client Rewrite

A new client library, 
[python-glanceclient](http://github.com/openstack/python-glanceclient), was 
created during the Folsom release cycle to replace the client that currently 
lives in the Glance repository. This new client has already been integrated 
into Nova, Cinder, Horizon and Devstack.

As a [library project](http://wiki.openstack.org/ProjectTypes), 
python-glanceclient does not follow the same release cycle as core projects 
such as Glance. It uses a three-part versioning mechanism and is distributed 
through OpenStack-supporting distros, 
[pypi](http://pypi.python.org/pypi/python-glanceclient), and 
[GitHub](http://github.com/openstack/python-glanceclient).

The importance bit is that the (now considered 'legacy') client code in Glance 
is officially deprecated in favor of this new client. It will still ship with 
Folsom, but it prints warnings to stderr when used from the command-line and 
raises `UserWarning` when imported directly in python. Expect the legacy client 
code to be removed from the Glance repository sometime early in the Grizzly 
release cycle.

The new client does maintain 100% CLI compatibility for interactions with the 
v1 Images API, but that legacy usage will never be updated to work with the v2 
API. The python interface does not maintain compatibility with the legacy 
client, however, the python module does not conflict with that installed by the 
Glance source. Expect to see more about python-glanceclient in a subsequent 
post.

## OpenStack Images API v2.0

Version 2.0 of the OpenStack Images API is largely defined based on the work 
that was finished in the Folsom release of Glance. Expect a separate post 
covering the v2.0 API spec itself.

I wanted to specifically thank Mark Washenberger, Alex Meade, Iccha Sethi and 
Nikhil Komawar of Rackspace for their outstanding work on the v2.0 API 
implementation!

See the [super-blueprint on 
launchpad](https://blueprints.launchpad.net/glance/+spec/api-2).

## High-Profile Bugs

Features are always awesome, but the biggest request of the OpenStack community 
has been to work on stabilization and bug-fixing. The following is a list of 
major bugs that were fixed in the Folsom release cycle, many more 
lower-priority bugs were fixed and can be seen on launchpad. Bugs that affect 
stable/essex have been backported accordingly.

### Keystone Integration

* [1010519](https://bugs.launchpad.net/glance/+bug/1010519): Use a 
case-insensitive check when determining if a user has admin privileges

### Swift Integration

* [979745](https://bugs.launchpad.net/glance/+bug/979745): Actually delete 
images from swift when using Keystone authentication.
* [1002791](https://bugs.launchpad.net/glance/+bug/1002791): Replace usage of 
`swift.client` with `swiftclient` - swift dependency replaced with 
python-swiftclient.
* [994296](https://bugs.launchpad.net/glance/+bug/994296): Allow swift account 
name to contain the '@' character.

### SSL

* [1032451](https://bugs.launchpad.net/glance/+bug/1032451): Allow server to 
validate client certificate using CA cert specified in `ca_file` config option.
* [1007093](https://bugs.launchpad.net/glance/+bug/1007093): Images less than 4 
KB in size are now uploaded only once; data is no longer duplicated.

### Database

* [1012823](https://bugs.launchpad.net/glance/+bug/1012823): Prevent database 
auto-creation - configurable using `db_auto_create` config option.
* [975651](https://bugs.launchpad.net/ubuntu/+source/glance/+bug/975651): 
Update all image id references in db migration 12; image properties were being 
ignored.

### Miscellaneous

* [1038994](https://bugs.launchpad.net/glance/+bug/1038994): Maximum image size 
is now configurable using `image_size_cap` (default 1 TB) and chunked 
transfer-encoding HTTP requests are now properly validated.
* [978130](https://bugs.launchpad.net/glance/+bug/978130): Multiprocess-enabled 
servers now respect CTRL+C.
* [1031842](https://bugs.launchpad.net/glance/+bug/1031842): Partially-cached 
images are removed when a client connection is prematurely closed.
* [1021054](https://bugs.launchpad.net/glance/+bug/1021054), 
[1021740](https://bugs.launchpad.net/glance/+bug/1021740): Admins can now share 
images regardless of ownership or existing sharing permissions.

## Show me the Features!

### Tenant-Specific Storage Locations in Swift

The ability to store image data in the image owner-specific locations has 
always been an interesting 

Re: [Openstack] Multiple Floating IPs per multiple instance interfaces

[Vishvananda Ishaya]

No it is not possible to do this with flaoting ips. Floating ips are not 
visible to the instance and they are natted by the network host to the first 
fixed ip of the guest.

It is possible to configure nova to give multiple fixed ips to a single vm on 
different interfaces, but configuring it is a bit tricky.

Vish

On Aug 21, 2012, at 5:12 AM, Juris  wrote:

> Hi all,
> 
> Is it possible to assign floating IP to some particular instance's interface.
> Let's say we have Instance1 with 2 interfaces (nic1 and nic2) and two
> pools of floating IP addresses (pool1 and pool2). So how can I assign
> IP from pool1 to point to nic and IP from pool2 to nic2?
> 
> Thank you in advance.
> 
> ___
> 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] [openstack-dev] Discussion about where to put database for bare-metal provisioning (review 10726)

[David Kang]

 Hi Vish,

 We are trying to change our code according to your comment.
I want to ask a question.

> >> a) modify driver.get_host_stats to be able to return a list of host
> >> stats instead of just one. Report the whole list back to the
> >> scheduler. We could modify the receiving end to accept a list as
> >> well
> >> or just make multiple calls to
> >> self.update_service_capabilities(capabilities)

 Modifying driver.get_host_stats to return a list of host stats is easy.
Calling muliple calls to self.update_service_capabilities(capabilities) doesn't 
seem to work,
because 'capabilities' is overwritten each time.

 Modifying the receiving end to accept a list seems to be easy.
However, 'capabilities' is assumed to be dictionary by all other scheduler 
routines,
it looks like that we have to change all of them to handle 'capability' as a 
list of dictionary.

 If my understanding is correct, it would affect many parts of the scheduler.
Is it what you recommended?

 Thanks,
 David
 

- Original Message -
> This was an immediate goal, the bare-metal nova-compute node could
> keep an internal database, but report capabilities through nova in the
> common way with the changes below. Then the scheduler wouldn't need
> access to the bare metal database at all.
> 
> On Aug 15, 2012, at 4:23 PM, David Kang  wrote:
> 
> >
> > Hi Vish,
> >
> > Is this discussion for long-term goal or for this Folsom release?
> >
> > We still believe that bare-metal database is needed
> > because there is not an automated way how bare-metal nodes report
> > their capabilities
> > to their bare-metal nova-compute node.
> >
> > Thanks,
> > David
> >
> >>
> >> I am interested in finding a solution that enables bare-metal and
> >> virtualized requests to be serviced through the same scheduler
> >> where
> >> the compute_nodes table has a full view of schedulable resources.
> >> This
> >> would seem to simplify the end-to-end flow while opening up some
> >> additional use cases (e.g. dynamic allocation of a node from
> >> bare-metal to hypervisor and back).
> >>
> >> One approach would be to have a proxy running a single nova-compute
> >> daemon fronting the bare-metal nodes . That nova-compute daemon
> >> would
> >> report up many HostState objects (1 per bare-metal node) to become
> >> entries in the compute_nodes table and accessible through the
> >> scheduler HostManager object.
> >>
> >>
> >>
> >>
> >> The HostState object would set cpu_info, vcpus, member_mb and
> >> local_gb
> >> values to be used for scheduling with the hypervisor_host field
> >> holding the bare-metal machine address (e.g. for IPMI based
> >> commands)
> >> and hypervisor_type = NONE. The bare-metal Flavors are created with
> >> an
> >> extra_spec of hypervisor_type= NONE and the corresponding
> >> compute_capabilities_filter would reduce the available hosts to
> >> those
> >> bare_metal nodes. The scheduler would need to understand that
> >> hypervisor_type = NONE means you need an exact fit (or best-fit)
> >> host
> >> vs weighting them (perhaps through the multi-scheduler). The
> >> scheduler
> >> would cast out the message to the . (code
> >> today uses the HostState hostname), with the compute driver having
> >> to
> >> understand if it must be serviced elsewhere (but does not break any
> >> existing implementations since it is 1 to 1).
> >>
> >>
> >>
> >>
> >>
> >> Does this solution seem workable? Anything I missed?
> >>
> >> The bare metal driver already is proxying for the other nodes so it
> >> sounds like we need a couple of things to make this happen:
> >>
> >>
> >> a) modify driver.get_host_stats to be able to return a list of host
> >> stats instead of just one. Report the whole list back to the
> >> scheduler. We could modify the receiving end to accept a list as
> >> well
> >> or just make multiple calls to
> >> self.update_service_capabilities(capabilities)
> >>
> >>
> >> b) make a few minor changes to the scheduler to make sure filtering
> >> still works. Note the changes here may be very helpful:
> >>
> >>
> >> https://review.openstack.org/10327
> >>
> >>
> >> c) we have to make sure that instances launched on those nodes take
> >> up
> >> the entire host state somehow. We could probably do this by making
> >> sure that the instance_type ram, mb, gb etc. matches what the node
> >> has, but we may want a new boolean field "used" if those aren't
> >> sufficient.
> >>
> >>
> >> I This approach seems pretty good. We could potentially get rid of
> >> the
> >> shared bare_metal_node table. I guess the only other concern is how
> >> you populate the capabilities that the bare metal nodes are
> >> reporting.
> >> I guess an api extension that rpcs to a baremetal node to add the
> >> node. Maybe someday this could be autogenerated by the bare metal
> >> host
> >> looking in its arp table for dhcp requests! :)
> >>
> >>
> >> Vish
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> openstack-...@lists.

[Openstack] implementing custom keystone module

[pat]

Hello,

I want to implement custom keystone authentication module. I went through the
documentation and I'm not sure where to start :-\ Please, could you point me
to specific page describing this? Thanks. And one more: please, could you
point me to document which describes relation between keystone and WSGI? And
yes, I've never used python :-)

Thanks for help.

 Pat

P.S. I've googled a lot, but keystone is too common world :-(


Freehosting PIPNI - http://www.pipni.cz/


___
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] uninstall

[Guillermo Alvarado]

Hello everyone,

Which is the best way to uninstall all the components? I want to re-install
it because I have  an inconsistent environment.

Thanks in advance!!
___
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] implementing custom keystone module

[Adam Young]

On 08/21/2012 05:10 PM, pat wrote:

Hello,

I want to implement custom keystone authentication module. I went through the


What are you trying to do?  There is a good chance that one of the other 
modules can be a good example.



documentation and I'm not sure where to start :-\ Please, could you point me
to specific page describing this? Thanks. And one more: please, could you
point me to document which describes relation between keystone and WSGI? And


WSGI is a standard for writing Web applicaions in Python. Keystone 
complies with the WSGI contract.  THus, while Keystone is usually run in 
the Eventlet web container, it can run in Apache HTTPD as well.  Both 
are WSGI containers.




yes, I've never used python :-)

Thanks for help.

  Pat

P.S. I've googled a lot, but keystone is too common world :-(


Google for "Openstack Keystone" and you will have more success.



Freehosting PIPNI - http://www.pipni.cz/


___
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] Unable to start nova-scheduler : duplicate option: scheduler_host_manager

[Ben]

Hi,

I'm trying to setup a little nova cluster with 3 nodes :

- 1 controller node running all services but compute
- 2 compute nodes running compute and network only

I have faced a lot of issues, but I can't understand this one. When I 
start nova-scheduler on controller node, the process dies instantly with 
this error :


CRITICAL nova [-] duplicate option: scheduler_host_manager

So I can't start an instance, it remains stuck in building state. I have 
checked my nova.conf file, and I only see this line :


--scheduler_driver=nova.scheduler.simple.SimpleScheduler

What does means this error, how can I solve it ?

Thanks,

Ben

___
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] [openstack-dev] Discussion about where to put database for bare-metal provisioning (review 10726)

[Vishvananda Ishaya]

I think you should be able to modify nova/manager.py to be able to store and 
report a list of capabilites and report them all individually to the scheduler 
via the periodic task.

Vish

On Aug 21, 2012, at 1:28 PM, David Kang  wrote:

> 
>  Hi Vish,
> 
>  We are trying to change our code according to your comment.
> I want to ask a question.
> 
 a) modify driver.get_host_stats to be able to return a list of host
 stats instead of just one. Report the whole list back to the
 scheduler. We could modify the receiving end to accept a list as
 well
 or just make multiple calls to
 self.update_service_capabilities(capabilities)
> 
>  Modifying driver.get_host_stats to return a list of host stats is easy.
> Calling muliple calls to self.update_service_capabilities(capabilities) 
> doesn't seem to work,
> because 'capabilities' is overwritten each time.
> 
>  Modifying the receiving end to accept a list seems to be easy.
> However, 'capabilities' is assumed to be dictionary by all other scheduler 
> routines,
> it looks like that we have to change all of them to handle 'capability' as a 
> list of dictionary.
> 
>  If my understanding is correct, it would affect many parts of the scheduler.
> Is it what you recommended?
> 
>  Thanks,
>  David
>  
> 
> - Original Message -
>> This was an immediate goal, the bare-metal nova-compute node could
>> keep an internal database, but report capabilities through nova in the
>> common way with the changes below. Then the scheduler wouldn't need
>> access to the bare metal database at all.
>> 
>> On Aug 15, 2012, at 4:23 PM, David Kang  wrote:
>> 
>>> 
>>> Hi Vish,
>>> 
>>> Is this discussion for long-term goal or for this Folsom release?
>>> 
>>> We still believe that bare-metal database is needed
>>> because there is not an automated way how bare-metal nodes report
>>> their capabilities
>>> to their bare-metal nova-compute node.
>>> 
>>> Thanks,
>>> David
>>> 
 
 I am interested in finding a solution that enables bare-metal and
 virtualized requests to be serviced through the same scheduler
 where
 the compute_nodes table has a full view of schedulable resources.
 This
 would seem to simplify the end-to-end flow while opening up some
 additional use cases (e.g. dynamic allocation of a node from
 bare-metal to hypervisor and back).
 
 One approach would be to have a proxy running a single nova-compute
 daemon fronting the bare-metal nodes . That nova-compute daemon
 would
 report up many HostState objects (1 per bare-metal node) to become
 entries in the compute_nodes table and accessible through the
 scheduler HostManager object.
 
 
 
 
 The HostState object would set cpu_info, vcpus, member_mb and
 local_gb
 values to be used for scheduling with the hypervisor_host field
 holding the bare-metal machine address (e.g. for IPMI based
 commands)
 and hypervisor_type = NONE. The bare-metal Flavors are created with
 an
 extra_spec of hypervisor_type= NONE and the corresponding
 compute_capabilities_filter would reduce the available hosts to
 those
 bare_metal nodes. The scheduler would need to understand that
 hypervisor_type = NONE means you need an exact fit (or best-fit)
 host
 vs weighting them (perhaps through the multi-scheduler). The
 scheduler
 would cast out the message to the . (code
 today uses the HostState hostname), with the compute driver having
 to
 understand if it must be serviced elsewhere (but does not break any
 existing implementations since it is 1 to 1).
 
 
 
 
 
 Does this solution seem workable? Anything I missed?
 
 The bare metal driver already is proxying for the other nodes so it
 sounds like we need a couple of things to make this happen:
 
 
 a) modify driver.get_host_stats to be able to return a list of host
 stats instead of just one. Report the whole list back to the
 scheduler. We could modify the receiving end to accept a list as
 well
 or just make multiple calls to
 self.update_service_capabilities(capabilities)
 
 
 b) make a few minor changes to the scheduler to make sure filtering
 still works. Note the changes here may be very helpful:
 
 
 https://review.openstack.org/10327
 
 
 c) we have to make sure that instances launched on those nodes take
 up
 the entire host state somehow. We could probably do this by making
 sure that the instance_type ram, mb, gb etc. matches what the node
 has, but we may want a new boolean field "used" if those aren't
 sufficient.
 
 
 I This approach seems pretty good. We could potentially get rid of
 the
 shared bare_metal_node table. I guess the only other concern is how
 you populate the capabilities that the bare metal nodes are
 reporting.
 I guess an 

[Openstack] Translation, Internationalization and Localization in OpenStack

[Gabriel Hurley]

In conjunction with the PTLs, the Docs team, the Infrastructure team, various 
community members and more, I'm very happy to say that we are ready to share 
out a complete set of documentation and processes for translation, 
internationalization, and localization for OpenStack as a whole. The document 
lives on the wiki here:

http://wiki.openstack.org/Translations

The critical infrastructure is already in place, and Nova, Horizon, Keystone 
and Docs are already up and running with the new processes (and have been 
successfully for a little while now).

Of immediate importance is the fact that we are technically under string freeze 
right now, so (as Thierry pointed out at the meeting earlier today) any review 
that alters strings marked for translation should be flagged and requires 
special consideration and coordination with translators before being merged. 
The string freeze gives translators a period of time before a release in which 
translations do not change so they can complete their work properly.

Comments and critiques of the process are welcome, but let's keep them on the 
mailing list before making edits to the wiki page.

Obviously we'll continue to refine this over time.

Thanks, and happy translating!

- Gabriel


___
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] [openstack-dev] Translation, Internationalization and Localization in OpenStack

[Matt Joyce]

I've already put a dent in the pt / pt_br translations for horizon.  I'd
love some assistance though.  Especially since my portuguese is secondary
and honestly not very fluent.

-Matt

On Tue, Aug 21, 2012 at 6:07 PM, Gabriel Hurley
wrote:

> In conjunction with the PTLs, the Docs team, the Infrastructure team,
> various community members and more, I'm very happy to say that we are ready
> to share out a complete set of documentation and processes for translation,
> internationalization, and localization for OpenStack as a whole. The
> document lives on the wiki here:
>
> http://wiki.openstack.org/Translations
>
> The critical infrastructure is already in place, and Nova, Horizon,
> Keystone and Docs are already up and running with the new processes (and
> have been successfully for a little while now).
>
> Of immediate importance is the fact that we are technically under string
> freeze right now, so (as Thierry pointed out at the meeting earlier today)
> any review that alters strings marked for translation should be flagged and
> requires special consideration and coordination with translators before
> being merged. The string freeze gives translators a period of time before a
> release in which translations do not change so they can complete their work
> properly.
>
> Comments and critiques of the process are welcome, but let's keep them on
> the mailing list before making edits to the wiki page.
>
> Obviously we'll continue to refine this over time.
>
> Thanks, and happy translating!
>
> - Gabriel
>
>
> ___
> OpenStack-dev mailing list
> openstack-...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
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] [openstack-dev] Discussion about where to put database for bare-metal provisioning (review 10726)

[Vishvananda Ishaya]

To elaborate, something the below. I'm not absolutely sure you need to be able 
to set service_name and host, but this gives you the option to do so if needed.

iff --git a/nova/manager.py b/nova/manager.py
index c6711aa..c0f4669 100644
--- a/nova/manager.py
+++ b/nova/manager.py
@@ -217,6 +217,8 @@ class SchedulerDependentManager(Manager):
 
 def update_service_capabilities(self, capabilities):
 """Remember these capabilities to send on next periodic update."""
+if not isinstance(capabilities, list):
+capabilities = [capabilities]
 self.last_capabilities = capabilities
 
 @periodic_task
@@ -224,5 +226,8 @@ class SchedulerDependentManager(Manager):
 """Pass data back to the scheduler at a periodic interval."""
 if self.last_capabilities:
 LOG.debug(_('Notifying Schedulers of capabilities ...'))
-self.scheduler_rpcapi.update_service_capabilities(context,
-self.service_name, self.host, self.last_capabilities)
+for capability_item in self.last_capabilities:
+name = capability_item.get('service_name', self.service_name)
+host = capability_item.get('host', self.host)
+self.scheduler_rpcapi.update_service_capabilities(context,
+name, host, capability_item)

On Aug 21, 2012, at 1:28 PM, David Kang  wrote:

> 
>  Hi Vish,
> 
>  We are trying to change our code according to your comment.
> I want to ask a question.
> 
 a) modify driver.get_host_stats to be able to return a list of host
 stats instead of just one. Report the whole list back to the
 scheduler. We could modify the receiving end to accept a list as
 well
 or just make multiple calls to
 self.update_service_capabilities(capabilities)
> 
>  Modifying driver.get_host_stats to return a list of host stats is easy.
> Calling muliple calls to self.update_service_capabilities(capabilities) 
> doesn't seem to work,
> because 'capabilities' is overwritten each time.
> 
>  Modifying the receiving end to accept a list seems to be easy.
> However, 'capabilities' is assumed to be dictionary by all other scheduler 
> routines,
> it looks like that we have to change all of them to handle 'capability' as a 
> list of dictionary.
> 
>  If my understanding is correct, it would affect many parts of the scheduler.
> Is it what you recommended?
> 
>  Thanks,
>  David
>  
> 
> - Original Message -
>> This was an immediate goal, the bare-metal nova-compute node could
>> keep an internal database, but report capabilities through nova in the
>> common way with the changes below. Then the scheduler wouldn't need
>> access to the bare metal database at all.
>> 
>> On Aug 15, 2012, at 4:23 PM, David Kang  wrote:
>> 
>>> 
>>> Hi Vish,
>>> 
>>> Is this discussion for long-term goal or for this Folsom release?
>>> 
>>> We still believe that bare-metal database is needed
>>> because there is not an automated way how bare-metal nodes report
>>> their capabilities
>>> to their bare-metal nova-compute node.
>>> 
>>> Thanks,
>>> David
>>> 
 
 I am interested in finding a solution that enables bare-metal and
 virtualized requests to be serviced through the same scheduler
 where
 the compute_nodes table has a full view of schedulable resources.
 This
 would seem to simplify the end-to-end flow while opening up some
 additional use cases (e.g. dynamic allocation of a node from
 bare-metal to hypervisor and back).
 
 One approach would be to have a proxy running a single nova-compute
 daemon fronting the bare-metal nodes . That nova-compute daemon
 would
 report up many HostState objects (1 per bare-metal node) to become
 entries in the compute_nodes table and accessible through the
 scheduler HostManager object.
 
 
 
 
 The HostState object would set cpu_info, vcpus, member_mb and
 local_gb
 values to be used for scheduling with the hypervisor_host field
 holding the bare-metal machine address (e.g. for IPMI based
 commands)
 and hypervisor_type = NONE. The bare-metal Flavors are created with
 an
 extra_spec of hypervisor_type= NONE and the corresponding
 compute_capabilities_filter would reduce the available hosts to
 those
 bare_metal nodes. The scheduler would need to understand that
 hypervisor_type = NONE means you need an exact fit (or best-fit)
 host
 vs weighting them (perhaps through the multi-scheduler). The
 scheduler
 would cast out the message to the . (code
 today uses the HostState hostname), with the compute driver having
 to
 understand if it must be serviced elsewhere (but does not break any
 existing implementations since it is 1 to 1).
 
 
 
 
 
 Does this solution seem workable? Anything I missed?
 
 The bare metal driver already is proxying for the other nodes so i