Re: [openstack-dev] [Keystone] [devstack] About _member_ role

2015-02-27 Thread Pasquale Porreca
As I said in your code review I don't really like an approach that
require saving a random generate id in the config file and a keystone
restart.
I would like you to review my proposal if you don't mind
https://review.openstack.org/156527

I think this is a quite important bug in devstack since it prevents
users to create or manage projects, so I would ask anyone interested -
especially devstack core reviewers - to give a look to the bug report
https://bugs.launchpad.net/devstack/+bug/1421616 and the proposed fixes.

On 02/27/15 06:38, Jamie Lennox wrote:

 - Original Message -
 From: Pasquale Porreca pasquale.porr...@dektech.com.au
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Thursday, February 19, 2015 3:24:03 AM
 Subject: Re: [openstack-dev] [Keystone] [devstack] About _member_ role

 Analyzing Horizon code I can confirm that the existence of _member_ role
 is required, so the commit https://review.openstack.org/#/c/150667/
 introduced the bug in devstack. More details and a fix proposal in my
 change submission: https://review.openstack.org/#/c/156527/

 On 02/18/15 10:04, Pasquale Porreca wrote:
 I saw 2 different bug report that Devstack dashboard gives an error when
 trying to manage projects
 https://bugs.launchpad.net/devstack/+bug/1421616 and
 https://bugs.launchpad.net/horizon/+bug/1421999
 In my devstack environment projects were working just fine, so I tried a
 fresh installation to see if I could reproduce the bug and I could
 confirm that actually the bug is present in current devstack deployment.
 Both reports point to the lack of _member_ role this error, so I just
 tried to manually (i.e. via CLI) add a _member_ role and I verified that
 just having it - even if not assigned to any user - fix the project
 management in Horizon.

 I didn't deeply analyze yet the root cause of this, but this behaviour
 seemed quite weird, this is the reason I sent this mail to dev list.
 Your explanation somewhat confirmed my doubts: I presume that adding a
 _member_ role is merely a workaround and the real bug is somewhere else
 - in Horizon code with highest chance.
 Ok, so I dug into this today. The problem is that the 'member_role_name' that 
 is set in keystone CONF is only being read that first time when it creates 
 the default member role if not already present. At all other times keystone 
 works with the role id set by 'member_role_id' which has a default value. So 
 even though horizon is looking and finding a member_role_name it doesn't 
 match up with what keystone is doing when it uses member_role_id. 

 IMO this is wrong and i filed a bug against keystone: 
 https://bugs.launchpad.net/keystone/+bug/1426184

 In the mean time it works if you add both the member_role_name and 
 member_role_id to the config file. Unfortunately adding an ID means you need 
 to get the value from keystone and then set it into keystone's own config 
 file, so restarting keystone. This is similar to a review I had for policy so 
 I modified that and put up my own review 
 https://review.openstack.org/#/c/159690

 Given the keystone restart I don't know if it's cleaner, however that's the 
 way i know to solve this 'properly'. 


 Jamie

 On 02/17/15 21:01, Jamie Lennox wrote:
 - Original Message -
 From: Pasquale Porreca pasquale.porr...@dektech.com.au
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Sent: Tuesday, 17 February, 2015 9:07:14 PM
 Subject: [openstack-dev]  [Keystone] [devstack] About _member_ role

 I proposed a fix for a bug in devstack
 https://review.openstack.org/#/c/156527/ caused by the fact the role
 _member_ was not anymore created due to a recent change.

 But why is the existence of _member_ role necessary, even if it is not
 necessary to be used? Is this a know/wanted feature or a bug by itself?
 So the way to be a 'member' of a project so that you can get a token
 scoped to that project is to have a role defined on that project.
 The way we would handle that from keystone for default_projects is to
 create a default role _member_ which had no permissions attached to it,
 but by assigning it to the user on the project we granted membership of
 that project.
 If the user has any other roles on the project then the _member_ role is
 essentially ignored.

 In that devstack patch I removed the default project because we want our
 users to explicitly ask for the project they want to be scoped to.
 This patch shouldn't have caused any issues though because in each of
 those cases the user is immediately granted a different role on the
 project - therefore having 'membership'.

 Creating the _member_ role manually won't cause any problems, but what
 issue are you seeing where you need it?


 Jamie


 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr

Re: [openstack-dev] Name field marked mandatory on Horizon

2015-02-25 Thread Pasquale Porreca
I think these inconsistencies are valid bugs, in fact for volume names a
proposed fix has been merged yet:
https://bugs.launchpad.net/horizon/+bug/1389172

For image name there is a report for this kind of bug:
https://bugs.launchpad.net/horizon/+bug/1420809 I am anyway not sure if
it is being worked on.

On 02/25/15 06:49, Yamini Sardana wrote:
 Hello all,

 For creating Networks, Images, Volumes etc, the name field is marked
 as mandatory on the Horizon UI whereas, in their corresponding create
 commands on the cli it is an optional field ( which is as per the API
 reference documents)

 Why is this inconsistency?

 Secondly, when we create a network/Image/Volume from the cli without
 any name and view it on Horizon, it shows its auto-generated ID in the
 name column which is confusing. Can we not display another ID column
 and display the ID in that column, similar to what we do in cli 'show'
 commands.

 I have already raised this bug on Horizon for network create option (
 https://bugs.launchpad.net/horizon/+bug/1424595) and if this is a
 valid one will raise on the rest as well.

 Please suggest.

 Best Regards
 Yamini Sardana
 Tata Consultancy Services
 Ground to 8th Floors, Building No. 1  2,
 Skyview Corporate Park, Sector 74A,NH 8
 Gurgaon - 122 004,Haryana
 India
 Ph:- +91 124 6213082
 Mailto: yamini.sard...@tcs.com
 Website: http://www.tcs.com http://www.tcs.com/
 
 Experience certainty.IT Services
Business Solutions
Consulting
 

 =-=-=
 Notice: The information contained in this e-mail
 message and/or attachments to it may contain
 confidential or privileged information. If you are
 not the intended recipient, any dissemination, use,
 review, distribution, printing or copying of the
 information contained in this e-mail message
 and/or attachments to it are strictly prohibited. If
 you have received this communication in error,
 please notify us by reply e-mail or telephone and
 immediately and permanently delete the message
 and any attachments. Thank you



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Keystone] [devstack] About _member_ role

2015-02-18 Thread Pasquale Porreca
I saw 2 different bug report that Devstack dashboard gives an error when
trying to manage projects
https://bugs.launchpad.net/devstack/+bug/1421616 and
https://bugs.launchpad.net/horizon/+bug/1421999
In my devstack environment projects were working just fine, so I tried a
fresh installation to see if I could reproduce the bug and I could
confirm that actually the bug is present in current devstack deployment.
Both reports point to the lack of _member_ role this error, so I just
tried to manually (i.e. via CLI) add a _member_ role and I verified that
just having it - even if not assigned to any user - fix the project
management in Horizon.

I didn't deeply analyze yet the root cause of this, but this behaviour
seemed quite weird, this is the reason I sent this mail to dev list.
Your explanation somewhat confirmed my doubts: I presume that adding a
_member_ role is merely a workaround and the real bug is somewhere else
- in Horizon code with highest chance.

On 02/17/15 21:01, Jamie Lennox wrote:

 - Original Message -
 From: Pasquale Porreca pasquale.porr...@dektech.com.au
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Tuesday, 17 February, 2015 9:07:14 PM
 Subject: [openstack-dev]  [Keystone] [devstack] About _member_ role

 I proposed a fix for a bug in devstack
 https://review.openstack.org/#/c/156527/ caused by the fact the role
 _member_ was not anymore created due to a recent change.

 But why is the existence of _member_ role necessary, even if it is not
 necessary to be used? Is this a know/wanted feature or a bug by itself?
 So the way to be a 'member' of a project so that you can get a token scoped 
 to that project is to have a role defined on that project. 
 The way we would handle that from keystone for default_projects is to create 
 a default role _member_ which had no permissions attached to it, but by 
 assigning it to the user on the project we granted membership of that project.
 If the user has any other roles on the project then the _member_ role is 
 essentially ignored. 

 In that devstack patch I removed the default project because we want our 
 users to explicitly ask for the project they want to be scoped to.
 This patch shouldn't have caused any issues though because in each of those 
 cases the user is immediately granted a different role on the project - 
 therefore having 'membership'. 

 Creating the _member_ role manually won't cause any problems, but what issue 
 are you seeing where you need it?


 Jamie


 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Keystone] [devstack] About _member_ role

2015-02-18 Thread Pasquale Porreca
Analyzing Horizon code I can confirm that the existence of _member_ role
is required, so the commit https://review.openstack.org/#/c/150667/
introduced the bug in devstack. More details and a fix proposal in my
change submission: https://review.openstack.org/#/c/156527/

On 02/18/15 10:04, Pasquale Porreca wrote:
 I saw 2 different bug report that Devstack dashboard gives an error when
 trying to manage projects
 https://bugs.launchpad.net/devstack/+bug/1421616 and
 https://bugs.launchpad.net/horizon/+bug/1421999
 In my devstack environment projects were working just fine, so I tried a
 fresh installation to see if I could reproduce the bug and I could
 confirm that actually the bug is present in current devstack deployment.
 Both reports point to the lack of _member_ role this error, so I just
 tried to manually (i.e. via CLI) add a _member_ role and I verified that
 just having it - even if not assigned to any user - fix the project
 management in Horizon.

 I didn't deeply analyze yet the root cause of this, but this behaviour
 seemed quite weird, this is the reason I sent this mail to dev list.
 Your explanation somewhat confirmed my doubts: I presume that adding a
 _member_ role is merely a workaround and the real bug is somewhere else
 - in Horizon code with highest chance.

 On 02/17/15 21:01, Jamie Lennox wrote:
 - Original Message -
 From: Pasquale Porreca pasquale.porr...@dektech.com.au
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Tuesday, 17 February, 2015 9:07:14 PM
 Subject: [openstack-dev]  [Keystone] [devstack] About _member_ role

 I proposed a fix for a bug in devstack
 https://review.openstack.org/#/c/156527/ caused by the fact the role
 _member_ was not anymore created due to a recent change.

 But why is the existence of _member_ role necessary, even if it is not
 necessary to be used? Is this a know/wanted feature or a bug by itself?
 So the way to be a 'member' of a project so that you can get a token scoped 
 to that project is to have a role defined on that project. 
 The way we would handle that from keystone for default_projects is to create 
 a default role _member_ which had no permissions attached to it, but by 
 assigning it to the user on the project we granted membership of that 
 project.
 If the user has any other roles on the project then the _member_ role is 
 essentially ignored. 

 In that devstack patch I removed the default project because we want our 
 users to explicitly ask for the project they want to be scoped to.
 This patch shouldn't have caused any issues though because in each of those 
 cases the user is immediately granted a different role on the project - 
 therefore having 'membership'. 

 Creating the _member_ role manually won't cause any problems, but what issue 
 are you seeing where you need it?


 Jamie


 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Keystone] [devstack] About _member_ role

2015-02-17 Thread Pasquale Porreca
I proposed a fix for a bug in devstack
https://review.openstack.org/#/c/156527/ caused by the fact the role
_member_ was not anymore created due to a recent change.

But why is the existence of _member_ role necessary, even if it is not
necessary to be used? Is this a know/wanted feature or a bug by itself?

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [nova] Flavor extra-spec and image metadata documentation

2015-02-11 Thread Pasquale Porreca
Hello

I am working on a little patch that introduce a new flavor extra-spec
and image metadata key-value pair https://review.openstack.org/#/c/153607/

I am wondering how an openstack admin can be aware that a specific value
of a flavor extra-spec or image metadata provides a feature he may
desire, in other words is there a place where the flavor extra-specs
and/or image metadata key-value pairs are documented?

I found plenty of documentation on how to list, create, delete, etc.
flavor extra-spec and image metadata, but the only place where I found a
list (is that complete?) of the accepted (i.e. that trigger specific
feature in nova) key-value pairs is in horizon dashboard, when logged
with admin credential.

I am a bit confused on how someone working to add a new key/value pair
should proceed. 

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Flavor extra-spec and image metadata documentation

2015-02-11 Thread Pasquale Porreca
Thank you for all answers.
I know that meta data tags are free to use with any key/value, still
there are some specific values that triggers pieces of code in nova (or
maybe even in other components). In particular I am working on one of
these key/value, in my case it should enable the

bios rebootTimeout=value/

parameter in libvirt. Anyway even if my code is merged, no one will know
about it (except myself and the reviewers) if it is not documented
somewhere. A DocImpact flag was added to the commit message, but I still
don't know how to proper document it. I may create/update existing wiki
pages, but I would have preferred an official documentation: I was not
able to find the wiki page proposed by Daniel Berrange, even if I had
been searching exactly to something similar :(
It is very good that there is a work to objectify image meta, anyway is
there any recommendation  how to document it in the meanwhile?

I would also know if there is any naming convention for image meta and
flavor extra-spec keys: in my case I used hw_reboot_timeoutand
hw:reboot_timeout respectively, but it is more a bios than hardware
feature and they are handled in nova/virt/libvirt/driver.py rather than
nova/virt/hardware.py so maybe the name choice was not so good.

On 02/11/15 11:25, Bhandaru, Malini K wrote:
 Pasquale Porreca,
 The flexibility/ freedom to create meta data tags for images and Nova flavor 
 extra specs can be confusing. Even allows one to make typographical errors 
 that may be hard to detect.
 As Daniel mentions, some tags have a definite meaning/semantics, others can 
 be totally random.
 Tags with semantic significance will typically be handled by special purpose 
 filters, look in Nova/filters directory, 
 /opt/stack/nova/nova/scheduler/filters
 The filters documentation in Nova admin guide may help too.
 All the rest are just matched as strings.
 Hope that helps.
 Regards
 Malini
  

 -Original Message-
 From: Kashyap Chamarthy [mailto:kcham...@redhat.com] 
 Sent: Wednesday, February 11, 2015 2:14 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [nova] Flavor extra-spec and image metadata 
 documentation

 On Wed, Feb 11, 2015 at 10:23:54AM +0100, Pasquale Porreca wrote:
 Hello

 I am working on a little patch that introduce a new flavor extra-spec 
 and image metadata key-value pair 
 https://review.openstack.org/#/c/153607/

 I am wondering how an openstack admin can be aware that a specific 
 value of a flavor extra-spec or image metadata provides a feature he 
 may desire, in other words is there a place where the flavor 
 extra-specs and/or image metadata key-value pairs are documented?
 Unfortunately, there's none as of now. I found this the hard way that you 
 cannot trivially find all possible 'extra_spec' key values that can be set by 
 `nova flavor-key`

 I did gross things like this:

 $ grep hw\: nova/virt/hardware.py nova/tests/unit/virt/test_hardware.py | 
 sort | uniq

 And, obviously the above will only find you 'hw' properties.

 Daniel Berrangé once suggested that image properties and flavor extra specs 
 need to be 'objectified' to alleviate this.

 I found plenty of documentation on how to list, create, delete, etc.
 flavor extra-spec and image metadata, but the only place where I found 
 a list (is that complete?) of the accepted (i.e. that trigger specific 
 feature in nova) key-value pairs is in horizon dashboard, when logged 
 with admin credential.

 I am a bit confused on how someone working to add a new key/value pair 
 should proceed.

 --
 /kashyap

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Flavor extra-spec and image metadata documentation

2015-02-11 Thread Pasquale Porreca
Thank you very much for the clarification :)

On 02/11/15 12:15, Daniel P. Berrange wrote:
 On Wed, Feb 11, 2015 at 12:03:58PM +0100, Pasquale Porreca wrote:
 Thank you for all answers.
 I know that meta data tags are free to use with any key/value, still
 there are some specific values that triggers pieces of code in nova (or
 maybe even in other components). In particular I am working on one of
 these key/value, in my case it should enable the

 bios rebootTimeout=value/

 parameter in libvirt. Anyway even if my code is merged, no one will know
 about it (except myself and the reviewers) if it is not documented
 somewhere. A DocImpact flag was added to the commit message, but I still
 don't know how to proper document it. I may create/update existing wiki
 pages, but I would have preferred an official documentation: I was not
 able to find the wiki page proposed by Daniel Berrange, even if I had
 been searching exactly to something similar :(
 It is very good that there is a work to objectify image meta, anyway is
 there any recommendation  how to document it in the meanwhile?
 For people submitting patches to nova the expectation is simply that they
 add DocImpact and have a commit message that describes the usage of the
 new property. The docs team work from this data. There's no current formal
 docs that I'd expect you to be editing/updating.

 I would also know if there is any naming convention for image meta and
 flavor extra-spec keys: in my case I used hw_reboot_timeoutand
 hw:reboot_timeout respectively, but it is more a bios than hardware
 feature and they are handled in nova/virt/libvirt/driver.py rather than
 nova/virt/hardware.py so maybe the name choice was not so good.
 In terms of image metadata, broadly speaking, we're aiming to standardize
 on 3 name prefixes in Nova

  'hw' - stuff that affects guest hardware configuration (this includes
 the BIOS settings, since that's hardware firmware)
  'os' - stuff that affects the guest operating system setup
  'img' - stuff Nova uses related to managing images

 So, your choice of 'hw_reboot_timeout' for image and 'hw:reboot_timeout'
 for the flavour  is correct.

 Regards,
 Daniel

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Kilo devstack issue

2015-01-13 Thread Pasquale Porreca
I had the same issue and, as John Griffith pointed out, it is due to the
fact n-novnvc service is no more a default service in devstack. You need
to enable the service in local.conf file by adding the line

|enable_service n-novnc|


On 01/12/15 20:21, John Griffith wrote:
 On Mon, Jan 12, 2015 at 10:03 AM, Nikesh Kumar Mahalka
 nikeshmaha...@vedams.com wrote:
 Hi,
 We deployed a kilo devstack on ubuntu 14.04 server.
 We successfully launched a instance from dashboard, but we are unable to
 open console from dashboard for instance.Also instacne is unable to get ip

 Below is link for local.conf
 http://paste.openstack.org/show/156497/



 Regards
 Nikesh

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 Correct, see this thread:
 http://lists.openstack.org/pipermail/openstack-dev/2015-January/054157.html

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 答复: [devstack] Opensatck installation issue.

2015-01-12 Thread Pasquale Porreca
Since it seems a permission error, this may help:
http://docs.openstack.org/developer/devstack/guides/single-machine.html#installation-shake-and-bake

NB: in my environment I had to edit the file sudoers with a text editor
(echoing the string didn't work).


On 01/12/15 09:33, Abhishek Shrivastava wrote:
 Hi all,

 I am still getting the same error while installing the Openstack
 through devstack, If someone know the solution please reply.

 On Fri, Jan 9, 2015 at 1:53 PM, Abhishek Shrivastava
 abhis...@cloudbyte.com mailto:abhis...@cloudbyte.com wrote:

 Hi Liuxinguo,

 Thanks for the suggestion, I'll try and make it work.

 On Fri, Jan 9, 2015 at 1:24 PM, liuxinguo liuxin...@huawei.com
 mailto:liuxin...@huawei.com wrote:

 Hi Abhishek,

  

 For the error in the first line:

 “mkdir: cannot create directory `/logs': Permission denied”

 and the error at the end:

 “ln: failed to create symbolic link
 `/logs/screen/screen-key.log': No such file or directory”

  

 The stack user does not have the permission on “/” so it can
 not create directory `/logs'.

  

 Please check the permission.

  

 liu

  

 *发件人:*Abhishek Shrivastava [mailto:abhis...@cloudbyte.com
 mailto:abhis...@cloudbyte.com]
 *发 送时间:*2015年1月9日15:26
 *收件人:*OpenStack Development Mailing List (not for usage
 questions)
 *主题:*[openstack-dev] [devstack] Opensatck installation issue.

  

 Hi,

  

 I'm trying to install *Openstack//*through*//devstack master*
 on my *Ubuntu* *12.04 VM*, but it is failing and generating
 the following error.

  

 If anyone can help me resolving this issue please do reply.

  

 -- 

 *Thanks  Regards,*

 *Abhishek*


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 -- 
 *Thanks  Regards,
 *
 *Abhishek*




 -- 
 *Thanks  Regards,
 *
 *Abhishek*


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] #PERSONAL# : Git checkout command for Blueprints submission

2014-12-19 Thread Pasquale Porreca
I think you meant git checkout -b bp/bp_name :)

@Swati: when you commit, add the message:

Implements: blueprint bp_name

For more info you can give a look at gerrit workflow wiki:
https://wiki.openstack.org/wiki/Gerrit_Workflow


On 12/18/14 18:17, Edgar Magana wrote:
 It is git checkout -b bp/bp_number

 Edgar

 From: Swati Shukla1 swati.shuk...@tcs.com mailto:swati.shuk...@tcs.com
 Reply-To: openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Tuesday, December 16, 2014 at 10:53 PM
 To: openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Subject: [openstack-dev] #PERSONAL# : Git checkout command for
 Blueprints submission


 Hi All,

 Generally, for bug submissions, we use git checkout -b
 bug/bug_number

 What is the similar 'git checkout' command for blueprints submission?

 Swati Shukla
 Tata Consultancy Services
 Mailto: swati.shuk...@tcs.com mailto:swati.shuk...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty. IT Services
 Business Solutions
 Consulting
 

 =-=-=
 Notice: The information contained in this e-mail
 message and/or attachments to it may contain
 confidential or privileged information. If you are
 not the intended recipient, any dissemination, use,
 review, distribution, printing or copying of the
 information contained in this e-mail message
 and/or attachments to it are strictly prohibited. If
 you have received this communication in error,
 please notify us by reply e-mail or telephone and
 immediately and permanently delete the message
 and any attachments. Thank you



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Complexity check and v2 API

2014-12-18 Thread Pasquale Porreca
Yes, for v2.1 there is not this problem, moreover v2.1 corresponding
server.py has much lower complexity than v2 one.

On 12/17/14 20:10, Christopher Yeoh wrote:
 Hi,

 Given the timing (no spec approved) it sounds like a v2.1 plus
 microversions (just merging) with no v2 changes at all.

 The v2.1 framework is more flexible and you should need no changes to
 servers.py at all as there are hooks for adding extra parameters in
 separate plugins. There are examples of this in the v3 directory which
 is really v2.1 now.

 Chris
 On Thu, 18 Dec 2014 at 3:49 am, Pasquale Porreca
 pasquale.porr...@dektech.com.au
 mailto:pasquale.porr...@dektech.com.au wrote:

 Thank you for the answer.

 my API proposal won't be merged in kilo release since the deadline for
 approval is tomorrow, so I may propose the fix to lower the complexity
 in another way, what do you think about a bug fix?

 On 12/17/14 18:05, Matthew Gilliard wrote:
  Hello Pasquale
 
The problem is that you are trying to add a new if/else branch
 into
  a method which is already ~250 lines long, and has the highest
  complexity of any function in the nova codebase. I assume that you
  didn't contribute much to that complexity, but we've recently
 added a
  limit to stop it getting any worse. So, regarding your 4
 suggestions:
 
  1/ As I understand it, v2.1 should be the same as v2 at the
  moment, so they need to be kept the same
  2/ You can't ignore it - it will fail CI
  3/ No thank you. This limit should only ever be lowered :-)
  4/ This is 'the right way'. Your suggestion for the refactor
 does
  sound good.
 
  I suggest a single patch that refactors and lowers the limit in
  tox.ini.  Once you've done that then you can add the new
 parameter in
  a following patch. Please feel free to add me to any patches you
  create.
 
  Matthew
 
 
 
  On Wed, Dec 17, 2014 at 4:18 PM, Pasquale Porreca
  pasquale.porr...@dektech.com.au
 mailto:pasquale.porr...@dektech.com.au wrote:
  Hello
 
  I am working on an API extension that adds a parameter on
 create server
  call; to implement the v2 API I added few lines of code to
  nova/api/openstack/compute/servers.py
 
  In particular just adding something like
 
  new_param = None
  if self.ext_mgr.is_loaded('os-new-param'):
  new_param = server_dict.get('new_param')
 
  leads to a pep8 fail with message 'Controller.create' is too
 complex (47)
  (Note that in tox.ini the max complexity is fixed to 47 and
 there is a note
  specifying 46 is the max complexity present at the moment).
 
  It is quite easy to make this test pass creating a new method
 just to
  execute these lines of code, anyway all other extensions are
 handled in that
  way and one of most important stylish rule states to be
 consistent with
  surrounding code, so I don't think a separate function is the
 way to go
  (unless it implies a change in how all other extensions are
 handled too).
 
  My thoughts on this situation:
 
  1) New extensions should not consider v2 but only v2.1, so that
 file should
  not be touched
  2) Ignore this error and go on: if and when the extension will
 be merged the
  complexity in tox.ini will be changed too
  3) The complexity in tox.ini should be raised to allow new v2
 extensions
  4) The code of that module should be refactored to lower the
 complexity
  (i.e. move the load of each extension in a separate function)
 
  I would like to know if any of my point is close to the correct
 solution.
 
  --
  Pasquale Porreca
 
  DEK Technologies
  Via dei Castelli Romani, 22
  00040 Pomezia (Roma)
 
  Mobile +39 3394823805
  Skype paskporr
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack

Re: [openstack-dev] [nova] Complexity check and v2 API

2014-12-18 Thread Pasquale Porreca
I created a bug  report and proposed a fix for this issue:

https://bugs.launchpad.net/nova/+bug/1403586

@Matthew Gilliard: I added you as reviewer for my patch, since you asked
for it.

Thanks to anyone that will want to review the bug report and the patch.

On 12/18/14 09:33, Pasquale Porreca wrote:
 Yes, for v2.1 there is not this problem, moreover v2.1 corresponding
 server.py has much lower complexity than v2 one.

 On 12/17/14 20:10, Christopher Yeoh wrote:
 Hi,

 Given the timing (no spec approved) it sounds like a v2.1 plus
 microversions (just merging) with no v2 changes at all.

 The v2.1 framework is more flexible and you should need no changes to
 servers.py at all as there are hooks for adding extra parameters in
 separate plugins. There are examples of this in the v3 directory
 which is really v2.1 now.

 Chris
 On Thu, 18 Dec 2014 at 3:49 am, Pasquale Porreca
 pasquale.porr...@dektech.com.au
 mailto:pasquale.porr...@dektech.com.au wrote:

 Thank you for the answer.

 my API proposal won't be merged in kilo release since the
 deadline for
 approval is tomorrow, so I may propose the fix to lower the
 complexity
 in another way, what do you think about a bug fix?

 On 12/17/14 18:05, Matthew Gilliard wrote:
  Hello Pasquale
 
The problem is that you are trying to add a new if/else
 branch into
  a method which is already ~250 lines long, and has the highest
  complexity of any function in the nova codebase. I assume that you
  didn't contribute much to that complexity, but we've recently
 added a
  limit to stop it getting any worse. So, regarding your 4
 suggestions:
 
  1/ As I understand it, v2.1 should be the same as v2 at the
  moment, so they need to be kept the same
  2/ You can't ignore it - it will fail CI
  3/ No thank you. This limit should only ever be lowered :-)
  4/ This is 'the right way'. Your suggestion for the
 refactor does
  sound good.
 
  I suggest a single patch that refactors and lowers the limit in
  tox.ini.  Once you've done that then you can add the new
 parameter in
  a following patch. Please feel free to add me to any patches you
  create.
 
  Matthew
 
 
 
  On Wed, Dec 17, 2014 at 4:18 PM, Pasquale Porreca
  pasquale.porr...@dektech.com.au
 mailto:pasquale.porr...@dektech.com.au wrote:
  Hello
 
  I am working on an API extension that adds a parameter on
 create server
  call; to implement the v2 API I added few lines of code to
  nova/api/openstack/compute/servers.py
 
  In particular just adding something like
 
  new_param = None
  if self.ext_mgr.is_loaded('os-new-param'):
  new_param = server_dict.get('new_param')
 
  leads to a pep8 fail with message 'Controller.create' is too
 complex (47)
  (Note that in tox.ini the max complexity is fixed to 47 and
 there is a note
  specifying 46 is the max complexity present at the moment).
 
  It is quite easy to make this test pass creating a new method
 just to
  execute these lines of code, anyway all other extensions are
 handled in that
  way and one of most important stylish rule states to be
 consistent with
  surrounding code, so I don't think a separate function is the
 way to go
  (unless it implies a change in how all other extensions are
 handled too).
 
  My thoughts on this situation:
 
  1) New extensions should not consider v2 but only v2.1, so
 that file should
  not be touched
  2) Ignore this error and go on: if and when the extension will
 be merged the
  complexity in tox.ini will be changed too
  3) The complexity in tox.ini should be raised to allow new v2
 extensions
  4) The code of that module should be refactored to lower the
 complexity
  (i.e. move the load of each extension in a separate function)
 
  I would like to know if any of my point is close to the
 correct solution.
 
  --
  Pasquale Porreca
 
  DEK Technologies
  Via dei Castelli Romani, 22
  00040 Pomezia (Roma)
 
  Mobile +39 3394823805
  Skype paskporr
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr

Re: [openstack-dev] [Neutron][Nova][DHCP] Use case of enable_dhcp option when creating a network

2014-12-17 Thread Pasquale Porreca
Just yesterday I asked a similar question on ML, this is the answer I got:

In Neutron IP address management and distribution are separated concepts.
IP addresses are assigned to ports even when DHCP is disabled. That IP
address is indeed used to configure anti-spoofing rules and security groups.

http://lists.openstack.org/pipermail/openstack-dev/2014-December/053069.html

On 12/17/14 09:15, Padmanabhan Krishnan wrote:
 Hello,
 I have a question regarding the enable_dhcp option when creating a
 network.

 When a VM is attached to  a network where enable_dhcp is False, I
 understand that the DHCP namespace is not created for the network and
 the VM does not get any IP address after it boots up and sends a DHCP
 Discover.
 But, I also see that the Neutron port is filled with the fixed IP
 value from the network pool even though there's no DHCP associated
 with the subnet. 
 So, for such VM's, does one need to statically configure the IP
 address with whatever Neutron has allocated from the pool?

 What exactly is the use case of the above? 

 I do understand that for providing public network access to VM's, an
 external network is generally created with enable-dhcp option set to
 False. Is it only for this purpose?

 I was thinking of a case of external/provider DHCP servers from where
 VM's can get their IP addresses and when one does not want to use L3
 agent/DVR. In such cases, one may want to disable DHCP when creating
 networks.  Isn't this a use-case?

 Appreciate any response or corrections with my above understanding.

 Thanks,
 Paddu 



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [nova] Complexity check and v2 API

2014-12-17 Thread Pasquale Porreca
Hello

I am working on an API extension that adds a parameter on create server
call; to implement the v2 API I added few lines of code to
nova/api/openstack/compute/servers.py

In particular just adding something like

|new_param = None||
||if self.ext_mgr.is_loaded('os-new-param'):||
||new_param = server_dict.get('new_param')|

leads to a pep8 fail with message 'Controller.create' is too complex (47)
(Note that in tox.ini the max complexity is fixed to 47 and there is a
note specifying 46 is the max complexity present at the moment).

It is quite easy to make this test pass creating a new method just to
execute these lines of code, anyway all other extensions are handled in
that way and one of most important stylish rule states to be consistent
with surrounding code, so I don't think a separate function is the way
to go (unless it implies a change in how all other extensions are
handled too).

My thoughts on this situation:

1) New extensions should not consider v2 but only v2.1, so that file
should not be touched
2) Ignore this error and go on: if and when the extension will be merged
the complexity in tox.ini will be changed too
3) The complexity in tox.ini should be raised to allow new v2 extensions
4) The code of that module should be refactored to lower the complexity
(i.e. move the load of each extension in a separate function)

I would like to know if any of my point is close to the correct solution.

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Complexity check and v2 API

2014-12-17 Thread Pasquale Porreca
Thank you for the answer.

my API proposal won't be merged in kilo release since the deadline for
approval is tomorrow, so I may propose the fix to lower the complexity
in another way, what do you think about a bug fix?

On 12/17/14 18:05, Matthew Gilliard wrote:
 Hello Pasquale

   The problem is that you are trying to add a new if/else branch into
 a method which is already ~250 lines long, and has the highest
 complexity of any function in the nova codebase. I assume that you
 didn't contribute much to that complexity, but we've recently added a
 limit to stop it getting any worse. So, regarding your 4 suggestions:

 1/ As I understand it, v2.1 should be the same as v2 at the
 moment, so they need to be kept the same
 2/ You can't ignore it - it will fail CI
 3/ No thank you. This limit should only ever be lowered :-)
 4/ This is 'the right way'. Your suggestion for the refactor does
 sound good.

 I suggest a single patch that refactors and lowers the limit in
 tox.ini.  Once you've done that then you can add the new parameter in
 a following patch. Please feel free to add me to any patches you
 create.

 Matthew



 On Wed, Dec 17, 2014 at 4:18 PM, Pasquale Porreca
 pasquale.porr...@dektech.com.au wrote:
 Hello

 I am working on an API extension that adds a parameter on create server
 call; to implement the v2 API I added few lines of code to
 nova/api/openstack/compute/servers.py

 In particular just adding something like

 new_param = None
 if self.ext_mgr.is_loaded('os-new-param'):
 new_param = server_dict.get('new_param')

 leads to a pep8 fail with message 'Controller.create' is too complex (47)
 (Note that in tox.ini the max complexity is fixed to 47 and there is a note
 specifying 46 is the max complexity present at the moment).

 It is quite easy to make this test pass creating a new method just to
 execute these lines of code, anyway all other extensions are handled in that
 way and one of most important stylish rule states to be consistent with
 surrounding code, so I don't think a separate function is the way to go
 (unless it implies a change in how all other extensions are handled too).

 My thoughts on this situation:

 1) New extensions should not consider v2 but only v2.1, so that file should
 not be touched
 2) Ignore this error and go on: if and when the extension will be merged the
 complexity in tox.ini will be changed too
 3) The complexity in tox.ini should be raised to allow new v2 extensions
 4) The code of that module should be refactored to lower the complexity
 (i.e. move the load of each extension in a separate function)

 I would like to know if any of my point is close to the correct solution.

 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Neutron] fixed ip info shown for port even when dhcp is disabled

2014-12-16 Thread Pasquale Porreca
Is there a specific reason for which a fixed ip is bound to a port on a
subnet where dhcp is disabled? it is confusing to have this info shown
when the instance doesn't have actually an ip on that port.
Should I fill a bug report, or is this a wanted behavior?

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [NFV][Telco] pxe-boot

2014-12-12 Thread Pasquale Porreca
From my point of view it is not advisable to base some functionalities
of the instances on direct calls to Openstack API. This for 2 main
reasons, the first one: if the Openstack code changes (and we know
Openstack code does change) it will be required to change the code of
the software running in the instance too; the second one: if in the
future one wants to pass to another cloud infrastructure it will be more
difficult to achieve it.

On 12/12/14 01:20, Joe Gordon wrote:
 On Wed, Dec 10, 2014 at 7:42 AM, Pasquale Porreca 
 pasquale.porr...@dektech.com.au wrote:
 
   Well, one of the main reason to choose an open source product is to avoid
  vendor lock-in. I think it is not
  advisable to embed in the software running in an instance a call to
  OpenStack specific services.
 
 I'm sorry I don't follow the logic here, can you elaborate.
 
 

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [NFV][Telco] pxe-boot

2014-12-12 Thread Pasquale Porreca
It is possible to decide in advance how many PL will be necessary for a
service, so their creation can be decided externally from the SC. Anyway
the role that any PL should assume and so the image to install on each
PL should be decided by the SC.

On 12/12/14 09:54, Steve Gordon wrote:
 - Original Message -
  From: Pasquale Porreca pasquale.porr...@dektech.com.au
  To: openstack-dev@lists.openstack.org
  
  Well, one of the main reason to choose an open source product is to
  avoid vendor lock-in. I think it is not
  
  advisable to embed in the software running in an instance a call to
  OpenStack specific services.
 Possibly a stupid question, but even if PXE boot was supported would the SC 
 not still have to trigger the creation of the PL instance(s) via a call to 
 Nova anyway (albeit with boot media coming from PXE instead of Glance)?

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [NFV][Telco] pxe-boot

2014-12-10 Thread Pasquale Porreca
Well, one of the main reason to choose an open source product is to 
avoid vendor lock-in. I think it is not
advisableto embed in the software running in an instance a call to 
OpenStack specific services.


On 12/10/14 00:20, Joe Gordon wrote:


On Wed, Dec 3, 2014 at 1:16 AM, Pasquale Porreca 
pasquale.porr...@dektech.com.au 
mailto:pasquale.porr...@dektech.com.au wrote:


The use case we were thinking about is a Network Function (e.g.
IMS Nodes) implementation in which the high availability is based
on OpenSAF. In this scenario there is an Active/Standby cluster of
2 System Controllers (SC) plus several Payloads (PL) that boot
from network, controlled by the SC. The logic of which service to
deploy on each payload is inside the SC.

In OpenStack both SCs and PLs will be instances running in the
cloud, anyway the PLs should still boot from network under the
control of the SC. In fact to use Glance to store the image for
the PLs and keep the control of the PLs in the SC, the SC should
trigger the boot of the PLs with requests to Nova/Glance, but an
application running inside an instance should not directly
interact with a cloud infrastructure service like Glance or Nova.


Why not? This is a fairly common practice.


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] V3 API support

2014-12-04 Thread Pasquale Porreca
v3 API is now moving to v2.1, but the definition of the api module and 
the json schema for v2.1 still go on v3 folder. I posted a question 
about v2 vs v3 API on this mailing list not long ago and got useful tips 
by Christopher Yeoh, maybe it will be useful for you too to give at 
check at them:


http://lists.openstack.org/pipermail/openstack-dev/2014-November/050711.html

On 12/04/14 13:50, Sergey Nikitin wrote:

Hi, Christopher,

I working on API extension for instance tags 
(https://review.openstack.org/#/c/128940/). Recently one reviewer 
asked me to add  V3 API support. I talked with Jay Pipes about it and 
he told me that V3 API became useless. So I wanted to ask you and our 
community: Do we need to support v3 API in future nova patches?




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [NFV][Telco] pxe-boot

2014-12-03 Thread Pasquale Porreca
The use case we were thinking about is a Network Function (e.g. IMS 
Nodes) implementation in which the high availability is based on 
OpenSAF. In this scenario there is an Active/Standby cluster of 2 System 
Controllers (SC) plus several Payloads (PL) that boot from network, 
controlled by the SC. The logic of which service to deploy on each 
payload is inside the SC.


In OpenStack both SCs and PLs will be instances running in the cloud, 
anyway the PLs should still boot from network under the control of the 
SC. In fact to use Glance to store the image for the PLs and keep the 
control of the PLs in the SC, the SC should trigger the boot of the PLs 
with requests to Nova/Glance, but an application running inside an 
instance should not directly interact with a cloud infrastructure 
service like Glance or Nova.


We know that it is yet possible to achieve network booting in OpenStack 
using an image stored in Glance that acts like a pxe client, anyway this 
workaround has some drawbacks, mainly due to the fact it won't be 
possible to choose the specific virtual NIC on which the network boot 
will happen, causing DHCP requests to flow on networks where they don't 
belong to and possible delays in the boot of the instances.


On 11/27/14 00:32, Steve Gordon wrote:

- Original Message -

From: Angelo Matarazzo angelo.matara...@dektech.com.au
To: OpenStack Development Mailing openstack-dev@lists.openstack.org, 
openstack-operat...@lists.openstack.org


Hi all,
my team and I are working on pxe boot feature very similar to the
Discless VM one  in Active blueprint list[1]
The blueprint [2] is no longer active and we created a new spec [3][4].

Nova core reviewers commented our spec and the first and the most
important objection is that there is not a compelling reason to
provide this kind of feature : booting from network.

Aside from the specific implementation, I think that some members of
TelcoWorkingGroup could be interested in  and provide a use case.
I would also like to add this item to the agenda of next meeting

Any thought?

We did discuss this today, and granted it is listed as a blueprint someone in 
the group had expressed interest in at a point in time - though I don't believe 
any further work was done. The general feeling was that there isn't anything 
really NFV or Telco specific about this over and above the more generic use 
case of legacy applications. Are you able to further elaborate on the reason 
it's NFV or Telco specific other than because of who is requesting it in this 
instance?

Thanks!

-Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] v2 or v3 for new api

2014-11-17 Thread Pasquale Porreca
Thank you for the clarification, yes I know about the 
blueprint/specification, I submitted yet them and the spec is currently 
under review :)


I noticed there are several steps one has always to do to enable and 
make a v3 api to work and pass the tests. It would be awesome to have a 
guideline or something similar that explain these steps, but I didn't 
find anything in wiki or documentation.


In particular I noticed I had to modify the file 
nova/nova.egg-info/entry_points.txt to make my v3 api to load, but this 
file seems not to be under versioning, is this file modified only after 
the changes are merged?


On 11/16/14 23:55, Christopher Yeoh wrote:
On Thu, Nov 13, 2014 at 12:14 AM, Pasquale Porreca 
pasquale.porr...@dektech.com.au 
mailto:pasquale.porr...@dektech.com.au wrote:


Hello

I am working on an api for a new feature in nova, but I am
wondering what is the correct way to add a new extension: should
it be supported by v2, v3 or both?


You need now to have at least a v2.1 (formerly known as v3) extension. 
V2 support if you want but I think once v2.1 is fully merged and 
tested (which may not be that far away at all) we should freeze v2 and 
rely just on v2.1 for new features. Otherwise the interaction between 
v2.1 being exactly equivalent to v2 plus having microversion support 
for v2.1 will get a bit confusing.
As the other Chris mentioned, the first step however is to get a 
nova-spec submitted which needs to fully describe the API additions 
that you want to make.


Regards,

Chris

BR

-- 
Pasquale Porreca


DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805 tel:%2B39%203394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] v2 or v3 for new api

2014-11-17 Thread Pasquale Porreca

Thank you very much Christopher

On 11/17/14 12:15, Christopher Yeoh wrote:
Yes, sorry documentation has been on our todo list for too long. Could 
I get you to submit a bug report about the lack of developer 
documentation for api plugins? It might hurry us up :-)


I reported as a bug and subscribed you to it. 
https://bugs.launchpad.net/nova/+bug/1393455




In the meantime, off the top of my head. you'll need to create or 
modify the following files in a typical plugin:


setup.cfg - add an entry in at least the nova.api.v3.extensions section

etc/nova/policy.json - an entry for the permissions for you plugin, 
perhaps one per api method for maximum flexibility. Also will need a 
discoverable entry (lots of examples in this file)


nova/tests/unit/fake_policy.json (similar to policy.json)


I wish I had asked about this before, I found yet these files, but I 
confess it took quite a bit of time to guess I had to modify them (I 
actually didn't modify yet fake_policy, but my tests are still not 
completed).

What about nova/nova.egg-info/entry_points.txt I mentioned earlier?



nova/api/openstack/compute/plugins/v3/your_plugin.py - please make 
the alias name something os-scheduler-hints rather than OS-SCH-HNTS. 
No skimping on vowels. Probably the easiest way at this stage without 
more doco is look for for a plugin in that directory that does the 
sort of the thing you want to do.


Following the path of other plugins, I created a module 
nova/api/openstack/compute/plugins/v3/node_uuid.py, while the class is 
NodeUuid(extensions.V3APIExtensionBase) the alias is os-node-uuid and 
the actual json parameter is node_uuid. I hope this is correct...




nova/tests/unit/nova/api/openstack/compute/contrib/test_your_plugin.py 
- we have been combining the v2 and v2.1(v3) unittests to share as 
much as possible, so please do the same here for new tests as the v3 
directory will be eventually removed. There's quite a few examples now 
in that directory of sharing unittests between v2.1 and v2 but with a 
new extension the customisation between the two should be pretty 
minimal (just a bit of inheritance to call the right controller)




Very good to know. I put my test in 
nova/tests/unit/api/openstack/plugins/v3 , but I was getting confused by 
the fact only few tests were in this folder while the tests in 
nova/tests/unit/api/openstack/compute/contrib/ covered both v2 and v2.1 
cases.
So should I move my test in 
nova/tests/unit/api/openstack/compute/contrib/ folder, right?



nova/tests/unit/integrated/v3/test_your_plugin.py
nova/tests/unit/integrated/test_api_samples.py

Sorry the api samples tests are not unified yet. So you'll need to 
create two. All of the v2 api sample tests are in one directory, 
whilst the the v2.1 are separated into different files by plugin.


There's some rather old documentation on how to generate the api 
samples themselves (hint: directories aren't made automatically) here:


https://blueprints.launchpad.net/nova/+spec/nova-api-samples

Personally I wouldn't bother with any xml support if you do decide to 
support v2 as its deprecated anyway.


After reading your answer I understood I have to work more on this part :)



Hope this helps. Feel free to add me as a reviewer for the api parts 
of your changesets.


It helps a lot! I will add you for sure as soon as I will upload my 
code. For now the specification has still to be approved, so I think I 
have to wait before to upload it, is that correct?


This is the blueprint link anyway: 
https://blueprints.launchpad.net/nova/+spec/use-uuid-v1




Regards,

Chris


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova] v2 or v3 for new api

2014-11-12 Thread Pasquale Porreca

Hello

I am working on an api for a new feature in nova, but I am wondering 
what is the correct way to add a new extension: should it be supported 
by v2, v3 or both?


BR

--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Create an instance with a custom uuid

2014-10-01 Thread Pasquale Porreca

Thank you for the answers.

I understood the concerns about having the UUID completely user defined 
and I also understand Nova has no interest in supporting a customized 
algorithm to generate UUID. Anyway I may have found a solution that will 
cover my use case and respect the standard for UUID (RFC 4122 
http://www.ietf.org/rfc/rfc4122.txt) .


The generation of the UUID in Nova make use of the function /uuid4()/ 
from the module /uuid.py/ to have an UUID (pseudo)random, according to 
version 4 described in RFC 4122. Anyway this is not the only algorithm 
supported in the standard (and implemented yet in /uuid.py/).


In particular I focused my attention on UUID version 1 and the method 
/uuid1(node=None, clock_seq=None)/ that allows to pass as parameter a 
part of the UUID (/node/ is the field containing the last 12 hexadecimal 
digits of the UUID).


So my idea was to give the chance to the user to set uiid version (1 or 
4, with the latter as default) when creating a new instance and in case 
of version 1  to pass optionally a value for parameter /node/.


Any thoughts?

On 09/30/14 14:07, Andrew Laski wrote:


On 09/30/2014 06:53 AM, Pasquale Porreca wrote:

Going back to my original question, I would like to know:

1) Is it acceptable to have the UUID passed from client side?


In my opinion, no.  This opens a door to issues we currently don't 
need to deal with, and use cases I don't think Nova should support. 
Another possibility, which I don't like either, would be to pass in 
some data which could influence the generation of the UUID to satisfy 
requirements.


But there was a suggestion to look into addressing your use case on 
the QEMU mailing list, which I think would be a better approach.




2) What is the correct way to do it? I started to implement this 
feature, simply passing it as metadata with key uuid, but I feel that 
this feature should have a reserved option rather then use metadata.



On 09/25/14 17:26, Daniel P. Berrange wrote:

On Thu, Sep 25, 2014 at 05:23:22PM +0200, Pasquale Porreca wrote:

This is correct Daniel, except that that it is done by the virtual
firmware/BIOS of the virtual machine and not by the OS (not yet 
installed at

that time).

This is the reason we thought about UUID: it is yet used by the 
iPXE client
to be included in Bootstrap Protocol messages, it is taken from the 
uuid
field in libvirt template and the uuid in libvirt is set by 
OpenStack; the
only missing passage is the chance to set the UUID in OpenStack 
instead to

have it randomly generated.

Having another user defined tag in libvirt won't help for our 
issue, since
it won't be included in Bootstrap Protocol messages, not without 
changes in
the virtual BIOS/firmware (as you stated too) and honestly my team 
doesn't

have interest in this (neither the competence).

I don't think the configdrive or metadata service would help 
either: the OS
on the instance is not yet installed at that time (the target if 
the network
boot is exactly to install the OS on the instance!), so it won't be 
able to

mount it.

Ok, yes, if we're considering the DHCP client inside the iPXE BIOS
blob, then I don't see any currently viable options besides UUID.
There's no mechanism for passing any other data into iPXE that I
am aware of, though if there is a desire todo that it could be
raised on the QEMU mailing list for discussion.


Regards,
Daniel





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Create an instance with a custom uuid

2014-09-30 Thread Pasquale Porreca

Going back to my original question, I would like to know:

1) Is it acceptable to have the UUID passed from client side?

2) What is the correct way to do it? I started to implement this 
feature, simply passing it as metadata with key uuid, but I feel that 
this feature should have a reserved option rather then use metadata.



On 09/25/14 17:26, Daniel P. Berrange wrote:

On Thu, Sep 25, 2014 at 05:23:22PM +0200, Pasquale Porreca wrote:

This is correct Daniel, except that that it is done by the virtual
firmware/BIOS of the virtual machine and not by the OS (not yet installed at
that time).

This is the reason we thought about UUID: it is yet used by the iPXE client
to be included in Bootstrap Protocol messages, it is taken from the uuid
field in libvirt template and the uuid in libvirt is set by OpenStack; the
only missing passage is the chance to set the UUID in OpenStack instead to
have it randomly generated.

Having another user defined tag in libvirt won't help for our issue, since
it won't be included in Bootstrap Protocol messages, not without changes in
the virtual BIOS/firmware (as you stated too) and honestly my team doesn't
have interest in this (neither the competence).

I don't think the configdrive or metadata service would help either: the OS
on the instance is not yet installed at that time (the target if the network
boot is exactly to install the OS on the instance!), so it won't be able to
mount it.

Ok, yes, if we're considering the DHCP client inside the iPXE BIOS
blob, then I don't see any currently viable options besides UUID.
There's no mechanism for passing any other data into iPXE that I
am aware of, though if there is a desire todo that it could be
raised on the QEMU mailing list for discussion.


Regards,
Daniel


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ceph] Why performance of benchmarks with small blocks is extremely small?

2014-09-29 Thread Pasquale Porreca

Hello

I have no experience with Ceph and this specific benchmark tool, anyway 
I have experience with several other performance benchmark tools and 
file systems and I can say it always happen to have very very low 
performance results when the file size is too small (i.e.  1MB).


My suspect is that benchmark tools are not reliable for file size so 
small, since the time to write is so small that the overhead introduced 
by the test itself is not at all negligible.


I saw that the default object size for rados is 4 MB, did you try your 
test without the option -b 512? I think the results should be 
different for several order of magnitude.


BR

On 09/27/14 17:14, Timur Nurlygayanov wrote:

Hello all,

I installed OpenStack with Glance + Ceph OSD with replication factor 2 
and now I can see the write operations are extremly slow.
For example, I can see only 0.04 MB/s write speed when I run rados 
bench with 512b blocks:


rados bench -p test 60 write --no-cleanup -t 1 -b 512

 Maintaining 1 concurrent writes of 512 bytes for up to 60 seconds or 
0 objects

 Object prefix: benchmark_data_node-17.domain.tld_15862
   sec Cur ops   started  finishedavg MB/s cur MB/s   last 
lat  avg lat
 0   0 0 0 0
0   -   0
 1   183820.0400341 0.0400391  
0.008465   0.0120985
 2   1   169   168  0.0410111 0.0419922  
0.080433   0.0118995
 3   1   240   239  0.0388959 0.034668   
0.008052   0.0125385
 4   1   356   355  0.0433309 0.0566406  
0.00837 0.0112662
 5   1   472   471  0.0459919 0.0566406  
0.008343   0.0106034
 6   1   550   549  0.0446735 0.0380859  
0.036639   0.0108791
 7   1   581   580  0.0404538 0.0151367  
0.008614   0.0120654



My test environment configuration:
Hardware servers with 1Gb network interfaces, 64Gb RAM and 16 CPU 
cores per node, HDDs WDC WD5003ABYX-01WERA0.
OpenStack with 1 controller, 1 compute and 2 ceph nodes (ceph on 
separate nodes).

CentOS 6.5, kernel 2.6.32-431.el6.x86_64.

I tested several config options for optimizations, like in 
/etc/ceph/ceph.conf:


[default]
...
osd_pool_default_pg_num = 1024
osd_pool_default_pgp_num = 1024
osd_pool_default_flag_hashpspool = true
...
[osd]
osd recovery max active = 1
osd max backfills = 1
filestore max sync interval = 30
filestore min sync interval = 29
filestore flusher = false
filestore queue max ops = 1
filestore op threads = 16
osd op threads = 16
...
[client]
rbd_cache = true
rbd_cache_writethrough_until_flush = true

and in /etc/cinder/cinder.conf:

[DEFAULT]
volume_tmp_dir=/tmp

but in the result performance was increased only on ~30 % and it not 
looks like huge success.


Non-default mount options and TCP optimization increase the speed in 
about 1%:


[root@node-17 ~]# mount | grep ceph
/dev/sda4 on /var/lib/ceph/osd/ceph-0 type xfs 
(rw,noexec,nodev,noatime,nodiratime,user_xattr,data=writeback,barrier=0)


[root@node-17 ~]# cat /etc/sysctl.conf
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1


Do we have other ways to significantly improve CEPH storage performance?
Any feedback and comments are welcome!

Thank you!


--

Timur,
QA Engineer
OpenStack Projects
Mirantis Inc


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Create an instance with a custom uuid

2014-09-25 Thread Pasquale Porreca
I will briefly explain our use case. This idea is related to another 
project to enable the network boot in OpenStack 
https://blueprints.launchpad.net/nova/+spec/pxe-boot-instance


We want to make use of the extra-dhcp-opt to indicate as tftp server a 
specific instance inside our deployed system, so it will provide the 
right operating system to the other instances booting from network (once 
the feature from the linked blueprint will be implemented).


On the tftp server we want to be able to filter what boot file to 
provide to different class of instances and our idea was to identify 
each class with 2 hexadecimal of the UUID (while the rest would be 
random generated, still granting its uniqueness).


Anyway this is a customization for our specific environment and for a 
feature that is still in early proposal stage, so we wanted to propose 
as a separate feature to allow user custom UUID and manage the 
generation out of OpenStack.



On 09/24/14 23:15, Matt Riedemann wrote:



On 9/24/2014 3:17 PM, Dean Troyer wrote:

On Wed, Sep 24, 2014 at 2:58 PM, Roman Podoliaka
rpodoly...@mirantis.com mailto:rpodoly...@mirantis.com wrote:

Are there any known gotchas with support of this feature in REST 
APIs

(in general)?


I'd be worried about relying on a user-defined attribute in that use
case, that's ripe for a DOS.  Since these are cloud-unique I wouldn't
even need to be in your project to block you from creating that clone
instance if I knew your UUID.

dt

--

Dean Troyer
dtro...@gmail.com mailto:dtro...@gmail.com


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



We talked about this a bit before approving the 
'enforce-unique-instance-uuid-in-db' blueprint [1].  As far as we knew 
there was no one using null instance UUIDs or duplicates for that matter.


The instance object already enforces that the UUID field is unique but 
the database schema doesn't.  I'll be re-proposing that for Kilo when 
it opens up.


If it's a matter of tagging an instance, there is also the tags 
blueprint [2] which will probably be proposed again for Kilo.


[1] 
https://blueprints.launchpad.net/nova/+spec/enforce-unique-instance-uuid-in-db

[2] https://blueprints.launchpad.net/nova/+spec/tag-instances



--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Create an instance with a custom uuid

2014-09-25 Thread Pasquale Porreca
The problem to use a different tag than UUID is that it won't be 
possible (for what I know) to include this tag in the Bootstrap Protocol 
messages exchanged during the pre-boot phase.


Our original idea was to use the Client-identifier (option 61) or Vendor 
class identifier (option 60) of the dhcp request to achieve our target, 
but these fields cannot be controlled in libvirt template and so they 
cannot be set in OpenStack either. Instead the UUID is set it the 
libvirt template by OpenStack and it is included in the messages 
exchanged in the pre-boot phase (option 97) by the instance trying to 
boot from network.


Reference: 
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml



On 09/25/14 14:43, Andrew Laski wrote:


On 09/25/2014 04:18 AM, Pasquale Porreca wrote:
I will briefly explain our use case. This idea is related to another 
project to enable the network boot in OpenStack 
https://blueprints.launchpad.net/nova/+spec/pxe-boot-instance


We want to make use of the extra-dhcp-opt to indicate as tftp server 
a specific instance inside our deployed system, so it will provide 
the right operating system to the other instances booting from 
network (once the feature from the linked blueprint will be 
implemented).


On the tftp server we want to be able to filter what boot file to 
provide to different class of instances and our idea was to identify 
each class with 2 hexadecimal of the UUID (while the rest would be 
random generated, still granting its uniqueness).


It seems like this would still be achievable using the instance tags 
feature that Matt mentioned.  And it would be more clear since you 
could use human readable class names rather than relying on knowing 
that part of the UUID had special meaning.


If you have a need to add specific information to an instance like 
'boot class' or want to indicate that an instance in two different 
clouds is actually the same one, the Pumphouse use case, that 
information should be something we layer on top of an instance and not 
something we encode in the UUID.



Anyway this is a customization for our specific environment and for a 
feature that is still in early proposal stage, so we wanted to 
propose as a separate feature to allow user custom UUID and manage 
the generation out of OpenStack.

On 09/24/14 23:15, Matt Riedemann wrote:



On 9/24/2014 3:17 PM, Dean Troyer wrote:

On Wed, Sep 24, 2014 at 2:58 PM, Roman Podoliaka
rpodoly...@mirantis.com mailto:rpodoly...@mirantis.com wrote:

Are there any known gotchas with support of this feature in 
REST APIs

(in general)?


I'd be worried about relying on a user-defined attribute in that use
case, that's ripe for a DOS.  Since these are cloud-unique I wouldn't
even need to be in your project to block you from creating that clone
instance if I knew your UUID.

dt

--

Dean Troyer
dtro...@gmail.com mailto:dtro...@gmail.com


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



We talked about this a bit before approving the 
'enforce-unique-instance-uuid-in-db' blueprint [1].  As far as we 
knew there was no one using null instance UUIDs or duplicates for 
that matter.


The instance object already enforces that the UUID field is unique 
but the database schema doesn't.  I'll be re-proposing that for Kilo 
when it opens up.


If it's a matter of tagging an instance, there is also the tags 
blueprint [2] which will probably be proposed again for Kilo.


[1] 
https://blueprints.launchpad.net/nova/+spec/enforce-unique-instance-uuid-in-db

[2] https://blueprints.launchpad.net/nova/+spec/tag-instances






___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Create an instance with a custom uuid

2014-09-25 Thread Pasquale Porreca
This is correct Daniel, except that that it is done by the virtual 
firmware/BIOS of the virtual machine and not by the OS (not yet 
installed at that time).


This is the reason we thought about UUID: it is yet used by the iPXE 
client to be included in Bootstrap Protocol messages, it is taken from 
the uuid field in libvirt template and the uuid in libvirt is set by 
OpenStack; the only missing passage is the chance to set the UUID in 
OpenStack instead to have it randomly generated.


Having another user defined tag in libvirt won't help for our issue, 
since it won't be included in Bootstrap Protocol messages, not without 
changes in the virtual BIOS/firmware (as you stated too) and honestly my 
team doesn't have interest in this (neither the competence).


I don't think the configdrive or metadata service would help either: the 
OS on the instance is not yet installed at that time (the target if the 
network boot is exactly to install the OS on the instance!), so it won't 
be able to mount it.


On 09/25/14 16:24, Daniel P. Berrange wrote:

On Thu, Sep 25, 2014 at 09:19:03AM -0500, Matt Riedemann wrote:


On 9/25/2014 8:26 AM, Pasquale Porreca wrote:

The problem to use a different tag than UUID is that it won't be
possible (for what I know) to include this tag in the Bootstrap Protocol
messages exchanged during the pre-boot phase.

Our original idea was to use the Client-identifier (option 61) or Vendor
class identifier (option 60) of the dhcp request to achieve our target,
but these fields cannot be controlled in libvirt template and so they
cannot be set in OpenStack either. Instead the UUID is set it the
libvirt template by OpenStack and it is included in the messages
exchanged in the pre-boot phase (option 97) by the instance trying to
boot from network.

Reference:
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

[snip]


If it's a matter of getting the instance tag information down to the libvirt
driver on boot that shouldn't be a problem, there are others asking for
similar things, i.e. I want to tag my instances at create time and store
that tag metadata in some namespace in the libvirt domain xml so I can have
an application outside of openstack consuming those domain xml's and reading
that custom namespace information.

Perhaps I'm misunderstanding something, but isn't the DHCP client that
needs to send the tag running in the guest OS ? Libvirt is involved wrt
UUID, because UUID is populated in the guest's virtual BIOS and then
extracted by the guest OS and from there used by the DHCP client. If
we're talking about making a different tag/identifier available for
the DHCP client, then this is probably not going to involve libvirt
unless it also gets pushed up via the virtual BIOS. IOW, couldn't you
just pass whatever tag is needed to the guest OS via the configdrive
or metadata service.

Regards,
Daniel


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [nova] Create an instance with a custom uuid

2014-09-24 Thread Pasquale Porreca

Hello

I would like to be able to specify the UUID of an instance when I create 
it. I found this discussion about this matter: 
https://lists.launchpad.net/openstack/msg22387.html
but I could not find any blueprint, anyway I understood this 
modification should not comport any particular issue.


Would it be acceptable to pass the uuid as metadata, or should I instead 
modify the api if I want to set the UUID from the novaclient?


Best regards

--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev