date:20150126

On Tue, Jan 27, 2015 at 10:34:47AM +0800, Jay Lau wrote:
> 2015-01-27 10:28 GMT+08:00 Qiming Teng :
> 
> > On Tue, Jan 27, 2015 at 10:13:59AM +0800, Jay Lau wrote:
> > > Greetings,
> > >
> > > I have a question related to MAC and IP binding, I know that we can
> > create
> > > a port to bind a private IP and MAC together then create VM using this
> > > specified port to make sure the VM can use the the IP and MAC in this
> > port.
> > > This can make sure one VM can have IP and MAC as customer required.
> > >
> > > The problem is how to handle this in HEAT, I can create a pool of neutron
> > > ports which have a list of MAC&IP biniding, then I want to create a stack
> >
> > Who maintains that pool? Is the maintainer providing an API for port
> > allocation? Or ... the pool itself is a new resource type?
> >
> The pool was created by a tenant user as heat do not have such kind of
> resource type for now.  Once the pool was created, I want to use the ports
> in my stack resources.

Are you considering propose a spec to add that kind of a resource type
to Heat? Or you can try generating such a pool using ResourceGroup?
Then the question becomes referencing a member from a ResourceGroup, I
think.

Regards,
  Qiming

> >
> > Regards,
> >   Qiming
> >
> > > with heat to use the ports that I created before to make sure all VMs in
> > > the stack can have the IP&MAC specified in my port pool, I did not find a
> > > solution for this, does anyone can give some suggestions for how to
> > > configure this in heat template to achieve this goal?
> > >
> > > --
> > > Thanks,
> > >
> > > Jay Lau (Guangya Liu)
> >
> > >
> > __
> > > 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
> >
> 
> 
> 
> -- 
> Thanks,
> 
> Jay Lau (Guangya Liu)

> __
> 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

[openstack-dev] [all] need help with my first commit: The branch 'master' does not exist on the given remote 'gerrit'

2015-01-26 Thread Tran, Steven

Hi,
   Can someone point out what I miss that results in the following warning?

$ git review
The branch 'master' does not exist on the given remote 'gerrit'. If
these changes are intended to start a new branch, re-run with the '-R'
option enabled.


I believe I shouldn't do "git review -R" because it prompts me to submit 
multiple commits.
I can do "git review -s" without any errors.
I follow the steps at 
http://docs.openstack.org/infra/manual/developers.html#starting-a-change
I'm using Cygwin.

$ git status
On branch bp/murano-driver
nothing to commit, working directory clean

$ git branch
* bp/murano-driver
  master

$ git config --list
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
remote.origin.url=https://github.com/stackforge/congress.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
remote.gerrit.url=ssh://steven...@review.openstack.org:29418/stackforge/congress.git
user.name=Steven Tran
user.email=steven.tr...@hp.com
gitreview.username=stevenldt

$ git log
commit 5567b6e4622246ad86cdb9d6c0643427573e8d13
Author: Steven Tran 
Date:   Mon Jan 26 17:19:38 2015 -0800

Change-Id: Idc4abf32a7aa25231a7a6df511df998a0a3a50ad
Implements: blueprint murano-driver

Thanks,
-Steven
__
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] [magnum] Schedule for rest of Kilo

2015-01-26 Thread Adrian Otto

Tony,

That would be terrific. Which iCal feed were you thinking of? I was planning on 
making something similar to this:

https://wiki.openstack.org/wiki/Kilo_Release_Schedule

But under Magnum on the wiki. Were you thinking I would proceed with that plan, 
or would it be more appropriate to put a column into the above wiki page? My 
gut is telling me that a separate schedule page is probably better until such 
time as integration with other projects is important. Thoughts?

Thanks,

Adrian

On Jan 26, 2015, at 4:43 PM, Tony Breeds  wrote:

> On Fri, Jan 23, 2015 at 03:14:18PM -0700, Steven Dake wrote:
>> On 01/23/2015 02:46 PM, Adrian Otto wrote:
>>> Steven,
>>> 
>>> Thanks for this email to capture and relay this decision from our IRC team
>>> meeting this week! I thought it might be helpful if I made a team calendar
>>> with an iCal feed that our team can subscribe to that would include our team
>>> meeting schedule, and our milestones to help make our plans more visible to
>>> the team. I can set this up if there is interest. Thoughts on this?
>> 
>> I probably wouldn't use an iCal feed, but publishing the schedule on the
>> wiki might be helpful.  Others may want an ical feed though.
> 
> Put it on the wiki (and keep it updated) and I'll keep the iCal in sync.
> 
> Yours Tony.
> __
> 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

[openstack-dev] [nova] Do we need new nova configuration option to show compute nodes with shared_storage or not ?

2015-01-26 Thread ChangBo Guo

Hi ALL,

I have been working on bug 1414432 [1] recently,  I would like do more
discussion before further work.

I'm talking about libvirt driver( maybe fit for other hypervisor),  there
are two kinds of  storages  which are used for  instance's  root_disk.
1) non-shared storage  on each compute nodes
2) shared storage  between compute nodes
2.1 shared  instance_path and  root_disk  (shared everything ike NFS)
2.2 shared  root_disk  without shared instance_path  (shared volume
backend like ceph)

Current we  check if shared storage or not  in  concrete actions like
live-migration,  evacuate,  these need pass instance as argument,
I think the value of  hared storage or not should base on compute node,
should not base on instance.
So do we need new nova configuration option to show compute nodes with
shared_storage or not ?

benefits:

   1) Don't need check for each instance while taking action
   2) Can handle similar bug easily like [1] from API level.

If yes,
some thing like, compute-node-storage-type= [ non-shared |  shared-all |
shared-volume ]  or part-shared
 In order to support some compute nodes with shared_storage, and others
doesn't in one OpenStack development,
 another configuration   shared_storage_compute_nodes =[node3, node5]

Any thoughts ?


[1]https://bugs.launchpad.net/nova/+bug/1414432

-- 
ChangBo Guo(gcb)
__
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] [gantt] Scheduler sub-group meeting agenda 1/27 - cancelled

2015-01-26 Thread Dugger, Donald D

Meeting canceled this week due to the Nova mid-cycle meetup.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

__
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] [Neutron][Heat] How to bind IP&MAC for a stack VM resources

2015-01-26 Thread Jay Lau

2015-01-27 10:28 GMT+08:00 Qiming Teng :

> On Tue, Jan 27, 2015 at 10:13:59AM +0800, Jay Lau wrote:
> > Greetings,
> >
> > I have a question related to MAC and IP binding, I know that we can
> create
> > a port to bind a private IP and MAC together then create VM using this
> > specified port to make sure the VM can use the the IP and MAC in this
> port.
> > This can make sure one VM can have IP and MAC as customer required.
> >
> > The problem is how to handle this in HEAT, I can create a pool of neutron
> > ports which have a list of MAC&IP biniding, then I want to create a stack
>
> Who maintains that pool? Is the maintainer providing an API for port
> allocation? Or ... the pool itself is a new resource type?
>
The pool was created by a tenant user as heat do not have such kind of
resource type for now.  Once the pool was created, I want to use the ports
in my stack resources.

>
> Regards,
>   Qiming
>
> > with heat to use the ports that I created before to make sure all VMs in
> > the stack can have the IP&MAC specified in my port pool, I did not find a
> > solution for this, does anyone can give some suggestions for how to
> > configure this in heat template to achieve this goal?
> >
> > --
> > Thanks,
> >
> > Jay Lau (Guangya Liu)
>
> >
> __
> > 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
>



-- 
Thanks,

Jay Lau (Guangya Liu)
__
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] [Neutron][Heat] How to bind IP&MAC for a stack VM resources

On Tue, Jan 27, 2015 at 10:13:59AM +0800, Jay Lau wrote:
> Greetings,
> 
> I have a question related to MAC and IP binding, I know that we can create
> a port to bind a private IP and MAC together then create VM using this
> specified port to make sure the VM can use the the IP and MAC in this port.
> This can make sure one VM can have IP and MAC as customer required.
> 
> The problem is how to handle this in HEAT, I can create a pool of neutron
> ports which have a list of MAC&IP biniding, then I want to create a stack

Who maintains that pool? Is the maintainer providing an API for port
allocation? Or ... the pool itself is a new resource type?

Regards,
  Qiming

> with heat to use the ports that I created before to make sure all VMs in
> the stack can have the IP&MAC specified in my port pool, I did not find a
> solution for this, does anyone can give some suggestions for how to
> configure this in heat template to achieve this goal?
> 
> -- 
> Thanks,
> 
> Jay Lau (Guangya Liu)

> __
> 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

[openstack-dev] [Neutron][Heat] How to bind IP&MAC for a stack VM resources

2015-01-26 Thread Jay Lau

Greetings,

I have a question related to MAC and IP binding, I know that we can create
a port to bind a private IP and MAC together then create VM using this
specified port to make sure the VM can use the the IP and MAC in this port.
This can make sure one VM can have IP and MAC as customer required.

The problem is how to handle this in HEAT, I can create a pool of neutron
ports which have a list of MAC&IP biniding, then I want to create a stack
with heat to use the ports that I created before to make sure all VMs in
the stack can have the IP&MAC specified in my port pool, I did not find a
solution for this, does anyone can give some suggestions for how to
configure this in heat template to achieve this goal?

-- 
Thanks,

Jay Lau (Guangya Liu)
__
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] [heat][hot]

On Mon, Jan 26, 2015 at 07:44:25PM +0200, Dmitry wrote:
> thanks, exactly what I was looking for:
> curl http://169.254.169.254/1.0/meta-data/instance-id

or, /var/lib/cloud/data/instance-id, if cloud-init is there.

Regards,
  Qiming

> On Mon, Jan 26, 2015 at 7:31 PM, Zane Bitter  wrote:
> 
> > On 25/01/15 10:41, Dmitry wrote:
> >
> >> Hello,
> >> I need to receive instance id as part of the instance installation script.
> >> Something like:
> >> params:
> >>$current_id: {get_param: $this.id }
> >>
> >
> > I have no idea what this is supposed to mean, sorry.
> >
> >  Is it possible?
> >>
> >
> > The get_resource function will return the server UUID for a server
> > resource, but you can't use it from within that resource itself (it would
> > be a circular reference).
> >
> > The UUID of a server is provided to the server through the Nova metadata;
> > you should retrieve it from there in your user_data script.
> >
> > cheers,
> > Zane.
> >
> >
> > __
> > 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


__
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] [Openstack-operators] [openstack-operators]flush expired tokens and moves deleted instance

2015-01-26 Thread Daniel Comnea

+100

Dani

On Mon, Jan 26, 2015 at 1:10 AM, Tim Bell  wrote:

>  This is often mentioned as one of those items which catches every
> OpenStack cloud operator at some time. It’s not clear to me that there
> could not be a scheduled job built into the system with a default frequency
> (configurable, ideally).
>
>
>
> If we are all configuring this as a cron job, is there a reason that it
> could not be built into the code ?
>
>
>
> Tim
>
>
>
> *From:* Mike Smith [mailto:mism...@overstock.com]
> *Sent:* 24 January 2015 18:08
> *To:* Daniel Comnea
> *Cc:* OpenStack Development Mailing List (not for usage questions);
> openstack-operat...@lists.openstack.org
> *Subject:* Re: [Openstack-operators]
> [openstack-dev][openstack-operators]flush expired tokens and moves deleted
> instance
>
>
>
> It is still mentioned in the Juno installation docs:
>
>
>
> By default, the Identity service stores expired tokens in the database
> indefinitely. The
>
> accumulation of expired tokens considerably increases the database size
> and might degrade
>
> service performance, particularly in environments with limited resources.
>
> We recommend that you use cron to configure a periodic task that purges
> expired tokens
>
> hourly:
>
> # (crontab -l -u keystone 2>&1 | grep -q token_flush) || \
>
> echo '@hourly /usr/bin/keystone-manage token_flush >/var/log/keystone/
>
> keystone-tokenflush.log 2>&1' \
>
> >> /var/spool/cron/keystone
>
>
>
>
>
>
> Mike Smith
> Principal Engineer, Website Systems
> Overstock.com
>
>
>
>  On Jan 24, 2015, at 10:03 AM, Daniel Comnea 
> wrote:
>
>
>
> Hi all,
>
>   I just bumped into Sebastien's blog where he suggested a cron job
> should run in production to tidy up expired tokens - see blog[1]
>
> Could you please remind me if this is still required in IceHouse/ Juno? (i
> kind of remember i've seen some work being done in this direction but i
> can't find the emails)
>
>   Thanks,
> Dani
>
> [1]
> http://www.sebastien-han.fr/blog/2014/08/18/a-must-have-cron-job-on-your-openstack-cloud/
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
>  --
>
>
> CONFIDENTIALITY NOTICE: This message is intended only for the use and
> review of the individual or entity to which it is addressed and may contain
> information that is privileged and confidential. If the reader of this
> message is not the intended recipient, or the employee or agent responsible
> for delivering the message solely to the intended recipient, you are hereby
> notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify sender immediately by telephone or
> return email. 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

[openstack-dev] [nova] Requesting FFE for opencontrail-nova-vif-driver-plugin

2015-01-26 Thread Nati Ueno

Hi nova folks

May I request FFE for vif driver for contrail?
Spec was already approved, and 1st code review pushed Jan21, and it's
just 95 lines code.

BP
https://blueprints.launchpad.net/nova/+spec/opencontrail-nova-vif-driver-plugin

Code
https://review.openstack.org/#/c/148805/1

Best
Nachi

-- 
Nachi Ueno
email:nati.u...@gmail.com
twitter:http://twitter.com/nati

__
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] [Neutron] Bulk network operations

2015-01-26 Thread Saksham Varma (sakvarma)

Modifying the subject line.

From: Saksham Varma mailto:sakva...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, January 27, 2015 at 5:21 AM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] Bulk network operations

Hi,

I was working on bulk network operations for one of Cisco’s plugins. I was 
wondering how do other plugins handle failures in bulk requests. Are all the 
requests in the bulk payload rolled back, if any fails (like an atomic 
strategy)? Or is it like a best effort, which is not necassarily atomic?

Thanks,
Saksham
__
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] [magnum] Schedule for rest of Kilo

2015-01-26 Thread Tony Breeds

On Fri, Jan 23, 2015 at 03:14:18PM -0700, Steven Dake wrote:
> On 01/23/2015 02:46 PM, Adrian Otto wrote:
> >Steven,
> >
> >Thanks for this email to capture and relay this decision from our IRC team
> >meeting this week! I thought it might be helpful if I made a team calendar
> >with an iCal feed that our team can subscribe to that would include our team
> >meeting schedule, and our milestones to help make our plans more visible to
> >the team. I can set this up if there is interest. Thoughts on this?
> 
> I probably wouldn't use an iCal feed, but publishing the schedule on the
> wiki might be helpful.  Others may want an ical feed though.

Put it on the wiki (and keep it updated) and I'll keep the iCal in sync.
 
Yours Tony.


pgpHb6jc1YPLb.pgp
Description: PGP signature
__
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] [Fuel] Getting rid of kickstart/preseed for all NEW releases

2015-01-26 Thread Andrew Woodward

On Mon, Jan 26, 2015 at 10:47 AM, Sergii Golovatiuk
 wrote:
> Until we are sure IBP solves operation phase where we need to deliver
> updated packages so client will be able to provision new machines with these
> fixed packages, I would leave backward compatibility with normal provision.
> ... Just in case.

doesn't running 'apt-get upgrade' or 'yum update' after laying out the
FS image resolve the gap until we can rebuild the images on the fly?
>
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Jan 26, 2015 at 4:56 PM, Vladimir Kozhukalov
>  wrote:
>>
>> My suggestion is to make IBP the only option available for all upcoming
>> OpenStack releases which are defined in openstack.yaml. It is to be possible
>> to install OS using kickstart for all currently available OpenStack
>> releases.
>>
>> Vladimir Kozhukalov
>>
>> On Mon, Jan 26, 2015 at 6:22 PM, Igor Kalnitsky 
>> wrote:
>>>
>>> Just want to be sure I understand you correctly: do you propose to
>>> FORBID kickstart/preseed installation way in upcoming release at all?
>>>
>>> On Mon, Jan 26, 2015 at 3:59 PM, Vladimir Kozhukalov
>>>  wrote:
>>> > Subject is changed.
>>> >
>>> > Vladimir Kozhukalov
>>> >
>>> > On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukalov
>>> >  wrote:
>>> >>
>>> >> Dear Fuelers,
>>> >>
>>> >> As you might know we need it to be possible to install several
>>> >> versions of
>>> >> a particular OS (Ubuntu and Centos) by 6.1  As far as having different
>>> >> OS
>>> >> versions also means having different sets of packages and some of  the
>>> >> packages are installed and configured during provisioning stage, we
>>> >> need to
>>> >> have a kind of kickstart/preseed version mechanism.
>>> >>
>>> >> Cobbler is exactly such a mechanism. It allows us to have several
>>> >> Distros
>>> >> (installer images) and profiles (kickstart/preseed files). But
>>> >> unfortunately, for some reasons we have not been using those Cobbler's
>>> >> capabilities since the beginning of Fuel and it doesn't seem to be
>>> >> easily
>>> >> introduced into Nailgun to deal with the whole Cobbler life cycle.
>>> >>
>>> >> Anyway, we are moving towards IBP (image based provisioning) and we
>>> >> already have different images connected to different OpenStack
>>> >> releases
>>> >> (openstack.yaml) and everything else which is necessary for initial
>>> >> node
>>> >> configuration is serialized inside provision data (including profile
>>> >> name
>>> >> like 'ubuntu_1204' or 'ubuntu_1404') and we are able to choose
>>> >> cloud-init
>>> >> template by this profile name.
>>> >>
>>> >> And taking into account what it is written above, the suggestion is to
>>> >> completely avoid using kickstart/preseed based way of OS provisioning
>>> >> by 6.1
>>> >> for all new releases allowing ONLY old ones to use this way.
>>> >>
>>> >> Any opinions about that stuff are welcome.
>>> >>
>>> >> Vladimir Kozhukalov
>>> >
>>> >
>>> >
>>> >
>>> > __
>>> > 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
>>
>>
>>
>> __
>> 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
>



-- 
Andrew
Mirantis
Ceph community

__
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] [Heat] Convergence Phase 1 implementation plan

2015-01-26 Thread Angus Salkeld

On Sat, Jan 24, 2015 at 7:00 AM, Zane Bitter  wrote:

> I've mentioned this in passing a few times, but I want to lay it out here
> in a bit more detail for comment. Basically we're implementing convergence
> at a time when we still have a lot of 'unit' tests that are really
> integration tests, and we don't want to have to rewrite them to anticipate
> this new architecture, nor wait until they have all been converted into
> functional tests. And of course it goes without saying that we have to land
> all of these changes without breaking anything for users.
>
> To those ends, my proposal is that we (temporarily) support two code
> paths: the existing, legacy in-memory path and the new, distributed
> convergence path. Stacks will contain a field indicating which code path
> they were created with, and each stack will be operated on only by that
> same code path throughout its lifecycle (i.e. a stack created in legacy
> mode will always use the legacy code). We'll add a config option, off by
> default, to enable the new code path. That way users can switch over at a
> time of their choosing. When we're satisfied that it's stable enough we can
> flip the default (note: IMHO this would have to happen before kilo-3 in
> order to make it for the Kilo release).
>

+1


>
> Based on this plan, I had a go at breaking the work down into discrete
> tasks, and because it turned out to be really long I put it in an etherpad
> rather than include it here:
>
> https://etherpad.openstack.org/p/heat-convergence-tasks
>
>
Thanks Zane, this looks great.


> If anyone has additions/changes then I suggest adding them to that
> etherpad and replying to this message to flag your changes.
>
> To be clear, it's unlikely I will have time to do the implementation work
> on any of these tasks myself (although I will be trying to review as many
> of them as possible). So the goal here is to get as many contributors
> involved in doing stuff in parallel as we can.
>
> There are obviously dependencies between many of these tasks, so my plan
> is to raise each one as a blueprint so we can see the magic picture that
> Launchpad shows. I want to get feedback first though, because there are 18
> of them so far, and rejigging everything in response to feedback would be a
> bit of a pain.
>
> I'm also prepared to propose specs for all of these _if_ people think that
> would be helpful. I see three options here:
>  - Propose 18 fairly minimal specs (maybe in a single review?)
>

This sounds fine, but if possible group them a bit 18 sounds like a lot and
many of these look like small jobs.
I am also open to using bugs for smaller items. Basically this is just the
red tape, so what ever is the least effort
and makes things easier to divide the work up.

-Angus


>  - Propose 1 large spec (essentially the contents of that etherpad)
>  - Just discuss in the etherpad rather than Gerrit
>

> Obviously that's in decreasing order of the amount of work required, but
> I'll do whatever folks think best for discussion.
>
> cheers,
> Zane.
>
> __
> 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

Re: [openstack-dev] [oslo][heat] potentially breaking release of oslo.messaging Tuesday 27th

2015-01-26 Thread Angus Salkeld

On Tue, Jan 27, 2015 at 8:05 AM, Doug Hellmann 
wrote:

> We’ve held up the oslo.messaging release with the namespace package work
> for a while now while we work with the nova, designate, and heat teams to
> fix things up so their tests won’t break. We think the one remaining issue
> is in heat, where some tests are mocking private parts of oslo.messaging.
>
> There’s a bug filed at https://bugs.launchpad.net/heat/+bug/1412836
>
> I think asalkeld fixed similar tests in
> https://review.openstack.org/#/c/145094/1/heat/tests/test_stack_lock.py
> but missed these at the time.
>
> I would propose a fix, but I really don’t understand the test suite or
> what’s going on there. If someone else does propose a fix, please ping me
> in #openstack-oslo on IRC and I’ll test the pre-release against it to see
> if the issue is resolved.
>
>
This should sort it out: https://review.openstack.org/150185

-Angus


> I plan to release the new version of oslo.messaging around 15:00 UTC on 27
> Jan, but I will wait if there’s a fix in heat’s merge queue.
>
> Doug
>
>
> __
> 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

[openstack-dev] Bulk network operations

2015-01-26 Thread Saksham Varma (sakvarma)

Hi,

I was working on bulk network operations for one of Cisco’s plugins. I was 
wondering how do other plugins handle failures in bulk requests. Are all the 
requests in the bulk payload rolled back, if any fails (like an atomic 
strategy)? Or is it like a best effort, which is not necassarily atomic?

Thanks,
Saksham
__
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] [Magnum] Mid-Cycle Meetup Planning

2015-01-26 Thread Adrian Otto

Team,

Thanks for participating in the poll. Due to considerable scheduling conflicts, 
I am expanding the poll to include the following Monday 2015-03-02+Tuesday 
2015-03-03. Hopefully these alternate dates can get more of us together on the 
same days.

Please take a moment to respond to the poll a second time to indicate your 
availability on the newly proposed dates:

http://doodle.com/ddgsptuex5u3394m

Thanks,

Adrian

On Jan 8, 2015, at 2:24 PM, Adrian Otto  wrote:

> Team,
> 
> If you have been watching the Magnum project you know that things have really 
> taken off recently. At Paris we did not contemplate a Mid-Cycle meet-up but 
> now that we have come this far so quickly, and have such a broad base of 
> participation now, it makes sense to ask if you would like to attend a 
> face-to-face mid-cycle meetup. I propose the following for your consideration:
> 
> - Two full days to allow for discussion of Magnum architecture, and 
> implementation of our use cases.
> - Located in San Francisco.
> - Open to using Los Angeles or another west coast city to drive down travel 
> expenses, if that is a concern that may materially impact participation.
> - Dates: February 23+24 or 25+26
> 
> If you think you can attend (with 80+% certainty) please indicate your 
> availability on the proposed dates using this poll:
> 
> http://doodle.com/ddgsptuex5u3394m
> 
> Please also add a comment on the Doodle Poll indicating what Country/US City 
> you will be traveling FROM in order to attend.
> 
> I will tabulate the responses, and follow up to this thread. Feel free to 
> respond to this thread to discuss your thoughts about if we should meet, or 
> if there are other locations or times that we should consider.
> 
> Thanks,
> 
> Adrian
> 
> PS: I do recognize that some of our contributors reside in countries that 
> require Visas to travel to the US, and those take a long time to acquire. The 
> reverse is also true. For those of you who can not attend in person, we will 
> explore options for remote participation using teleconferencing technology, 
> IRC, Etherpad, etc for limited portions of the agenda.
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> 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

Re: [openstack-dev] required libvirtd/qemu versions for numa support?

2015-01-26 Thread Jay Pipes


On 01/26/2015 07:33 AM, Chris Friesen wrote:

Hi,

I'm interested in the recent work around NUMA support for guest
instances
(https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement), but
I'm having some difficulty figuring out what versions of libvirt and
qemu are required.

 From the research that I've done it seems like qemu 2.1 might be
required, but I've been unable to find a specific version listed in the
nova requirements or in the openstack global requirements.  Is it there
and I just can't find it?

If it's not specified, and yet openstack relies on it, perhaps it should
be added.  (Or at least documented somewhere.)


Hi Chris,

The constants starting here:

http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py#n340

should answer your questions.

All the best,
-jay

__
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] [tc][python-clients] More freedom for all python clients

2015-01-26 Thread Chris Dent


On Tue, 27 Jan 2015, Robert Collins wrote:


Yes, but the experience we have about the limitations of per-service
venvs is still relevant, no? Are you really saying 'do per-service
venvs because they work well', or are you agreeing with me that they
don't solve the problems plaguing the gate?


To take this topic even further from its original subject I'd just
like to remind at least myself that the reason we have problems in the
gate is because there are real problems that actually exist or will
exist soon and that catching them before they leak out is is presumably
exactly why we have a gate.

Given a lot more resources we should always pip -U and never put upper
version caps in requirements.txt. Then when stuff breaks do the good
work to untangle the mess and fix the problem. Not just for us but for
the commonweal.

Breaking stuff tends to be how stuff gets fixed.

Yes, I'm talking idealistic impractical hooey here, but I think it is
important to remember these things. So whereas earlier I said I was
keen on virtualenvs, now that I actually think about it some I think
we're better off creating a chaotic crucible of everything in one fiery
cauldron of truth and using breakage in the gate as a way of marshalling
resources.

Do I expect to see that happen? Sadly, not really.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
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] [Fuel][Agent] Moving Fuel Agent to a separate repo

2015-01-26 Thread Roman Prykhodchenko

I think the idea is not to work on it right at this moment but to accept the 
general idea of fuel-agent being moved somewhere it can be alone. I’m not sure 
there is one single approach for separating a component from the common 
repository because each of them has their own use-cases and requirements so for 
every single one of them there is a need to do the same job as we’ve done for 
Fuel Client.

Thar said I’d like to note that only by having a clear specification of how 
work- data- and test-flaws have to be changed after the component is put to its 
own repository it will be possible to judge on the time frame and the number of 
resources required to accomplish this task.


- romcheg

> 26 січ. 2015 о 20:39 Mike Scherbakov  написав(ла):
> 
> -1 to make changes now
> +1 to Alexandra
> 
> Let's finish fuel-client first. Also, it is about prioritization. We have 
> many things to be resolved in 6.1 (e.g. package the rest of the stuff which 
> not yet packaged into RPM/DEB; split repos openstack/fuel/linux, etc.), and 
> fuel agent in particular has pretty low priority to me in 6.1.
> 
> In examples I have provided, which are essential for 6.1, we are experiencing 
> lack of hands. Let's see if we can focus our work on those items and many 
> other essential things, and come to this question later.
> 
> On Mon, Jan 26, 2015 at 10:29 PM, Aleksandra Fedorova 
>  wrote:
> It seems that we have general agreement about the idea, but to make it happen 
> we need much more detailed proposal.
> 
> Even with python-fuelclient it is not quite clear right now, which version of 
> nailgun should be used to test it, and the opposite: which version of 
> fuelclient we have to use in iso builds. We also don't handle it in the build 
> system very well right now, as we use git hashes, and not fixed versions, or 
> packages.
> 
> Maybe we should complete the python-fuelclient transformation first and see 
> how it is going to work for us?
> 
> On Jan 26, 2015 8:59 PM, "Roman Prykhodchenko"  wrote:
> Vladimir,
> 
> As a fuel-separatist I give this initiative a big +1 because of the following 
> advantages I can see:
> 
>  - Git is designed for keeping smaller single-compoent repos, keeping 
> everything to one repo is a discouraged pattern
>  - Having a separate -core group that will only contain active core reviewers 
> for fuel-agent project so getting core-reviews will be easier.
>  - It makes possible to re-use some of the existing jobs in OpenStack CI
>  - Making independent releases becomes possible
> 
> AFAIK fuel-agent is positioned as an independent provisioning tool which will 
> not be exclusively used by Fuel. There is a work in progress to integrate it 
> with Ironic. Integrating it to any other provisioning system should also be 
> possible then. From that perspective putting it into its own repo also brings 
> the following advantages:
> 
>  - Connecting 3rd party CI will be possible
>  - Getting involved for the new folks will be much easier
> 
> 
> - romcheg
> 
> 
> > 26 січ. 2015 о 17:42 Vladimir Kozhukalov  
> > написав(ла):
> >
> > Fuelers,
> >
> > As most of you might know we have a bunch of projects inside fuel-web repo 
> > which are not directly related to Fuel Web application. Some of them are 
> > tested together and it seemed we could end up with a set of  
> > incompatibility issues if we separated them and stopped tracking their 
> > versions on the git level (instead of release level).
> >
> > Recent activities about separating Fuel Client from Nailgun (api) make me 
> > think we are mature enough to move all other not related project out of 
> > fuel-web repo and bring them together not earlier than on the stage of 
> > system/functional testing.
> >
> > Next step would be moving out Fuel Agent project. The reason is that it is 
> > independent and potentially could be used even out of Fuel because its data 
> > parsing mechanism is implemented so as to be agnostic to the data format. 
> > Some people could be potentially interested in using it independently with 
> > their own data format. It is tested together with other Fuel components 
> > during system testing only.
> >
> >
> >
> > Vladimir Kozhukalov
> > __
> > 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
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu

Re: [openstack-dev] [nova] Mumble server for the mid-cycle meetup

2015-01-26 Thread Michael Still

For reference, that's because we were having lunch. It seems to be
working well again.

Michael

On Tue, Jan 27, 2015 at 7:24 AM, Robert Collins
 wrote:
> every participant is muted... so there's no sound :(
>
> On 27 January 2015 at 07:42, Michael Still  wrote:
>> Sigh, we had troubles with mumble being unreliable, so now we're
>> playing with google hangouts:
>>
>> https://plus.google.com/hangouts/_/gvieuyvxsvpvvsgs2vdmtqtbbea
>>
>> Michael
>>
>> On Tue, Jan 27, 2015 at 4:18 AM, Michael Still  wrote:
>>> As an experiment, I've put the meetup onto a mumble server at
>>> nova.rcbops.com. The server password is "midcycle".
>>>
>>> At the least this should let people listen in and hopefully comment if
>>> they need to.
>>>
>>> Michael
>>>
>>> --
>>> Rackspace Australia
>>
>>
>>
>> --
>> Rackspace Australia
>>
>> __
>> 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
>
>
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> __
> 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



-- 
Rackspace Australia

__
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] [oslo][heat] potentially breaking release of oslo.messaging Tuesday 27th

We’ve held up the oslo.messaging release with the namespace package work for a 
while now while we work with the nova, designate, and heat teams to fix things 
up so their tests won’t break. We think the one remaining issue is in heat, 
where some tests are mocking private parts of oslo.messaging.

There’s a bug filed at https://bugs.launchpad.net/heat/+bug/1412836

I think asalkeld fixed similar tests in 
https://review.openstack.org/#/c/145094/1/heat/tests/test_stack_lock.py but 
missed these at the time.

I would propose a fix, but I really don’t understand the test suite or what’s 
going on there. If someone else does propose a fix, please ping me in 
#openstack-oslo on IRC and I’ll test the pre-release against it to see if the 
issue is resolved.

I plan to release the new version of oslo.messaging around 15:00 UTC on 27 Jan, 
but I will wait if there’s a fix in heat’s merge queue.

Doug


__
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][cinder][infra] Ceph CI status update

2015-01-26 Thread Matt Riedemann

On 1/15/2015 9:29 AM, Matt Riedemann wrote:

On 12/16/2014 2:48 PM, Matt Riedemann wrote:

On 12/11/2014 10:36 AM, Jon Bernard wrote:

Heya, quick Ceph CI status update. Once the test_volume_boot_pattern
was marked as skipped, only the revert_resize test was failing. I have
submitted a patch to nova for this [1], and that yields an all green
ceph ci run [2]. So at the moment, and with my revert patch, we're in
good shape.

I will fix up that patch today so that it can be properly reviewed and
hopefully merged. From there I'll submit a patch to infra to move the
job to the check queue as non-voting, and we can go from there.

[1] https://review.openstack.org/#/c/139693/
[2]
http://logs.openstack.org/93/139693/1/experimental/check-tempest-dsvm-full-ceph/12397fd/console.html

Cheers,

Jon,

Thanks, this is something I'm supposed to be tracking actually given the
Kilo priorities for the project, it's nice to know that someone is
already fixing this stuff. :)

I've reviewed https://review.openstack.org/#/c/139693/ so it's close,
just needs a small fix.

With Jon's fix [1] the ceph job on the experimental queue is passing now
[2].

This is great to see.

I think there are still some skipped tests due to known bugs but those
can be worked out now that we have a baseline.

I'd also like to move forward on getting this into the check queue, but
remain non-voting for the time being until it's burned in a bit (to make
sure there aren't any bad intermittent failures lurking in there).

[1] https://review.openstack.org/#/c/139693/
[2]
http://logs.openstack.org/93/139693/9/experimental/check-tempest-dsvm-full-ceph/e97ba57/console.html

FYI to anyone paying attention, the ceph job is now running as
non-voting on the check queue for nova and cinder.

https://review.openstack.org/#/c/147559/

Thanks,

Matt Riedemann

__
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] proposal for unwinding database usage from tests

2015-01-26 Thread Matt Riedemann




On 1/24/2015 12:13 PM, Sean Dague wrote:

I've been looking at the following patch series -
https://review.openstack.org/#/c/131691/13 for removing database
requirements from some tests.

I whole heartedly support getting DB usage out of tests, but I'd like to
make sure that we don't create new challenges in the process. The
conditional create_db parameter in test functions adds a bit more
internal test complexity than I think we should have.

I'd like to propose instead DB usage should be removed per test Class as
an atomic unit. If that turns into too large a patch that probably means
breaking apart the test class into smaller test classes first.

The other thing to be careful in understanding the results of timing
tests. The way the database fixture works it caches the migration
process -
https://github.com/openstack/nova/blob/master/nova/tests/fixtures.py#L206

That actually means that the overhead of the db-migration sync is paid
only once per testr worker (it's 1s on my fast workstation, might be 2s
on gate nodes). The subsequence db setups for tests 2 -> N in the worker
only take about 0.020s on my workstation (scale appropriately). So
removing all the unneeded db setup code is probably only going to save
~30s over an entire test run.

Which doesn't mean it shouldn't be done, there are other safety reasons
we shouldn't let every test randomly punch data into the db and still
pass. But time savings should not be the primary motivator here, because
it's actually not nearly as much gain as it looks like from running only
a small number of tests.

-Sean



__
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



Big +1 to doing this on a class by class basis, however, that can get 
ugly fast [1].


I commented on the change for test_compute to just move those to 
test_compute_api/mgr as appropriate, we should be freezing test_compute 
for the most part unless you're just modifying an existing test for some 
small wrinkle in the code.


I don't think we can completely change test_compute over to no-db in one 
change, that would be huge, we should just work on moving pieces over to 
those other modules that use NoDBTestCase (or move the bigger 
functional-type tests into nova.tests.functional).


One candidate is moving the big shelve/unshelve tests into 
test_compute_mgr/api, those have been a latent source of race bugs in 
the gate because of weird DB interactions/expectations/assumptions being 
borked by other tests running at the same time hitting the DB (because 
of so many different test classes that extend test_compute.BaseTestCase).


[1] https://review.openstack.org/#/c/142655/

--

Thanks,

Matt Riedemann


__
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] Adding new features to Kilo and future releases - DB upgrades

2015-01-26 Thread Johannes Erdfelt

On Thu, Jan 22, 2015, Kekane, Abhishek  wrote:
> With online schema changes/No downtime DB upgrades things would be
> much lot easier for OpenStack deployments.
> Big kudos to Johannes who initiated this feature. But as a service
> provider, I'm curious to understand what is the development process
> of adding new features to Kilo and future releases once the online
> schema changes is in.
> 
> 
> 1. Will the committer be responsible of adding new procedures of
> upgrading db with minimal or zero downtime? or the online schema
> changes framework itself will detect whatever db changes are required
> on its own and the decision to apply db changes online or offline
> will be left solely with the service provider?

The online schema change code will compare the running schema and the
model and figure out what changes are needed to make the running schema
match the model (it actually leverages alembic for most of this). (This
automates much of the work currently done in sqlalchemy-migrate
scripts)

The scheduling of changes into the three phases is handled completely
internally to the online schema change patch. It understands which
changes are semantically safe (that can be safely applied when nova is
running) and locking safe (so it doesn't block access to the table for a
long time).

Unless you are working on the code that implements the online schema
changes, then a developer need not know how it operates.

Developers just need to make changes to the model and write
sqlalchemy-migrate scripts as we have always required.

Eventually, developers will no longer need to write sqlalchemy-migrate
scripts. This is likely to be 1 or 2 cycles away (certainly not in
Kilo).

There will be some minor restrictions on what kind of schema changes
will be allowed. As an example column renames won't be allowed because
they appear as a delete/add and we'll potentially lose data. However,
this can be done as an explicit add/delete along with a data migration,
if it's needed. Same thing with some column type changes.

I'll clarify these in the patch when it's put up for review.

> 2. Is it possible to predict how much time it would take to upgrade db
> (expand/migrate/contract phases) for adding a new column, constraint.
> For example, adding a new column with NULL constraint would take less
> time than adding a default value.

This is difficult to estimate. It varies on how fast the database server
is (CPU, disk I/O, etc), the current load of the database, the number of
rows in the table and the size of the data in the columns.

However, I can develop some relative estimates. For instance, adding an
index on MySQL 5.6 only acquires a lock very briefly and does the rest
of the work in the background. It still produces load, but it doesn't
block access to the table. This would be considered online safe and
scheduled to the expand phase. The CREATE INDEX would appear to finish
very quickly.

However, other changes could potentially require a table rewrite which
could be long if it's a large table (eg instance_system_metadata table),
but very short if the table only has a handful of rows (eg
instance_types table).

I've written a test suite which takes a variety of database software
(MySQL, PostgreSQL, etc), versions and storage engines (InnoDB, TokuDB,
etc) and does tests to figure out which changes are online safe (as far
as locking goes).

I will be using this data to make better decisions on scheduling of
operations to ensure the expand and contract phases don't cause any
problems.

I can also take that data and make it available somewhere as well
and/or possibly annotate the output from the --dry-run option to explain
why some operations are scheduled to migrate instead of the expand and
contract phases.

JE

__
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] [Fuel] Getting rid of kickstart/preseed for all NEW releases

2015-01-26 Thread Vladimir Kuklin

I would also go through normal deprecation process, thus marking it as
deprecated and disabled by default. But I would leave an opportunity to
enable it.

On Mon, Jan 26, 2015 at 9:47 PM, Sergii Golovatiuk  wrote:

> Until we are sure IBP solves operation phase where we need to deliver
> updated packages so client will be able to provision new machines with
> these fixed packages, I would leave backward compatibility with normal
> provision. ... Just in case.
>
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Jan 26, 2015 at 4:56 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> My suggestion is to make IBP the only option available for all upcoming
>> OpenStack releases which are defined in openstack.yaml. It is to be
>> possible to install OS using kickstart for all currently available
>> OpenStack releases.
>>
>> Vladimir Kozhukalov
>>
>> On Mon, Jan 26, 2015 at 6:22 PM, Igor Kalnitsky 
>> wrote:
>>
>>> Just want to be sure I understand you correctly: do you propose to
>>> FORBID kickstart/preseed installation way in upcoming release at all?
>>>
>>> On Mon, Jan 26, 2015 at 3:59 PM, Vladimir Kozhukalov
>>>  wrote:
>>> > Subject is changed.
>>> >
>>> > Vladimir Kozhukalov
>>> >
>>> > On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukalov
>>> >  wrote:
>>> >>
>>> >> Dear Fuelers,
>>> >>
>>> >> As you might know we need it to be possible to install several
>>> versions of
>>> >> a particular OS (Ubuntu and Centos) by 6.1  As far as having
>>> different OS
>>> >> versions also means having different sets of packages and some of  the
>>> >> packages are installed and configured during provisioning stage, we
>>> need to
>>> >> have a kind of kickstart/preseed version mechanism.
>>> >>
>>> >> Cobbler is exactly such a mechanism. It allows us to have several
>>> Distros
>>> >> (installer images) and profiles (kickstart/preseed files). But
>>> >> unfortunately, for some reasons we have not been using those Cobbler's
>>> >> capabilities since the beginning of Fuel and it doesn't seem to be
>>> easily
>>> >> introduced into Nailgun to deal with the whole Cobbler life cycle.
>>> >>
>>> >> Anyway, we are moving towards IBP (image based provisioning) and we
>>> >> already have different images connected to different OpenStack
>>> releases
>>> >> (openstack.yaml) and everything else which is necessary for initial
>>> node
>>> >> configuration is serialized inside provision data (including profile
>>> name
>>> >> like 'ubuntu_1204' or 'ubuntu_1404') and we are able to choose
>>> cloud-init
>>> >> template by this profile name.
>>> >>
>>> >> And taking into account what it is written above, the suggestion is to
>>> >> completely avoid using kickstart/preseed based way of OS provisioning
>>> by 6.1
>>> >> for all new releases allowing ONLY old ones to use this way.
>>> >>
>>> >> Any opinions about that stuff are welcome.
>>> >>
>>> >> Vladimir Kozhukalov
>>> >
>>> >
>>> >
>>> >
>>> __
>>> > 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
>>>
>>
>>
>> __
>> 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
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] [Fuel] Getting rid of kickstart/preseed for all NEW releases

2015-01-26 Thread Igor Kalnitsky

+1 to Sergii. It's completely a crazy idea to replace one feature with
another and don't provide a fallback mode. We have no data how it
works on the user side in real life. I think it could be marked as
"deprecated", but it definitely must be present at least one release
yet.

On Mon, Jan 26, 2015 at 8:47 PM, Sergii Golovatiuk
 wrote:
> Until we are sure IBP solves operation phase where we need to deliver
> updated packages so client will be able to provision new machines with these
> fixed packages, I would leave backward compatibility with normal provision.
> ... Just in case.
>
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Jan 26, 2015 at 4:56 PM, Vladimir Kozhukalov
>  wrote:
>>
>> My suggestion is to make IBP the only option available for all upcoming
>> OpenStack releases which are defined in openstack.yaml. It is to be possible
>> to install OS using kickstart for all currently available OpenStack
>> releases.
>>
>> Vladimir Kozhukalov
>>
>> On Mon, Jan 26, 2015 at 6:22 PM, Igor Kalnitsky 
>> wrote:
>>>
>>> Just want to be sure I understand you correctly: do you propose to
>>> FORBID kickstart/preseed installation way in upcoming release at all?
>>>
>>> On Mon, Jan 26, 2015 at 3:59 PM, Vladimir Kozhukalov
>>>  wrote:
>>> > Subject is changed.
>>> >
>>> > Vladimir Kozhukalov
>>> >
>>> > On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukalov
>>> >  wrote:
>>> >>
>>> >> Dear Fuelers,
>>> >>
>>> >> As you might know we need it to be possible to install several
>>> >> versions of
>>> >> a particular OS (Ubuntu and Centos) by 6.1  As far as having different
>>> >> OS
>>> >> versions also means having different sets of packages and some of  the
>>> >> packages are installed and configured during provisioning stage, we
>>> >> need to
>>> >> have a kind of kickstart/preseed version mechanism.
>>> >>
>>> >> Cobbler is exactly such a mechanism. It allows us to have several
>>> >> Distros
>>> >> (installer images) and profiles (kickstart/preseed files). But
>>> >> unfortunately, for some reasons we have not been using those Cobbler's
>>> >> capabilities since the beginning of Fuel and it doesn't seem to be
>>> >> easily
>>> >> introduced into Nailgun to deal with the whole Cobbler life cycle.
>>> >>
>>> >> Anyway, we are moving towards IBP (image based provisioning) and we
>>> >> already have different images connected to different OpenStack
>>> >> releases
>>> >> (openstack.yaml) and everything else which is necessary for initial
>>> >> node
>>> >> configuration is serialized inside provision data (including profile
>>> >> name
>>> >> like 'ubuntu_1204' or 'ubuntu_1404') and we are able to choose
>>> >> cloud-init
>>> >> template by this profile name.
>>> >>
>>> >> And taking into account what it is written above, the suggestion is to
>>> >> completely avoid using kickstart/preseed based way of OS provisioning
>>> >> by 6.1
>>> >> for all new releases allowing ONLY old ones to use this way.
>>> >>
>>> >> Any opinions about that stuff are welcome.
>>> >>
>>> >> Vladimir Kozhukalov
>>> >
>>> >
>>> >
>>> >
>>> > __
>>> > 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
>>
>>
>>
>> __
>> 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
>

__
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] Mumble server for the mid-cycle meetup

2015-01-26 Thread Jeremy Stanley

On 2015-01-27 05:42:31 +1100 (+1100), Michael Still wrote:
> Sigh, we had troubles with mumble being unreliable, so now we're
> playing with google hangouts:
[...]

Also https://wiki.openstack.org/wiki/Infrastructure/Conferencing is
available for group voice communication (via phone and SIP clients)
if you want to give it a shot.
-- 
Jeremy Stanley

__
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] [tc][python-clients] More freedom for all python clients

2015-01-26 Thread Robert Collins

On 27 January 2015 at 09:56, Clint Byrum  wrote:

>  original order>



>> TripleO has done per service venvs for a couple years now, and it
>> doesn't solve the fragility issue that our unbounded deps cause. It
>> avoids most but not all conflicting deps within OpenStack, and none of
>> the 'upstream broke us' cases.
>>
>
> Note that we are not testing per-service venvs anymore because of the
> extreme high cost of building the controller images with so many separate
> venvs. We just put the openstack namespaced pieces in one big "openstack"
> venv now.

Yes, but the experience we have about the limitations of per-service
venvs is still relevant, no? Are you really saying 'do per-service
venvs because they work well', or are you agreeing with me that they
don't solve the problems plaguing the gate?

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [tc][python-clients] More freedom for all python clients

2015-01-26 Thread Clint Byrum

Excerpts from Robert Collins's message of 2015-01-26 12:29:37 -0800:
> On 27 January 2015 at 09:01, Joe Gordon  wrote:
> >
> >
> > On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague  wrote:
> >>
> >> On 01/20/2015 08:15 PM, Robert Collins wrote:
> >> > On 21 January 2015 at 10:21, Clark Boylan  wrote:
> >> > ...
> >> >> This ml thread came up in the TC meeting today and I am responding here
> >> >> to catch the thread up with the meeting. The soft update option is the
> >> >> suggested fix for non openstack projects that want to have most of
> >> >> their
> >> >> requirements managed by global requirements.
> >> >>
> >> >> For the project structure reform opening things up we should consider
> >> >> loosening the criteria to get on the list and make it primarily based
> >> >> on
> >> >> technical criteria such as py3k support, license compatibility,
> >> >> upstream
> >> >> support/activity, and so on (basically the current criteria with less
> >> >> of
> >> >> a focus on where the project comes from if it is otherwise healthy).
> >> >> Then individual projects would choose the subset they need to depend
> >> >> on.
> >> >> This model should be viable with different domains as well if we go
> >> >> that
> >> >> route.
> >> >>
> >> >> The following is not from the TC meeting but addressing other portions
> >> >> of this conversation:
> >> >>
> >> >> At least one concern with this option is that as the number of total
> >> >> requirements goes up is the difficulty in debugging installation
> >> >> conflicts becomes more difficult too. I have suggested that we could
> >> >> write tools to help with this. Install bisection based on pip logs for
> >> >> example, but these tools are still theoretical so I may be
> >> >> overestimating their usefulness.
> >> >>
> >> >> To address the community scaling aspect I think you push a lot of work
> >> >> back on deployers/users if we don't curate requirements for anything
> >> >> that ends up tagged as "production ready" (or whatever the equivalent
> >> >> tag becomes). Essentially we are saying "this doesn't scale for us so
> >> >> now you deal with the fallout. Have fun", which isn't very friendly to
> >> >> people consuming the software. We already have an absurd number of
> >> >> requirements and management of them has appeared to scale. I don't
> >> >> foresee my workload going up if we open up the list as suggested.
> >> >
> >> > Perhaps I missed something, but the initial request wasn't about
> >> > random packages, it was about other stackforge clients - these are
> >> > things in the ecosystem! I'm glad we have technical solutions, but it
> >> > just seems odd to me that adding them would ever have been
> >> > controversial.
> >>
> >> Well, I think Clark and I have different opinions of how much of a pain
> >> unwinding the requirements are, and how long these tend to leave the
> >> gate broken. I am happy to also put it in a "somebody elses problem
> >> field" for resolving the issues. :)
> >>
> >> Honestly, I think we're actually at a different point, where we need to
> >> stop assuming that the sane way to deal with python is to install it
> >> into system libraries, and just put every service in a venv and get rid
> >> of global requirements entirely. Global requirements was a scaling fix
> >> for getting to 10 coexisting projects. I don't think it actually works
> >> well with 50 ecosystem projects. Which is why I proposed the domains
> >> solution instead.
> >>
> >
> > ++ using per service virtual environments would help us avoid a whole class
> > of nasty issues. On the flip side doing this makes things harder for distros
> > to find a set of non-conflicting dependencies etc.
> >
> >>
> >> > On the pip solver side, joe gordon was working on a thing to install a
> >> > fixed set of packages by bypassing the pip resolver... not sure how
> >> > thats progressing.
> >>
> >> I think if we are talking seriously about bypassing the pip resolver, we
> >> should step back and think about that fact. Because now we're producting
> >> a custom installation process that will produce an answer for us, which
> >> is completely different than any answer that anyone else is getting for
> >> how to get a coherent system.
> >
> >
> > Fully agreed, I am looking into avoiding pips dependency solver for stable
> > branches only right now. But using per service venvs would be even better.
> >
>

> TripleO has done per service venvs for a couple years now, and it
> doesn't solve the fragility issue that our unbounded deps cause. It
> avoids most but not all conflicting deps within OpenStack, and none of
> the 'upstream broke us' cases.
> 

Note that we are not testing per-service venvs anymore because of the
extreme high cost of building the controller images with so many separate
venvs. We just put the openstack namespaced pieces in one big "openstack"
venv now.

__
OpenStack Development Mailing List (not for usag

Re: [openstack-dev] [infra] [stable] Stable check of openstack/nova failed - EnvironmentError: mysql_config not found

2015-01-26 Thread Jeremy Stanley

On 2015-01-26 11:31:12 -0800 (-0800), Adam Gandelman wrote:
> https://review.openstack.org/150120 should address it.

Yep--sorry--we weren't around much last week. I've approved
https://review.openstack.org/150081 (an earlier duplicate of that
fix) and rebuilt the offending image. All new nodes circa 17:45 UTC
should have the correct packages.
-- 
Jeremy Stanley

__
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] [tc][python-clients] More freedom for all python clients

2015-01-26 Thread Ben Nemec


On 01/26/2015 02:29 PM, Robert Collins wrote:
> TripleO has done per service venvs for a couple years now, and it
> doesn't solve the fragility issue that our unbounded deps cause. It
> avoids most but not all conflicting deps within OpenStack, and none of
> the 'upstream broke us' cases.

Note that a lot of us (our CI included) are no longer running with
separate venvs due to the time it takes to build them.

See common-venv from
http://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/toci_gate_test.sh#n21

Also, I don't see how this could work with distro packages (I'm not
saying there isn't a way, but I don't know what it would be), so I think
that's something I would definitely want an answer on before we decide
this is the way forward.

-Ben

> 
> -Rob
> 
> On 27 January 2015 at 09:01, Joe Gordon  wrote:
>>
>>
>> On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague  wrote:
>>>
>>> On 01/20/2015 08:15 PM, Robert Collins wrote:
 On 21 January 2015 at 10:21, Clark Boylan  wrote:
 ...
> This ml thread came up in the TC meeting today and I am responding here
> to catch the thread up with the meeting. The soft update option is the
> suggested fix for non openstack projects that want to have most of
> their
> requirements managed by global requirements.
>
> For the project structure reform opening things up we should consider
> loosening the criteria to get on the list and make it primarily based
> on
> technical criteria such as py3k support, license compatibility,
> upstream
> support/activity, and so on (basically the current criteria with less
> of
> a focus on where the project comes from if it is otherwise healthy).
> Then individual projects would choose the subset they need to depend
> on.
> This model should be viable with different domains as well if we go
> that
> route.
>
> The following is not from the TC meeting but addressing other portions
> of this conversation:
>
> At least one concern with this option is that as the number of total
> requirements goes up is the difficulty in debugging installation
> conflicts becomes more difficult too. I have suggested that we could
> write tools to help with this. Install bisection based on pip logs for
> example, but these tools are still theoretical so I may be
> overestimating their usefulness.
>
> To address the community scaling aspect I think you push a lot of work
> back on deployers/users if we don't curate requirements for anything
> that ends up tagged as "production ready" (or whatever the equivalent
> tag becomes). Essentially we are saying "this doesn't scale for us so
> now you deal with the fallout. Have fun", which isn't very friendly to
> people consuming the software. We already have an absurd number of
> requirements and management of them has appeared to scale. I don't
> foresee my workload going up if we open up the list as suggested.

 Perhaps I missed something, but the initial request wasn't about
 random packages, it was about other stackforge clients - these are
 things in the ecosystem! I'm glad we have technical solutions, but it
 just seems odd to me that adding them would ever have been
 controversial.
>>>
>>> Well, I think Clark and I have different opinions of how much of a pain
>>> unwinding the requirements are, and how long these tend to leave the
>>> gate broken. I am happy to also put it in a "somebody elses problem
>>> field" for resolving the issues. :)
>>>
>>> Honestly, I think we're actually at a different point, where we need to
>>> stop assuming that the sane way to deal with python is to install it
>>> into system libraries, and just put every service in a venv and get rid
>>> of global requirements entirely. Global requirements was a scaling fix
>>> for getting to 10 coexisting projects. I don't think it actually works
>>> well with 50 ecosystem projects. Which is why I proposed the domains
>>> solution instead.
>>>
>>
>> ++ using per service virtual environments would help us avoid a whole class
>> of nasty issues. On the flip side doing this makes things harder for distros
>> to find a set of non-conflicting dependencies etc.
>>
>>>
 On the pip solver side, joe gordon was working on a thing to install a
 fixed set of packages by bypassing the pip resolver... not sure how
 thats progressing.
>>>
>>> I think if we are talking seriously about bypassing the pip resolver, we
>>> should step back and think about that fact. Because now we're producting
>>> a custom installation process that will produce an answer for us, which
>>> is completely different than any answer that anyone else is getting for
>>> how to get a coherent system.
>>
>>
>> Fully agreed, I am looking into avoiding pips dependency solver for stable
>> branches only right now. But using per service venvs would be even better.
>>
>>>
>>>
>>> -Sean
>>

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

2015-01-26 Thread Robert Collins

TripleO has done per service venvs for a couple years now, and it
doesn't solve the fragility issue that our unbounded deps cause. It
avoids most but not all conflicting deps within OpenStack, and none of
the 'upstream broke us' cases.

-Rob

On 27 January 2015 at 09:01, Joe Gordon  wrote:
>
>
> On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague  wrote:
>>
>> On 01/20/2015 08:15 PM, Robert Collins wrote:
>> > On 21 January 2015 at 10:21, Clark Boylan  wrote:
>> > ...
>> >> This ml thread came up in the TC meeting today and I am responding here
>> >> to catch the thread up with the meeting. The soft update option is the
>> >> suggested fix for non openstack projects that want to have most of
>> >> their
>> >> requirements managed by global requirements.
>> >>
>> >> For the project structure reform opening things up we should consider
>> >> loosening the criteria to get on the list and make it primarily based
>> >> on
>> >> technical criteria such as py3k support, license compatibility,
>> >> upstream
>> >> support/activity, and so on (basically the current criteria with less
>> >> of
>> >> a focus on where the project comes from if it is otherwise healthy).
>> >> Then individual projects would choose the subset they need to depend
>> >> on.
>> >> This model should be viable with different domains as well if we go
>> >> that
>> >> route.
>> >>
>> >> The following is not from the TC meeting but addressing other portions
>> >> of this conversation:
>> >>
>> >> At least one concern with this option is that as the number of total
>> >> requirements goes up is the difficulty in debugging installation
>> >> conflicts becomes more difficult too. I have suggested that we could
>> >> write tools to help with this. Install bisection based on pip logs for
>> >> example, but these tools are still theoretical so I may be
>> >> overestimating their usefulness.
>> >>
>> >> To address the community scaling aspect I think you push a lot of work
>> >> back on deployers/users if we don't curate requirements for anything
>> >> that ends up tagged as "production ready" (or whatever the equivalent
>> >> tag becomes). Essentially we are saying "this doesn't scale for us so
>> >> now you deal with the fallout. Have fun", which isn't very friendly to
>> >> people consuming the software. We already have an absurd number of
>> >> requirements and management of them has appeared to scale. I don't
>> >> foresee my workload going up if we open up the list as suggested.
>> >
>> > Perhaps I missed something, but the initial request wasn't about
>> > random packages, it was about other stackforge clients - these are
>> > things in the ecosystem! I'm glad we have technical solutions, but it
>> > just seems odd to me that adding them would ever have been
>> > controversial.
>>
>> Well, I think Clark and I have different opinions of how much of a pain
>> unwinding the requirements are, and how long these tend to leave the
>> gate broken. I am happy to also put it in a "somebody elses problem
>> field" for resolving the issues. :)
>>
>> Honestly, I think we're actually at a different point, where we need to
>> stop assuming that the sane way to deal with python is to install it
>> into system libraries, and just put every service in a venv and get rid
>> of global requirements entirely. Global requirements was a scaling fix
>> for getting to 10 coexisting projects. I don't think it actually works
>> well with 50 ecosystem projects. Which is why I proposed the domains
>> solution instead.
>>
>
> ++ using per service virtual environments would help us avoid a whole class
> of nasty issues. On the flip side doing this makes things harder for distros
> to find a set of non-conflicting dependencies etc.
>
>>
>> > On the pip solver side, joe gordon was working on a thing to install a
>> > fixed set of packages by bypassing the pip resolver... not sure how
>> > thats progressing.
>>
>> I think if we are talking seriously about bypassing the pip resolver, we
>> should step back and think about that fact. Because now we're producting
>> a custom installation process that will produce an answer for us, which
>> is completely different than any answer that anyone else is getting for
>> how to get a coherent system.
>
>
> Fully agreed, I am looking into avoiding pips dependency solver for stable
> branches only right now. But using per service venvs would be even better.
>
>>
>>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> __
>> 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.opens

Re: [openstack-dev] [nova] Mumble server for the mid-cycle meetup

2015-01-26 Thread Robert Collins

every participant is muted... so there's no sound :(

On 27 January 2015 at 07:42, Michael Still  wrote:
> Sigh, we had troubles with mumble being unreliable, so now we're
> playing with google hangouts:
>
> https://plus.google.com/hangouts/_/gvieuyvxsvpvvsgs2vdmtqtbbea
>
> Michael
>
> On Tue, Jan 27, 2015 at 4:18 AM, Michael Still  wrote:
>> As an experiment, I've put the meetup onto a mumble server at
>> nova.rcbops.com. The server password is "midcycle".
>>
>> At the least this should let people listen in and hopefully comment if
>> they need to.
>>
>> Michael
>>
>> --
>> Rackspace Australia
>
>
>
> --
> Rackspace Australia
>
> __
> 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



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [tc][python-clients] More freedom for all python clients

2015-01-26 Thread Joe Gordon

On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague  wrote:

> On 01/20/2015 08:15 PM, Robert Collins wrote:
> > On 21 January 2015 at 10:21, Clark Boylan  wrote:
> > ...
> >> This ml thread came up in the TC meeting today and I am responding here
> >> to catch the thread up with the meeting. The soft update option is the
> >> suggested fix for non openstack projects that want to have most of their
> >> requirements managed by global requirements.
> >>
> >> For the project structure reform opening things up we should consider
> >> loosening the criteria to get on the list and make it primarily based on
> >> technical criteria such as py3k support, license compatibility, upstream
> >> support/activity, and so on (basically the current criteria with less of
> >> a focus on where the project comes from if it is otherwise healthy).
> >> Then individual projects would choose the subset they need to depend on.
> >> This model should be viable with different domains as well if we go that
> >> route.
> >>
> >> The following is not from the TC meeting but addressing other portions
> >> of this conversation:
> >>
> >> At least one concern with this option is that as the number of total
> >> requirements goes up is the difficulty in debugging installation
> >> conflicts becomes more difficult too. I have suggested that we could
> >> write tools to help with this. Install bisection based on pip logs for
> >> example, but these tools are still theoretical so I may be
> >> overestimating their usefulness.
> >>
> >> To address the community scaling aspect I think you push a lot of work
> >> back on deployers/users if we don't curate requirements for anything
> >> that ends up tagged as "production ready" (or whatever the equivalent
> >> tag becomes). Essentially we are saying "this doesn't scale for us so
> >> now you deal with the fallout. Have fun", which isn't very friendly to
> >> people consuming the software. We already have an absurd number of
> >> requirements and management of them has appeared to scale. I don't
> >> foresee my workload going up if we open up the list as suggested.
> >
> > Perhaps I missed something, but the initial request wasn't about
> > random packages, it was about other stackforge clients - these are
> > things in the ecosystem! I'm glad we have technical solutions, but it
> > just seems odd to me that adding them would ever have been
> > controversial.
>
> Well, I think Clark and I have different opinions of how much of a pain
> unwinding the requirements are, and how long these tend to leave the
> gate broken. I am happy to also put it in a "somebody elses problem
> field" for resolving the issues. :)
>
> Honestly, I think we're actually at a different point, where we need to
> stop assuming that the sane way to deal with python is to install it
> into system libraries, and just put every service in a venv and get rid
> of global requirements entirely. Global requirements was a scaling fix
> for getting to 10 coexisting projects. I don't think it actually works
> well with 50 ecosystem projects. Which is why I proposed the domains
> solution instead.
>
>
++ using per service virtual environments would help us avoid a whole class
of nasty issues. On the flip side doing this makes things harder for
distros to find a set of non-conflicting dependencies etc.


> > On the pip solver side, joe gordon was working on a thing to install a
> > fixed set of packages by bypassing the pip resolver... not sure how
> > thats progressing.
>
> I think if we are talking seriously about bypassing the pip resolver, we
> should step back and think about that fact. Because now we're producting
> a custom installation process that will produce an answer for us, which
> is completely different than any answer that anyone else is getting for
> how to get a coherent system.
>

Fully agreed, I am looking into avoiding pips dependency solver for stable
branches only right now. But using per service venvs would be even better.


>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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

[openstack-dev] [Swift] Swift GUI (free or open source)?

2015-01-26 Thread Adam Lawson

I'm researching for a web-based visualization that simply displays
OpenStack Swift and/or node status, cluster health etc in some manner.
being able to run a command would be cool but a little more than I need.
Does such a thing currently exist? I know about SwiftStack but I'm
wondering if there are other efforts that have produced a way to visualize
Swift telemetry.

Has anyone run across such a thing?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
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] [Fuel][Agent] Moving Fuel Agent to a separate repo

2015-01-26 Thread Mike Scherbakov

-1 to make changes now
+1 to Alexandra

Let's finish fuel-client first. Also, it is about prioritization. We have
many things to be resolved in 6.1 (e.g. package the rest of the stuff which
not yet packaged into RPM/DEB; split repos openstack/fuel/linux, etc.), and
fuel agent in particular has pretty low priority to me in 6.1.

In examples I have provided, which are essential for 6.1, we are
experiencing lack of hands. Let's see if we can focus our work on those
items and many other essential things, and come to this question later.

On Mon, Jan 26, 2015 at 10:29 PM, Aleksandra Fedorova <
afedor...@mirantis.com> wrote:

> It seems that we have general agreement about the idea, but to make it
> happen we need much more detailed proposal.
>
> Even with python-fuelclient it is not quite clear right now, which version
> of nailgun should be used to test it, and the opposite: which version of
> fuelclient we have to use in iso builds. We also don't handle it in the
> build system very well right now, as we use git hashes, and not fixed
> versions, or packages.
>
> Maybe we should complete the python-fuelclient transformation first and
> see how it is going to work for us?
> On Jan 26, 2015 8:59 PM, "Roman Prykhodchenko"  wrote:
>
>> Vladimir,
>>
>> As a fuel-separatist I give this initiative a big +1 because of the
>> following advantages I can see:
>>
>>  - Git is designed for keeping smaller single-compoent repos, keeping
>> everything to one repo is a discouraged pattern
>>  - Having a separate -core group that will only contain active core
>> reviewers for fuel-agent project so getting core-reviews will be easier.
>>  - It makes possible to re-use some of the existing jobs in OpenStack CI
>>  - Making independent releases becomes possible
>>
>> AFAIK fuel-agent is positioned as an independent provisioning tool which
>> will not be exclusively used by Fuel. There is a work in progress to
>> integrate it with Ironic. Integrating it to any other provisioning system
>> should also be possible then. From that perspective putting it into its own
>> repo also brings the following advantages:
>>
>>  - Connecting 3rd party CI will be possible
>>  - Getting involved for the new folks will be much easier
>>
>>
>> - romcheg
>>
>>
>> > 26 січ. 2015 о 17:42 Vladimir Kozhukalov 
>> написав(ла):
>> >
>> > Fuelers,
>> >
>> > As most of you might know we have a bunch of projects inside fuel-web
>> repo which are not directly related to Fuel Web application. Some of them
>> are tested together and it seemed we could end up with a set of
>> incompatibility issues if we separated them and stopped tracking their
>> versions on the git level (instead of release level).
>> >
>> > Recent activities about separating Fuel Client from Nailgun (api) make
>> me think we are mature enough to move all other not related project out of
>> fuel-web repo and bring them together not earlier than on the stage of
>> system/functional testing.
>> >
>> > Next step would be moving out Fuel Agent project. The reason is that it
>> is independent and potentially could be used even out of Fuel because its
>> data parsing mechanism is implemented so as to be agnostic to the data
>> format. Some people could be potentially interested in using it
>> independently with their own data format. It is tested together with other
>> Fuel components during system testing only.
>> >
>> >
>> >
>> > Vladimir Kozhukalov
>> >
>> __
>> > 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
>>
>>
> __
> 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
>
>


-- 
Mike Scherbakov
#mihgen
__
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] [infra] Re: [stable] Stable check of openstack/nova failed - EnvironmentError: mysql_config not found

2015-01-26 Thread Adam Gandelman

https://review.openstack.org/150120 should address it.

On Mon, Jan 26, 2015 at 11:16 AM, Adam Gandelman  wrote:

> Looking at the image build logs @ nodepool.openstack.org, it *looks* like
> package dependencies are not being installed properly on one of the slaves
> (hpcloud-b2.bare-precise): http://paste.ubuntu.com/9886045/  The failing
> periodic jobs all land on this b2 node. nodepool is, however, pre-caching
> devstack required packages (including libmysqlclient-dev) I wonder if that
> b2 node is incorrectly classified somewhere in puppet/etc as a devstack
> slave?
>
> Adam
>
>
>
> On Mon, Jan 26, 2015 at 3:55 AM, Ihar Hrachyshka 
> wrote:
>
>> The issue is still there, and I haven't heard anything from infra.
>> Updates, anyone?
>> /Ihar
>>
>>
>> On 01/21/2015 11:56 AM, Ihar Hrachyshka wrote:
>>
>>> Hi all,
>>>
>>> Any updates from infra on why it occurs? It's still one of the issues
>>> that make periodic stable jobs fail.
>>>
>>> We also have other failures due to missing packages on nodes. F.e.,
>>>
>>> keystone python-ldap installation failing due to missing devel files for
>>> openldap:
>>> http://logs.openstack.org/periodic-stableperiodicx-
>>> keystone-docs-icehouse/30c89e8/console.html
>>> http://logs.openstack.org/periodic-stableperiodic-
>>> keystone-python27-icehouse/2a77792/console.html
>>>
>>> /Ihar
>>>
>>> On 01/19/2015 09:17 AM, Alan Pevec wrote:
>>>
 - periodic-nova-docs-icehouse http://logs.openstack.org/
> periodic-stableperiodic-nova-docs-icehouse/a3d88ed/ : FAILURE in 1m
> 15s
>
 Same symptom as https://bugs.launchpad.net/openstack-ci/+bug/1336161
 which is marked as Fix released, could infra team check if all images
 are alright?
 This showed up in 3 periodic icehouse jobs over weekend, all on
 bare-precise-hpcloud-b2 nodes, I've listed them in
 https://etherpad.openstack.org/p/stable-tracker


 Cheers,
 Alan

 __

 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
>>>
>>
>>
>> 
>> __
>> 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

Re: [openstack-dev] [Fuel][Agent] Moving Fuel Agent to a separate repo

2015-01-26 Thread Aleksandra Fedorova

It seems that we have general agreement about the idea, but to make it
happen we need much more detailed proposal.

Even with python-fuelclient it is not quite clear right now, which version
of nailgun should be used to test it, and the opposite: which version of
fuelclient we have to use in iso builds. We also don't handle it in the
build system very well right now, as we use git hashes, and not fixed
versions, or packages.

Maybe we should complete the python-fuelclient transformation first and see
how it is going to work for us?
On Jan 26, 2015 8:59 PM, "Roman Prykhodchenko"  wrote:

> Vladimir,
>
> As a fuel-separatist I give this initiative a big +1 because of the
> following advantages I can see:
>
>  - Git is designed for keeping smaller single-compoent repos, keeping
> everything to one repo is a discouraged pattern
>  - Having a separate -core group that will only contain active core
> reviewers for fuel-agent project so getting core-reviews will be easier.
>  - It makes possible to re-use some of the existing jobs in OpenStack CI
>  - Making independent releases becomes possible
>
> AFAIK fuel-agent is positioned as an independent provisioning tool which
> will not be exclusively used by Fuel. There is a work in progress to
> integrate it with Ironic. Integrating it to any other provisioning system
> should also be possible then. From that perspective putting it into its own
> repo also brings the following advantages:
>
>  - Connecting 3rd party CI will be possible
>  - Getting involved for the new folks will be much easier
>
>
> - romcheg
>
>
> > 26 січ. 2015 о 17:42 Vladimir Kozhukalov 
> написав(ла):
> >
> > Fuelers,
> >
> > As most of you might know we have a bunch of projects inside fuel-web
> repo which are not directly related to Fuel Web application. Some of them
> are tested together and it seemed we could end up with a set of
> incompatibility issues if we separated them and stopped tracking their
> versions on the git level (instead of release level).
> >
> > Recent activities about separating Fuel Client from Nailgun (api) make
> me think we are mature enough to move all other not related project out of
> fuel-web repo and bring them together not earlier than on the stage of
> system/functional testing.
> >
> > Next step would be moving out Fuel Agent project. The reason is that it
> is independent and potentially could be used even out of Fuel because its
> data parsing mechanism is implemented so as to be agnostic to the data
> format. Some people could be potentially interested in using it
> independently with their own data format. It is tested together with other
> Fuel components during system testing only.
> >
> >
> >
> > Vladimir Kozhukalov
> >
> __
> > 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
>
>
__
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] [infra] Re: [stable] Stable check of openstack/nova failed - EnvironmentError: mysql_config not found

2015-01-26 Thread Adam Gandelman

Looking at the image build logs @ nodepool.openstack.org, it *looks* like
package dependencies are not being installed properly on one of the slaves
(hpcloud-b2.bare-precise): http://paste.ubuntu.com/9886045/  The failing
periodic jobs all land on this b2 node. nodepool is, however, pre-caching
devstack required packages (including libmysqlclient-dev) I wonder if that
b2 node is incorrectly classified somewhere in puppet/etc as a devstack
slave?

Adam



On Mon, Jan 26, 2015 at 3:55 AM, Ihar Hrachyshka 
wrote:

> The issue is still there, and I haven't heard anything from infra.
> Updates, anyone?
> /Ihar
>
>
> On 01/21/2015 11:56 AM, Ihar Hrachyshka wrote:
>
>> Hi all,
>>
>> Any updates from infra on why it occurs? It's still one of the issues
>> that make periodic stable jobs fail.
>>
>> We also have other failures due to missing packages on nodes. F.e.,
>>
>> keystone python-ldap installation failing due to missing devel files for
>> openldap:
>> http://logs.openstack.org/periodic-stableperiodicx-
>> keystone-docs-icehouse/30c89e8/console.html
>> http://logs.openstack.org/periodic-stableperiodic-
>> keystone-python27-icehouse/2a77792/console.html
>>
>> /Ihar
>>
>> On 01/19/2015 09:17 AM, Alan Pevec wrote:
>>
>>> - periodic-nova-docs-icehouse http://logs.openstack.org/
 periodic-stableperiodic-nova-docs-icehouse/a3d88ed/ : FAILURE in 1m 15s

>>> Same symptom as https://bugs.launchpad.net/openstack-ci/+bug/1336161
>>> which is marked as Fix released, could infra team check if all images
>>> are alright?
>>> This showed up in 3 periodic icehouse jobs over weekend, all on
>>> bare-precise-hpcloud-b2 nodes, I've listed them in
>>> https://etherpad.openstack.org/p/stable-tracker
>>>
>>>
>>> Cheers,
>>> Alan
>>>
>>> __
>>>
>>> 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
>>
>
>
> __
> 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

[openstack-dev] [openstack][nova] Question on rollback live migration at the destination

2015-01-26 Thread Robert Li (baoli)

Hi,

I’m looking at rollback_live_migration_at_destination() in compute/manager.py. 
If it’s shared storage (such as NFS, is_shared_instance_path is True), it’s not 
going to be called since _live_migration_cleanup_flags() will return False. Can 
anyone let me know what’s the reason behind it? So nothing needs to be cleaned 
up at the destination in such case? Should VIFs be unplugged, to say the least?

I’m working on the live migration support with SR-IOV macvtap interfaces. The 
devices allocated at the destination needs to be freed.

thanks,
Robert
__
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] [neutron] FYI: Just abandoned old reviews

2015-01-26 Thread Mohammad Banikazemi

Looks like some reviews which should have been marked by this script were
not. At least I noticed one such review [1].

[1] https://review.openstack.org/#/c/122382/

From:   Kyle Mestery 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   01/26/2015 10:21 AM
Subject:[openstack-dev] [neutron] FYI: Just abandoned old reviews

I just ran the Nova abandon script [1] against the neutron repositories, so
a lot of old reviews were cleaned out of the system this morning. If your
review needs to be re-instated, you can do this manually as the message
should indicate.

I've also proposed the abandon script into the neutron repository as well
for future use [2]. Thanks to Sean for pointing me at the script last week!

Thanks,
Kyle

[1]
https://github.com/openstack/nova/blob/master/tools/abandon_old_reviews.sh
[2] https://review.openstack.org/150055
__
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

Re: [openstack-dev] [Fuel] Getting rid of kickstart/preseed for all NEW releases

2015-01-26 Thread Sergii Golovatiuk

Until we are sure IBP solves operation phase where we need to deliver
updated packages so client will be able to provision new machines with
these fixed packages, I would leave backward compatibility with normal
provision. ... Just in case.



--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Mon, Jan 26, 2015 at 4:56 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> My suggestion is to make IBP the only option available for all upcoming
> OpenStack releases which are defined in openstack.yaml. It is to be
> possible to install OS using kickstart for all currently available
> OpenStack releases.
>
> Vladimir Kozhukalov
>
> On Mon, Jan 26, 2015 at 6:22 PM, Igor Kalnitsky 
> wrote:
>
>> Just want to be sure I understand you correctly: do you propose to
>> FORBID kickstart/preseed installation way in upcoming release at all?
>>
>> On Mon, Jan 26, 2015 at 3:59 PM, Vladimir Kozhukalov
>>  wrote:
>> > Subject is changed.
>> >
>> > Vladimir Kozhukalov
>> >
>> > On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukalov
>> >  wrote:
>> >>
>> >> Dear Fuelers,
>> >>
>> >> As you might know we need it to be possible to install several
>> versions of
>> >> a particular OS (Ubuntu and Centos) by 6.1  As far as having different
>> OS
>> >> versions also means having different sets of packages and some of  the
>> >> packages are installed and configured during provisioning stage, we
>> need to
>> >> have a kind of kickstart/preseed version mechanism.
>> >>
>> >> Cobbler is exactly such a mechanism. It allows us to have several
>> Distros
>> >> (installer images) and profiles (kickstart/preseed files). But
>> >> unfortunately, for some reasons we have not been using those Cobbler's
>> >> capabilities since the beginning of Fuel and it doesn't seem to be
>> easily
>> >> introduced into Nailgun to deal with the whole Cobbler life cycle.
>> >>
>> >> Anyway, we are moving towards IBP (image based provisioning) and we
>> >> already have different images connected to different OpenStack releases
>> >> (openstack.yaml) and everything else which is necessary for initial
>> node
>> >> configuration is serialized inside provision data (including profile
>> name
>> >> like 'ubuntu_1204' or 'ubuntu_1404') and we are able to choose
>> cloud-init
>> >> template by this profile name.
>> >>
>> >> And taking into account what it is written above, the suggestion is to
>> >> completely avoid using kickstart/preseed based way of OS provisioning
>> by 6.1
>> >> for all new releases allowing ONLY old ones to use this way.
>> >>
>> >> Any opinions about that stuff are welcome.
>> >>
>> >> Vladimir Kozhukalov
>> >
>> >
>> >
>> >
>> __
>> > 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
>>
>
>
> __
> 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

Re: [openstack-dev] [nova] Mumble server for the mid-cycle meetup

2015-01-26 Thread Michael Still

Sigh, we had troubles with mumble being unreliable, so now we're
playing with google hangouts:

https://plus.google.com/hangouts/_/gvieuyvxsvpvvsgs2vdmtqtbbea

Michael

On Tue, Jan 27, 2015 at 4:18 AM, Michael Still  wrote:
> As an experiment, I've put the meetup onto a mumble server at
> nova.rcbops.com. The server password is "midcycle".
>
> At the least this should let people listen in and hopefully comment if
> they need to.
>
> Michael
>
> --
> Rackspace Australia



-- 
Rackspace Australia

__
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] [neutron] lbaas driver implementation question

2015-01-26 Thread Jain, Vivek

Can you try to ping the client IP from your Load Balancer and see if that 
works. I am suspecting that default gateway used on LB is not correct.

Thanks,
Vivek

From: Shane McGough 
mailto:smcgo...@kemptechnologies.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, January 26, 2015 at 7:32 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron] lbaas driver implementation question

Hi all,

Implementing a driver for lbaas and am running into some trouble.

The load balancer is a VM hosted on the compute node within devstack and the 
driver can create vips, pools and members no problem.

The problem lies when trying to access the service hosted by the VIP.

>From TCP dumps on the load balancer instance we can see that the traffic hits 
>the load balancer and the load balancer replies but the reply does not reach 
>the client.

Is there an implementation reason why this might occur (i.e. not creating a 
port or doing some neutron configuration within the driver) or could there be 
another issue at play here.

We are using stable/juno devstack for test purposes. We can access the load 
balancer GUI no problem via the browser its just anything hosted by the LB 
services is inaccessible.

Any help would be appreciated

Thanks,
Shane.
__
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] [Fuel] 10Gbe performance issue.

2015-01-26 Thread Rick Jones


On 01/22/2015 03:19 AM, Piotr Korthals wrote:

Thanks, Rick looks like GRO was something we was missing in our setup.

Here are some results form my tests

iperf with GRO disabled on server side : 2,5-3Gbps
iperf with GRO enabled on server side :  3,5-4 Gbps (gro was enabled on
eth0, br-eth0, br-storage)

Additionally i used OVS VLAN splinters option "Enable OVS VLAN splinters
hard trunks workaround" of fuel deployment

iperf with GRO disabled using hw VLAN splinters and MTU 1,5k : ~5 Gbps
iperf with GRO disabled using hw VLAN splinters and MTU 9k: 9-10 Gbps
iperf with GRO enabled using hw VLAN splinters and MTU 1,5k  : 9-10 Gbps

Then i tested iperf between machines of 2 different configurations (with
OVS VLAN splinters, and without it),

default->OVS_VLAN_spliters (GRO disabled) : 2,5 Gbps
default->OVS_VLAN_spliters (GRO enabled) : 5 Gbps

OVS_VLAN_spliters->default (GRO disabled) : 2,5-3 Gbps
OVS_VLAN_spliters->default (GRO enabled) : 5-10 Gbps

This looks like OVS is not performing good enough in this setup for
tagged vlans (our br-storage is running on tagged vlan)

any commands?


None that come to mind at present, sorry.

rick


__
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] [tc] do we really need project tags in the governance repository?

On Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote:
> Doug Hellmann wrote:
> > [...]
> > So, my proposal is that we re-evaluate our decision to introduce a tagging 
> > system and complicated taxonomy to the *governance* repository, and think 
> > about whether the same information can either be found elsewhere already or 
> > *should live elsewhere* and needs to be developed there. We can keep the 
> > integrated release tag that we have in place now, but we should not adopt 
> > any other tags and we should phase out the tag system when we drop the 
> > integrated release tag.
> 
> I agree that tag application/removal could be more distributed. The
> original draft for the spec explicitly proposed that the TC delegates
> (some) tag application to other groups, but in those discussions you
> were the one resisting the idea and requiring that the TC retained clear
> oversight :)

The TC should be responsible for evaluating teams and projects that want
to join OpenStack. If we use tags for that purpose, then we should vote
on them. We don't seem to be using tags for that purpose, though (at
least not after we drop the incubated release tag).

> I'm open to alternative suggestions on where the list of tags, their
> definition and the list projects they apply to should live. If you don't
> like that being in the governance repository, what would have your
> preference ?

>From the very beginning I have taken the position that tags are by
themselves not sufficiently useful for evaluating projects. If someone
wants to choose between Ceilometer, Monasca, or StackTach, we're
unlikely to come up with tags that will let them do that. They need
in-depth discussions of deployment options, performance characteristics,
and feature trade-offs.

> That said, I object to only saying "this is all information that can be
> found elsewhere or should live elsewhere", because that is just keeping
> the current situation -- where that information exists somewhere but
> can't be efficiently found by our downstream consumers. We need a
> taxonomy and clear definitions for tags, so that our users can easily
> find, understand and navigate such project metadata.

As someone new to the project, I would not think to look in the
governance documents for "state" information about a project. I would
search for things like "install guide openstack" or "component list
openstack" and expect to find them in the documentation. So I think
putting the information in those (or similar) places will actually make
it easier to find for someone that hasn't been involved in the
discussion of tags and the governance repository.

If we need a component list with descriptions, let's build that. It can
be managed by a team of interested parties -- perhaps some of the
operators or deployers, for example. I don't know if we have an existing
place where it would make sense to put it, or if we need a new
repository. We've been applying DRY to the existing projects/programs
list and saying that because we already have a list in the governance
repository we shouldn't repeat that information elsewhere, but we're
also starting to go to a lot of lengths to define a format to hold
information (tags, with metadata, a taxonomy, etc.) that isn't needed
for project governance. That makes me think we're trying to force-fit
this idea into a single list.

> The tagging proposal (only one-month old) has so far received a pretty
> good reception from operators and other downstream users, who see it as
> a way to explain and contribute what type of information matters to
> them. The Technical Committee members are not the only people who can
> propose tags.

I agree that a product matrix with some basic information will be useful
for deployers and operators to find project details, which can then go
into more depth about the issues operators and other downstream users
care about. I just don't think the TC needs to host or maintain that
matrix itself.

When we talk about things going into the governance repository, we
should apply two rules. First, we should consider whether it is
*appropriate* for the TC to be making decisions about the topic.
Subjective tags fail this test. Second, we should consider whether it is
*necessary* for the TC to be making the decision. Objective tags fail
this test.

Doug

> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> 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

Re: [openstack-dev] [neutron][vpnaas] Can we require kernel 3.8+ for use with StrongSwan IPSec VPN for Kilo?

2015-01-26 Thread Eleouet Francois

Hi,

I'm probably too late, as it's already merged, but as explained in
initial review [0],
these checks are more about security than feature support:

ip netns uses mount namespaces since check-in
(and mount namespaces are supported since 2.4.19 [1])

The reason for this check was more to make sure that this command isn't used
outside a mount namespace to bind-mount arbitrary directory in the
root filesystem,
as neutron_netns_wrapper is allowed by CommandFilter. The only way i figured
out to check that at time of writing was to use namespace inodes, that
landed in 3.8 [2]

There may be anyway better solutions to ensure that this bind-mount is
done within a
namespace...

[0] 
https://review.openstack.org/#/c/33467/4/quantum/agent/linux/netns_wrapper.py
[1] http://lwn.net/Articles/531114/
[2] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=98f842e675f96ffac96e6c50315790912b2812be

francois.

2015-01-23 17:57 GMT+01:00 Paul Michali :
> Maybe I'm misunderstanding the issue?
>
> I thought the reason there is no version check currently, is because a check
> is being made to see if the process is in the same namespace as root for the
> net namespace (as a proxy to checking that the mount namespace is being
> used).
>
> The comment indicates that one could check the mount namespace, but that
> would require a kernel 3.8+.
>
> My question was whether we should check the mount namespace and therefore
> require a kernel of 3.8+?
>
> Maybe it is just easier to stick with (C).
>
> Thoughts? Should this review move forward as-is?
>
> Regards,
>
> PCM
>
>
> PCM (Paul Michali)
>
> IRC pc_m (irc.freenode.com)
> Twitter... @pmichali
>
>
> On Fri, Jan 23, 2015 at 10:37 AM, Kyle Mestery  wrote:
>>
>> According to the patch author, the check isn't necessary at all.
>>
>> On Fri, Jan 23, 2015 at 7:12 AM, Paul Michali  wrote:
>>>
>>> To summarize, should we...
>>>
>>> A) Assume all kernels will be 3.8+ and use mount namespace (risky?)
>>> B) Do a check to ensure kernel is 3.8+ and fall back to net namespace and
>>> mount --bind if not (more work).
>>> C) Just use net namespace as indication that namespace with mount --bind
>>> done (simple)
>>>
>>> Maybe it is best to just do the simple thing for now. I wanted to double
>>> check though, to see if the alternatives could/should be considered.
>>>
>>> Regards,
>>>
>>> PCM
>>>
>>>
>>> PCM (Paul Michali)
>>>
>>> IRC pc_m (irc.freenode.com)
>>> Twitter... @pmichali
>>>
>>>
>>> On Fri, Jan 23, 2015 at 1:35 AM, Joshua Zhang
>>>  wrote:

 pls note that actually this patch doesn't have minumum kernel
 requirement because it only uses 'mount --bind' and 'net namespace', not 
 use
 'mount namespace'. ('mount --bind' is since linux 2.4, 'net namespace' is
 since Linux 3.0, 'mount namespace' is since Linux 3.8).

 so I think sanity checks for 3.8 is not need, any thoughts ?

 thanks.


 On Fri, Jan 23, 2015 at 2:12 PM, Kevin Benton  wrote:
>
> >If we can consolidate that and use a single tool from the master
> > neutron repository, that would be my vote.
>
> +1 with a hook mechanism so the sanity checks stay in the *aas repos
> and they are only run if installed.
>
>
> On Thu, Jan 22, 2015 at 7:30 AM, Kyle Mestery 
> wrote:
>>
>> On Wed, Jan 21, 2015 at 10:27 AM, Ihar Hrachyshka
>>  wrote:
>>>
>>> On 01/20/2015 05:40 PM, Paul Michali wrote:
>>>
>>> Review https://review.openstack.org/#/c/146508/ is adding support for
>>> StrongSwan VPN, which needs mount bind to be able to specify different 
>>> paths
>>> for config files.
>>>
>>> The code, which used some older patch, does a test for
>>> /proc/1/ns/net, instead of /proc/1/ns/mnt, because it stated that the 
>>> latter
>>> is only supported in kernel 3.8+. That was a while ago, and I'm 
>>> wondering if
>>> the condition is still true.  If we know that for Kilo and on, we'll be
>>> dealing with 3.8+ kernels, we could use the more accurate test.
>>>
>>> Can we require 3.8+ kernel for this?
>>>
>>>
>>> I think we can but it's better to check with distributions. Red Hat
>>> wise, we ship a kernel that is newer than 3.8.
>>>
>>> If so, how and where do we ensure that is true?
>>>
>>>
>>> Ideally, you would implement a sanity check for the feature you need
>>> from the kernel. Though it opens a question of whether we want to ship
>>> multiple sanity check tools for each of repos (neutron + 3 *aas repos).
>>>
>> If we can consolidate that and use a single tool from the master
>> neutron repository, that would be my vote.
>>>
>>>
>>> Also, if you can kindly review the code here:
>>> https://review.openstack.org/#/c/146508/5/neutron_vpnaas/services/vpn/common/netns_wrapper.py,
>>> I'd really appreciate it, as I'm not versed in the Linux proc files

[openstack-dev] [Infra] Meeting Tuesday January 27th at 19:00 UTC

2015-01-26 Thread Elizabeth K. Joseph

Hi everyone,

The OpenStack Infrastructure (Infra) team is resuming our weekly
meetings on Tuesday January 27th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

And in case you missed it or would like a refresher, meeting logs and
minutes from our last meeting are available here:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-01-20-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-01-20-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-01-20-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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] [Fuel][Agent] Moving Fuel Agent to a separate repo

2015-01-26 Thread Roman Prykhodchenko

Vladimir,

As a fuel-separatist I give this initiative a big +1 because of the following 
advantages I can see:

 - Git is designed for keeping smaller single-compoent repos, keeping 
everything to one repo is a discouraged pattern
 - Having a separate -core group that will only contain active core reviewers 
for fuel-agent project so getting core-reviews will be easier.
 - It makes possible to re-use some of the existing jobs in OpenStack CI
 - Making independent releases becomes possible

AFAIK fuel-agent is positioned as an independent provisioning tool which will 
not be exclusively used by Fuel. There is a work in progress to integrate it 
with Ironic. Integrating it to any other provisioning system should also be 
possible then. From that perspective putting it into its own repo also brings 
the following advantages:

 - Connecting 3rd party CI will be possible
 - Getting involved for the new folks will be much easier


- romcheg


> 26 січ. 2015 о 17:42 Vladimir Kozhukalov  
> написав(ла):
> 
> Fuelers,
> 
> As most of you might know we have a bunch of projects inside fuel-web repo 
> which are not directly related to Fuel Web application. Some of them are 
> tested together and it seemed we could end up with a set of  incompatibility 
> issues if we separated them and stopped tracking their versions on the git 
> level (instead of release level).
> 
> Recent activities about separating Fuel Client from Nailgun (api) make me 
> think we are mature enough to move all other not related project out of 
> fuel-web repo and bring them together not earlier than on the stage of 
> system/functional testing.
> 
> Next step would be moving out Fuel Agent project. The reason is that it is 
> independent and potentially could be used even out of Fuel because its data 
> parsing mechanism is implemented so as to be agnostic to the data format. 
> Some people could be potentially interested in using it independently with 
> their own data format. It is tested together with other Fuel components 
> during system testing only.
> 
> 
> 
> Vladimir Kozhukalov
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [heat][hot]

2015-01-26 Thread Dmitry

thanks, exactly what I was looking for:
curl http://169.254.169.254/1.0/meta-data/instance-id

On Mon, Jan 26, 2015 at 7:31 PM, Zane Bitter  wrote:

> On 25/01/15 10:41, Dmitry wrote:
>
>> Hello,
>> I need to receive instance id as part of the instance installation script.
>> Something like:
>> params:
>>$current_id: {get_param: $this.id }
>>
>
> I have no idea what this is supposed to mean, sorry.
>
>  Is it possible?
>>
>
> The get_resource function will return the server UUID for a server
> resource, but you can't use it from within that resource itself (it would
> be a circular reference).
>
> The UUID of a server is provided to the server through the Nova metadata;
> you should retrieve it from there in your user_data script.
>
> cheers,
> Zane.
>
>
> __
> 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

Re: [openstack-dev] [Fuel][Agent] Moving Fuel Agent to a separate repo

2015-01-26 Thread Sebastian Kalinowski

+1 I'm all for separating it.

2015-01-26 17:52 GMT+01:00 Alexander Gordeev :

> Hello Vladimir,
>
> totally +1 for separating Fuel Agent out of fuel-web.
>
> what will happen with fuel_agent_ci ?
>
> On Mon, Jan 26, 2015 at 7:42 PM, Vladimir Kozhukalov
>  wrote:
> > Fuelers,
> >
> > As most of you might know we have a bunch of projects inside fuel-web
> repo
> > which are not directly related to Fuel Web application. Some of them are
> > tested together and it seemed we could end up with a set of
> incompatibility
> > issues if we separated them and stopped tracking their versions on the
> git
> > level (instead of release level).
> >
> > Recent activities about separating Fuel Client from Nailgun (api) make me
> > think we are mature enough to move all other not related project out of
> > fuel-web repo and bring them together not earlier than on the stage of
> > system/functional testing.
> >
> > Next step would be moving out Fuel Agent project. The reason is that it
> is
> > independent and potentially could be used even out of Fuel because its
> data
> > parsing mechanism is implemented so as to be agnostic to the data format.
> > Some people could be potentially interested in using it independently
> with
> > their own data format. It is tested together with other Fuel components
> > during system testing only.
> >
> >
> >
> > Vladimir Kozhukalov
> >
> >
> __
> > 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
>
__
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] how to handle the 247 migration / model issue for DB2?

2015-01-26 Thread Matt Riedemann

The change to add DB2 support to nova has hit a snag in the 247 
migration [1] where it's altering the pci_devices.deleted column to be 
nullable=True to match the model (it was defined nullable=False in the 
216 migration which didn't match the model).


The problem is DB2 won't allow unique constraints over nullable columns 
and the unique constraint is required for the foreign key constraint 
between pci_devices and compute_nodes via the compute_node_id column in 
pci_devices (DB2 requires that a FKey be on a column that's in a unique 
or primary key constraint, and those must be non-nullable with DB2).


So I'm kind of stuck with what to do here. As discussed in the change 
with Johannes (and Jay Pipes in IRC a week ago), it's kind of silly that 
the deleted column is nullable (am I missing something), but that's 
defined in the SoftDeleteMixin in oslo.db [2] so it's pervasive.


I see our options as (1) diverge the pci_devices.deleted model for DB2 
and/or (2) add a HardDeleteMixin to oslo.db where deleted is 
nullable=False, then work that into nova but it's going to require a big 
migration (I'm thinking FKey drops, UC drops, table alterations, then 
re-add the UCs and FKeys over the deleted columns that were altered, 
plus possibly a CLI to scan the database looking for rows where deleted 
is NULL, like we did for instances.uuid when making that non-nullable).


Option (1) is obviously a short-term fix and in my opinion relatively 
painless since we aren't generating the DB schema from the modeles (yet, 
until Johannes has his vision realized :) ).  Option (2) is going to 
take some work, but I think it makes sense as something to do regardless 
of DB2's restrictions here.


Thoughts?

[1] 
https://review.openstack.org/#/c/69047/38/nova/db/sqlalchemy/migrate_repo/versions/247_nullable_mismatch.py
[2] 
http://git.openstack.org/cgit/openstack/oslo.db/tree/oslo_db/sqlalchemy/models.py#n122


--

Thanks,

Matt Riedemann


__
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] [heat][hot]

2015-01-26 Thread Zane Bitter


On 25/01/15 10:41, Dmitry wrote:

Hello,
I need to receive instance id as part of the instance installation script.
Something like:
params:
   $current_id: {get_param: $this.id }


I have no idea what this is supposed to mean, sorry.


Is it possible?


The get_resource function will return the server UUID for a server 
resource, but you can't use it from within that resource itself (it 
would be a circular reference).


The UUID of a server is provided to the server through the Nova 
metadata; you should retrieve it from there in your user_data script.


cheers,
Zane.

__
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] [Fuel] [UI] Deploy Changes dialog redesign

2015-01-26 Thread Igor Kalnitsky

+1 for removing attribute.

@Evgeniy, I'm not sure that this attribute really shows all changes
that's going to be done.

On Mon, Jan 26, 2015 at 7:11 PM, Evgeniy L  wrote:
> To be more specific, +1 for removing this information from UI, not from
> backend.
>
> On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L  wrote:
>>
>> Hi,
>>
>> I agree that this information is useless, but it's not really clear what
>> you are going
>> to show instead, will you completely remove the information about nodes
>> for deployment?
>> I think the list of nodes for deployment (without detailed list of
>> changes) can be useful
>> for the user.
>>
>> Thanks,
>>
>> On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh
>>  wrote:
>>>
>>> +1 for removing "changes" attribute. It's useless now. If there are no
>>> plans to add something else there, let's remove it.
>>>
>>> 2015-01-26 11:39 GMT+03:00 Julia Aranovich :

 Hi All,

 Since we changed Deploy Changes pop-up and added processing of role
 limits and restrictions I would like to raise a question of it's subsequent
 refactoring.

 In particular, I mean 'changes' attribute of cluster model. It's
 displayed in Deploy Changes dialog in the following format:

 Changed disks configuration on the following nodes:

 Changed interfaces configuration on the following nodes:

 Changed network settings
 Changed OpenStack settings

 This list looks absolutely useless.

 It doesn't make any sense to display lists of new, not deployed nodes
 with changed disks/interfaces. It's obvious I think that new nodes
 attributes await deployment. At the same time user isn't able to change
 disks/interfaces on deployed nodes (at least in UI). So, such node name
 lists are definitely redundant.
 Networks and settings are also locked after deployment finished.

 I tend to get rid of cluster model 'changes' attribute at all.

 It is important for me to know your opinion, to make a final decision.
 Please feel free and share your ideas and concerns if any.

 Regards,
 Julia

 --
 Kind Regards,
 Julia Aranovich,
 Software Engineer,
 Mirantis, Inc
 +7 (905) 388-82-61 (cell)
 Skype: juliakirnosova
 www.mirantis.ru
 jaranov...@mirantis.com

 __
 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

>>>
>>>
>>>
>>> --
>>> Vitaly Kramskikh,
>>> Fuel UI Tech Lead,
>>> Mirantis, Inc.
>>>
>>>
>>> __
>>> 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
>

__
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] Mumble server for the mid-cycle meetup

2015-01-26 Thread Michael Still

As an experiment, I've put the meetup onto a mumble server at
nova.rcbops.com. The server password is "midcycle".

At the least this should let people listen in and hopefully comment if
they need to.

Michael

-- 
Rackspace Australia

__
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] [tc] do we really need project tags in the governance repository?

2015-01-26 Thread Thierry Carrez

(this may have been sent multiple times as I experience email issues,
sorry for the noise if that's indeed the case)

Doug Hellmann wrote:
> [...] 
> So, my proposal is that we re-evaluate our decision to introduce a tagging 
> system and complicated taxonomy to the *governance* repository, and think 
> about whether the same information can either be found elsewhere already or 
> *should live elsewhere* and needs to be developed there. We can keep the 
> integrated release tag that we have in place now, but we should not adopt any 
> other tags and we should phase out the tag system when we drop the integrated 
> release tag.

I agree that tag application/removal could be more distributed. The
original draft for the spec explicitly proposed that the TC delegates
(some) tag application to other groups, but in those discussions you
were the one resisting the idea and requiring that the TC retained clear
oversight :)

I'm open to alternative suggestions on where the list of tags, their
definition and the list projects they apply to should live. If you don't
like that being in the governance repository, what would have your
preference ?

That said, I object to only saying "this is all information that can be
found elsewhere or should live elsewhere", because that is just keeping
the current situation -- where that information exists somewhere but
can't be efficiently found by our downstream consumers. We need a
taxonomy and clear definitions for tags, so that our users can easily
find, understand and navigate such project metadata.

The tagging proposal (only one-month old) has so far received a pretty
good reception from operators and other downstream users, who see it as
a way to explain and contribute what type of information matters to
them. The Technical Committee members are not the only people who can
propose tags.

-- 
Thierry Carrez (ttx)

__
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] [tc] do we really need project tags in the governance repository?

2015-01-26 Thread Thierry Carrez

Doug Hellmann wrote:
> [...]
> So, my proposal is that we re-evaluate our decision to introduce a tagging 
> system and complicated taxonomy to the *governance* repository, and think 
> about whether the same information can either be found elsewhere already or 
> *should live elsewhere* and needs to be developed there. We can keep the 
> integrated release tag that we have in place now, but we should not adopt any 
> other tags and we should phase out the tag system when we drop the integrated 
> release tag.

I agree that tag application/removal could be more distributed. The
original draft for the spec explicitly proposed that the TC delegates
(some) tag application to other groups, but in those discussions you
were the one resisting the idea and requiring that the TC retained clear
oversight :)

I'm open to alternative suggestions on where the list of tags, their
definition and the list projects they apply to should live. If you don't
like that being in the governance repository, what would have your
preference ?

That said, I object to only saying "this is all information that can be
found elsewhere or should live elsewhere", because that is just keeping
the current situation -- where that information exists somewhere but
can't be efficiently found by our downstream consumers. We need a
taxonomy and clear definitions for tags, so that our users can easily
find, understand and navigate such project metadata.

The tagging proposal (only one-month old) has so far received a pretty
good reception from operators and other downstream users, who see it as
a way to explain and contribute what type of information matters to
them. The Technical Committee members are not the only people who can
propose tags.

-- 
Thierry Carrez (ttx)

__
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] [cinder] [nova] [scheduler] Nova node name passed to Cinder

2015-01-26 Thread Vishvananda Ishaya

Nova passes ip, iqn, and hostname into initialize_connection. That should give 
you the info you need.

Vish

On Jan 26, 2015, at 3:21 AM, Philipp Marek  wrote:

> Hello everybody,
> 
> I'm currently working on providing DRBD as a block storage protocol.
> For that the cinder volume driver needs to know at
> 
>initialize_connection,
>create_export, and
>ensure_export
> 
> time which Nova host will be used to access the data.
> 
> I'd like to ask for a bit of help; can somebody tell me which part of
> the code decides that, and where the data flows?
> Is it already known at that time which node will receive the VM?
> 
> The arguments passed to this functions already include an
> "attached_host" value, sadly it's currently given as "None"...
> 
> 
> Thank you for any tips, ideas, and pointers into the code - and,
> of course, even more so for full-blown patches on review.openstack.org ;)
> 
> 
> Regards,
> 
> Phil
> 
> 
> -- 
> : Ing. Philipp Marek
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com :
> 
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> 
> __
> 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

Re: [openstack-dev] [QA] Prototype of the script for Tempest auto-configuration

2015-01-26 Thread Albert

HI,

We at midokura have this automated as well, let me explain our flow so may be 
it useful for you guys:

In my opinion tempest autoconf tool should be extremely bounded to rc files 
where the credentials are, plus the url of the keystone, those are the minimum 
requiremenets for such tool, after that it is just straight forward to feed it 
with the rest of the details. 

Our current approach is that we deploy our cloud with ansible and we produce a 
tempest.con with that deployment, then I fetch this file that is sitting in the 
controller node, and move it wherever is my tempest host and through some 
python script and the help of simpleconfigparser I finalise to set it up for 
our use.

best,
Albert
 

> On 26 Jan 2015, at 15:39, Timur Nurlygayanov  
> wrote:
> 
> Hi,
> 
> Yaroslav, thank you for raising the question, I realy like this feature, I 
> discussed this script with several people during the OpenStack summit in 
> Paris and heard many the same things - we need to have something like this to 
> execute tempest tests automatically for validation of different production 
> and test OpenStack clouds - it is real pain to create our own separate 
> scripts for each project / team which will configure Tempest for some 
> specific configurations / installations, because tempest configuration file 
> can be changed and we will need to update our scripts.
> 
> We need to discuss, first of all, what we need to change in this script 
> before this script will be merged.
> As I can see, the spec description [1] not fully meet the current 
> implementation [2] and the spec looks really general - probably we can 
> describe separate 'simple' spec for this script and just abandon the current 
> spec or update the spec to sync spec and this script?
> 
> David, we found many issues with the current version of script, many tempest 
> tests failed for our custom OpenStack configurations (for example, with and 
> without Swift or Ceph) and we have our own scripts which already can solve 
> the problem. Can we join you and edit the patch together? (or we can describe 
> our ideas in the comments for the patch).  
> 
> Also, looks like we need review from Tempest core team - they can write more 
> valuable comments and suggest some cool ideas for the implementation.
> 
> [1] https://review.openstack.org/#/c/94473 
> 
> [2] https://review.openstack.org/#/c/133245
>  
> 
> On Fri, Jan 23, 2015 at 7:12 PM, Yaroslav Lobankov  > wrote:
> Hello everyone,
> 
> I would like to discuss the following patch [1] for Tempest. I think that 
> such feature 
> as auto-configuration of Tempest would be very useful for many engineers and 
> users. 
> I have recently tried to use the script from [1]. I rebased the patch on 
> master and ran the script. 
> The script was finished without any errors and the tempest.conf was 
> generated! Of course, 
> this patch needs a lot of work, but the idea looks very cool! 
> 
> Also I would like to thank David Kranz for his working on initial version of 
> the script.
> 
> Any thoughts?
> 
> [1] https://review.openstack.org/#/c/133245 
> 
> 
> Regards,
> Yaroslav Lobankov.
> 
> __
> 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 
> 
> 
> 
> 
> 
> -- 
> 
> Timur,
> Senior QA Engineer
> OpenStack Projects
> Mirantis Inc
> __
> 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

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

2015-01-26 Thread Evgeniy L

To be more specific, +1 for removing this information from UI, not from
backend.

On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L  wrote:

> Hi,
>
> I agree that this information is useless, but it's not really clear what
> you are going
> to show instead, will you completely remove the information about nodes
> for deployment?
> I think the list of nodes for deployment (without detailed list of
> changes) can be useful
> for the user.
>
> Thanks,
>
> On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh  > wrote:
>
>> +1 for removing "changes" attribute. It's useless now. If there are no
>> plans to add something else there, let's remove it.
>>
>> 2015-01-26 11:39 GMT+03:00 Julia Aranovich :
>>
>>> Hi All,
>>>
>>> Since we changed Deploy Changes pop-up and added processing of role
>>> limits and restrictions  I
>>> would like to raise a question of it's subsequent refactoring.
>>>
>>> In particular, I mean 'changes' attribute of cluster model. It's
>>> displayed in Deploy Changes dialog in the following format
>>> :
>>>
>>>- Changed disks configuration on the following nodes:
>>>- 
>>>- Changed interfaces configuration on the following nodes:
>>>   - 
>>>- Changed network settings
>>>- Changed OpenStack settings
>>>
>>> This list looks absolutely useless.
>>>
>>> It doesn't make any sense to display lists of new, not deployed nodes
>>> with changed disks/interfaces. It's obvious I think that new nodes
>>> attributes await deployment. At the same time user isn't able to change
>>> disks/interfaces on deployed nodes (at least in UI). So, such node name
>>> lists are definitely redundant.
>>> Networks and settings are also locked after deployment finished.
>>>
>>>
>>> I tend to get rid of cluster model 'changes' attribute at all.
>>>
>>> It is important for me to know your opinion, to make a final decision.
>>> Please feel free and share your ideas and concerns if any.
>>>
>>>
>>> Regards,
>>> Julia
>>>
>>> --
>>> Kind Regards,
>>> Julia Aranovich,
>>> Software Engineer,
>>> Mirantis, Inc
>>> +7 (905) 388-82-61 (cell)
>>> Skype: juliakirnosova
>>> www.mirantis.ru
>>> jaranov...@mirantis.com 
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Vitaly Kramskikh,
>> Fuel UI Tech Lead,
>> Mirantis, Inc.
>>
>> __
>> 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

[openstack-dev] [cinder] More Details for Mid-Cycle meetup:

2015-01-26 Thread Jay S. Bryant


All,

I have updated the mid-cycle meetup etherpad 
(https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup) with more 
details with regards to finding the right building on the IBM site and 
have also added my cell phone number to the notes.  Please don't 
hesitate to call or text me with questions.


I have updated the note on dinner at Rudy's, it is on Tuesday, not 
Monday.  For those of you who are in town tonight (1/26), let me know.  
Going to try to get those who are interested together for dinner.


Look forward to seeing you all soon!

Jay

__
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] [Fuel][Agent] Moving Fuel Agent to a separate repo

2015-01-26 Thread Alexander Gordeev

Hello Vladimir,

totally +1 for separating Fuel Agent out of fuel-web.

what will happen with fuel_agent_ci ?

On Mon, Jan 26, 2015 at 7:42 PM, Vladimir Kozhukalov
 wrote:
> Fuelers,
>
> As most of you might know we have a bunch of projects inside fuel-web repo
> which are not directly related to Fuel Web application. Some of them are
> tested together and it seemed we could end up with a set of  incompatibility
> issues if we separated them and stopped tracking their versions on the git
> level (instead of release level).
>
> Recent activities about separating Fuel Client from Nailgun (api) make me
> think we are mature enough to move all other not related project out of
> fuel-web repo and bring them together not earlier than on the stage of
> system/functional testing.
>
> Next step would be moving out Fuel Agent project. The reason is that it is
> independent and potentially could be used even out of Fuel because its data
> parsing mechanism is implemented so as to be agnostic to the data format.
> Some people could be potentially interested in using it independently with
> their own data format. It is tested together with other Fuel components
> during system testing only.
>
>
>
> Vladimir Kozhukalov
>
> __
> 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

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

2015-01-26 Thread Evgeniy L

Hi,

I agree that this information is useless, but it's not really clear what
you are going
to show instead, will you completely remove the information about nodes for
deployment?
I think the list of nodes for deployment (without detailed list of changes)
can be useful
for the user.

Thanks,

On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh 
wrote:

> +1 for removing "changes" attribute. It's useless now. If there are no
> plans to add something else there, let's remove it.
>
> 2015-01-26 11:39 GMT+03:00 Julia Aranovich :
>
>> Hi All,
>>
>> Since we changed Deploy Changes pop-up and added processing of role
>> limits and restrictions  I
>> would like to raise a question of it's subsequent refactoring.
>>
>> In particular, I mean 'changes' attribute of cluster model. It's
>> displayed in Deploy Changes dialog in the following format
>> :
>>
>>- Changed disks configuration on the following nodes:
>>- 
>>- Changed interfaces configuration on the following nodes:
>>   - 
>>- Changed network settings
>>- Changed OpenStack settings
>>
>> This list looks absolutely useless.
>>
>> It doesn't make any sense to display lists of new, not deployed nodes
>> with changed disks/interfaces. It's obvious I think that new nodes
>> attributes await deployment. At the same time user isn't able to change
>> disks/interfaces on deployed nodes (at least in UI). So, such node name
>> lists are definitely redundant.
>> Networks and settings are also locked after deployment finished.
>>
>>
>> I tend to get rid of cluster model 'changes' attribute at all.
>>
>> It is important for me to know your opinion, to make a final decision.
>> Please feel free and share your ideas and concerns if any.
>>
>>
>> Regards,
>> Julia
>>
>> --
>> Kind Regards,
>> Julia Aranovich,
>> Software Engineer,
>> Mirantis, Inc
>> +7 (905) 388-82-61 (cell)
>> Skype: juliakirnosova
>> www.mirantis.ru
>> jaranov...@mirantis.com 
>>
>> __
>> 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
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
>
> __
> 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

[openstack-dev] [Fuel][Agent] Moving Fuel Agent to a separate repo

Fuelers,

As most of you might know we have a bunch of projects inside fuel-web repo
which are not directly related to Fuel Web application. Some of them are
tested together and it seemed we could end up with a set of
 incompatibility issues if we separated them and stopped tracking their
versions on the git level (instead of release level).

Recent activities about separating Fuel Client from Nailgun (api) make me
think we are mature enough to move all other not related project out of
fuel-web repo and bring them together not earlier than on the stage of
system/functional testing.

Next step would be moving out Fuel Agent project. The reason is that it is
independent and potentially could be used even out of Fuel because its data
parsing mechanism is implemented so as to be agnostic to the data format.
Some people could be potentially interested in using it independently with
their own data format. It is tested together with other Fuel components
during system testing only.



Vladimir Kozhukalov
__
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] [Fuel] [UI] Deploy Changes dialog redesign

2015-01-26 Thread Vitaly Kramskikh

+1 for removing "changes" attribute. It's useless now. If there are no
plans to add something else there, let's remove it.

2015-01-26 11:39 GMT+03:00 Julia Aranovich :

> Hi All,
>
> Since we changed Deploy Changes pop-up and added processing of role
> limits and restrictions  I
> would like to raise a question of it's subsequent refactoring.
>
> In particular, I mean 'changes' attribute of cluster model. It's displayed
> in Deploy Changes dialog in the following format
> :
>
>- Changed disks configuration on the following nodes:
>- 
>- Changed interfaces configuration on the following nodes:
>   - 
>- Changed network settings
>- Changed OpenStack settings
>
> This list looks absolutely useless.
>
> It doesn't make any sense to display lists of new, not deployed nodes with
> changed disks/interfaces. It's obvious I think that new nodes attributes
> await deployment. At the same time user isn't able to change
> disks/interfaces on deployed nodes (at least in UI). So, such node name
> lists are definitely redundant.
> Networks and settings are also locked after deployment finished.
>
>
> I tend to get rid of cluster model 'changes' attribute at all.
>
> It is important for me to know your opinion, to make a final decision.
> Please feel free and share your ideas and concerns if any.
>
>
> Regards,
> Julia
>
> --
> Kind Regards,
> Julia Aranovich,
> Software Engineer,
> Mirantis, Inc
> +7 (905) 388-82-61 (cell)
> Skype: juliakirnosova
> www.mirantis.ru
> jaranov...@mirantis.com 
>
> __
> 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
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] [Fuel][client][IMPORTANT] Making Fuel Client a separate project

That is the great news and it was my dream since more than a year ago.

By the way, the suggestion is to move all other projects which are not
directly related to Fuel Web application to separate repositories. Doing
this one by one seems gonna work. So the next project would be, let's say,
fuel-agent which is completely about provisioning. Will create a separate
ML thread.

Vladimir Kozhukalov

On Mon, Jan 26, 2015 at 6:40 PM, Roman Prykhodchenko  wrote:

> Hi guys,
>
> status update incoming.
>
>  - ISO build scripts have been switched to stackforge/python-fuelclient as
> the main source of Fuel Client [1] so please move all
>you’re patches that touch fuelclient [2] directory to the new Gerrit
> repo.
>  - The patch that removes the fuelclient directory from fuel-web repo [3]
> has passed BVT and now is been on the final testing
>at the QA dept. As soon as QA guys post their confirmation that it
> works it will be landed.
>
>
> References:
>
> [1] https://review.openstack.org/#/c/149672/
> [2]
> https://review.openstack.org/#/q/project:stackforge/fuel-web+status:open+file:%255Efuelclient/.*,n,z
> [3] https://review.openstack.org/#/c/149797/
>
>
> - romcheg
>
> > 16 січ. 2015 о 17:13 Roman Prykhodchenko  написав(ла):
> >
> > Hi Fuelers,
> >
> > this is another status update.
> >
> > - OpenStack-CI is now running pep8 checks [1] for patches to
> python-fuelclient.
> > - The script for running python tests in on review [2] and some guys are
> requested to test it and give some feedback
> > - Fuel CI is now allowed to vote on python-fuelclient [3] so the next
> stage it to merge both run_test.sh [2] and Jenkins job to FuelCI [4]
> > - It’s now planned to finish this migration on Tuesday next week, so it
> will be possible to build ISO from python-fuelclient repo
> >
> > Stay tuned.
> >
> >
> > References:
> >
> > 1. Run pep8 jobs for python-fuelclient
> https://review.openstack.org/#/c/147801
> > 2. Run Python tests https://review.openstack.org/#/c/146950
> > 3. Allow FuelCI voting on python-fuelclient
> https://review.openstack.org/#/c/147429
> > 4. Add verify-python-fuelclient https://review.fuel-infra.org/#/c/1989
> >
> >
> > - romcheg
> >
> >> 13 січ. 2015 о 15:58 Roman Prykhodchenko  написав(ла):
> >>
> >> Folks,
> >>
> >> this is another status update.
> >>
> >>  • The patch for moving python-fuelclient to a separate project has
> been merged. At the moment Stackforge repository, a Gerrit project and all
> Gerrit groups have been created. There are two guys in the core group: I
> and Dmitri Pyzhov (dpyz...@mirantis.com). You can obtain the sources from
> https://github.com/stackforge/python-fuelclient.
> >>  • I kindly ask authors of all changes to Fuel Client to start
> moving them to the new project.
> >>  • At the moment I’m working on enabling the same testing process
> in FuelCI, testing in OpenStack CI will be enabled later because that
> requires some refactoring of the existing tests in python-fuelclient.
> >>
> >> Stay tuned.
> >>
> >>
> >> - romcheg
> >>
> >>> 12 січ. 2015 о 12:44 Roman Prykhodchenko  написав(ла):
> >>>
> >>> Hi folks!
> >>>
> >>> This is a status update.
> >>> • Right now the patch for creating a new project on Stackforge is
> blocked by a bug in Zuul [1] which is actually a bug in python-daemon, the
> patch for this is already published [2] and waiting for being approved.
> >>> • After the patch is merged and all projects and groups are
> created I will file a request to perform initial setup of core groups. Once
> they are created it will be possible to land new patches.
> >>> • Meanwhile OSCI team is working [3] on adjusting build system to
> use python-fuelclient from PyPi [4].
> >>> Stay tuned for further updates.
> >>>
> >>> References:
> >>> • Zuul’s tests fail with dependencies error
> https://storyboard.openstack.org/#!/story/2000107
> >>> • Pin python-daemon<2.0 https://review.openstack.org/#/c/146350/
> >>> • Create repositories for python-fuelclient package
> https://bugs.launchpad.net/fuel/+bug/1409673
> >>> • python-fuelclient on PyPi
> https://pypi.python.org/pypi/python-fuelclient
> >>>
> >>>
>  9 січ. 2015 о 15:14 Roman Prykhodchenko  написав(ла):
> 
>  Hi folks,
> 
>  according to the Fuel client refactoring plan [1] it’s necessary to
> move it out to a separate repository on Stackforge.
> 
>  The process of doing that consists of two major steps:
>  - Landing a patch [2] to project-config for creating a new Stackforge
> project
>  - Creating an initial core group for python-fuelclient
>  - Moving all un-merged patches from fuel-web to python-fuelclient
> gerrit repo
> 
>  The first step of this process has already been started so I kindly
> ask all fuelers to DO NOT MERGE any new patches to fuel-web IF THEY DO
> touch fuelclient folder.
>  After the project is set up I will let everyone know about that and
> will tell what to do after that so I encourage all

Re: [openstack-dev] [Heat] Convergence Phase 1 implementation plan

2015-01-26 Thread Sergey Kraynev

On 24 January 2015 at 00:00, Zane Bitter  wrote:

> I've mentioned this in passing a few times, but I want to lay it out here
> in a bit more detail for comment. Basically we're implementing convergence
> at a time when we still have a lot of 'unit' tests that are really
> integration tests, and we don't want to have to rewrite them to anticipate
> this new architecture, nor wait until they have all been converted into
> functional tests. And of course it goes without saying that we have to land
> all of these changes without breaking anything for users.
>
> To those ends, my proposal is that we (temporarily) support two code
> paths: the existing, legacy in-memory path and the new, distributed
> convergence path. Stacks will contain a field indicating which code path
> they were created with, and each stack will be operated on only by that
> same code path throughout its lifecycle (i.e. a stack created in legacy
> mode will always use the legacy code). We'll add a config option, off by
> default, to enable the new code path. That way users can switch over at a
> time of their choosing. When we're satisfied that it's stable enough we can
> flip the default (note: IMHO this would have to happen before kilo-3 in
> order to make it for the Kilo release).
>
> Based on this plan, I had a go at breaking the work down into discrete
> tasks, and because it turned out to be really long I put it in an etherpad
> rather than include it here:
>
> https://etherpad.openstack.org/p/heat-convergence-tasks
>
> If anyone has additions/changes then I suggest adding them to that
> etherpad and replying to this message to flag your changes.
>

I do not want to be assertive and greedy, so I toke several task, which IMO
are not required a lot of time for implementation and deep understanding
tricky things :) (Marked them on etherpad)
Also I don't want to steal work from guys who designed whole staff with
you. I think, that we could take more tasks later, when other volunteers
will be satisfied. I believe, that work will be enough for everyone. :)



>
> To be clear, it's unlikely I will have time to do the implementation work
> on any of these tasks myself (although I will be trying to review as many
> of them as possible). So the goal here is to get as many contributors
> involved in doing stuff in parallel as we can.
>
> There are obviously dependencies between many of these tasks, so my plan
> is to raise each one as a blueprint so we can see the magic picture that
> Launchpad shows. I want to get feedback first though, because there are 18
> of them so far, and rejigging everything in response to feedback would be a
> bit of a pain.
>
> I'm also prepared to propose specs for all of these _if_ people think that
> would be helpful. I see three options here:
>  - Propose 18 fairly minimal specs (maybe in a single review?)
>  - Propose 1 large spec (essentially the contents of that etherpad)
>  - Just discuss in the etherpad rather than Gerrit
>
>
I tend to choose etherpad, because it makes review and discussion faster.
(i.e. all in one place is easier for reading and referencing).


> Obviously that's in decreasing order of the amount of work required, but
> I'll do whatever folks think best for discussion.
>
> cheers,
> Zane.
>
> __
> 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
>




Regards,
Sergey.
__
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] [Fuel] Getting rid of kickstart/preseed for all NEW releases

My suggestion is to make IBP the only option available for all upcoming
OpenStack releases which are defined in openstack.yaml. It is to be
possible to install OS using kickstart for all currently available
OpenStack releases.

Vladimir Kozhukalov

On Mon, Jan 26, 2015 at 6:22 PM, Igor Kalnitsky 
wrote:

> Just want to be sure I understand you correctly: do you propose to
> FORBID kickstart/preseed installation way in upcoming release at all?
>
> On Mon, Jan 26, 2015 at 3:59 PM, Vladimir Kozhukalov
>  wrote:
> > Subject is changed.
> >
> > Vladimir Kozhukalov
> >
> > On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukalov
> >  wrote:
> >>
> >> Dear Fuelers,
> >>
> >> As you might know we need it to be possible to install several versions
> of
> >> a particular OS (Ubuntu and Centos) by 6.1  As far as having different
> OS
> >> versions also means having different sets of packages and some of  the
> >> packages are installed and configured during provisioning stage, we
> need to
> >> have a kind of kickstart/preseed version mechanism.
> >>
> >> Cobbler is exactly such a mechanism. It allows us to have several
> Distros
> >> (installer images) and profiles (kickstart/preseed files). But
> >> unfortunately, for some reasons we have not been using those Cobbler's
> >> capabilities since the beginning of Fuel and it doesn't seem to be
> easily
> >> introduced into Nailgun to deal with the whole Cobbler life cycle.
> >>
> >> Anyway, we are moving towards IBP (image based provisioning) and we
> >> already have different images connected to different OpenStack releases
> >> (openstack.yaml) and everything else which is necessary for initial node
> >> configuration is serialized inside provision data (including profile
> name
> >> like 'ubuntu_1204' or 'ubuntu_1404') and we are able to choose
> cloud-init
> >> template by this profile name.
> >>
> >> And taking into account what it is written above, the suggestion is to
> >> completely avoid using kickstart/preseed based way of OS provisioning
> by 6.1
> >> for all new releases allowing ONLY old ones to use this way.
> >>
> >> Any opinions about that stuff are welcome.
> >>
> >> Vladimir Kozhukalov
> >
> >
> >
> >
> __
> > 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
>
__
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] [tc] do we really need project tags in the governance repository?

As part of the Big Tent discussion, we have recently started working on a 
tagging system to allow projects to be described and discovered using data 
managed by the TC [1]. IIRC, the proposal to have tags came first from Jay’s 
blog [2], but has evolved as we’ve discussed it as a group, to include extra 
meta-data about when the tags went into effect or were revoked, and to discuss 
what sorts of tags are appropriate.

There have been two sorts of categories of tags proposed, objective tags like 
“included-in-install-guide” or “compute-base” and subjective tags like 
“production-ready” or “good-enough-for-cern”. As I’ve thought more about this 
over the last week, I’ve come to the conclusion that it’s not necessary for the 
TC to vote on the objective tags and that it’s not appropriate for us to vote 
on the subjective tags. That’s not to say the tags aren’t useful, just that I 
don’t think we want them in the governance repository.

All of the examples of objective tags we have discussed so far are really 
short-hand for information that should be discoverable by looking at project 
documentation. To find if something is documented in the installation guide, 
read the table of contents. To learn about the dependencies of a project, look 
at it’s installation instructions. To learn if a distribution includes the 
packages for a given project, look at the distribution's feature list. None of 
those things need to be voted on by the governance body.

The more subjective tags are meant to help deployers make decisions about when 
and how to use projects -- "Is project X 'good/stable/mature/scalable enough' 
for me to use?” We likely to get bogged down in describing what exactly we mean 
by these sorts of terms, as we try convert the subjective tag to objective 
criteria to use to apply the it. If we manage to come up with those objective 
criteria, we’re back to a point where anyone could just write the answer down 
in documentation without needing a vote. If we don’t come up with objective 
criteria, then we have the governing body making value judgements about what 
deployers *should* want rather than what they *do* want. We would be better off 
with deployers sharing information with each other by writing about their 
experiences online, via blogs or deployment guides or other outlets, than 
having the TC try to make those sorts of decisions for them.

So, my proposal is that we re-evaluate our decision to introduce a tagging 
system and complicated taxonomy to the *governance* repository, and think about 
whether the same information can either be found elsewhere already or *should 
live elsewhere* and needs to be developed there. We can keep the integrated 
release tag that we have in place now, but we should not adopt any other tags 
and we should phase out the tag system when we drop the integrated release tag.

Doug

[1] 
https://review.openstack.org/#/q/project:openstack/governance+branch:master+topic:tag-template,n,z
[2] http://www.joinfu.com/2014/09/so-what-is-the-core-of-openstack/
__
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] [heat][hot]

2015-01-26 Thread Dmitry

I'm using OS::Nova::Server, the versions is 2013-05-23

On Mon, Jan 26, 2015 at 5:10 PM, Qiming Teng 
wrote:

> On Sun, Jan 25, 2015 at 05:41:33PM +0200, Dmitry wrote:
> > Hello,
> > I need to receive instance id as part of the instance installation
> script.
> > Something like:
> > params:
> >   $current_id: {get_param: $this.id}
>
> Please be specific about the 'installation script', i.e. which resource
> type and which template version are you using?
>
> Regards,
>  Qiming
> >
> >
> > Is it possible?
> >
> > Thanks,
> > Dmitry
>
> >
> __
> > 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
>
__
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] [Fuel][client][IMPORTANT] Making Fuel Client a separate project

2015-01-26 Thread Roman Prykhodchenko

Hi guys,

status update incoming.

 - ISO build scripts have been switched to stackforge/python-fuelclient as the 
main source of Fuel Client [1] so please move all
   you’re patches that touch fuelclient [2] directory to the new Gerrit repo.
 - The patch that removes the fuelclient directory from fuel-web repo [3] has 
passed BVT and now is been on the final testing
   at the QA dept. As soon as QA guys post their confirmation that it works it 
will be landed.


References:

[1] https://review.openstack.org/#/c/149672/
[2] 
https://review.openstack.org/#/q/project:stackforge/fuel-web+status:open+file:%255Efuelclient/.*,n,z
[3] https://review.openstack.org/#/c/149797/


- romcheg

> 16 січ. 2015 о 17:13 Roman Prykhodchenko  написав(ла):
> 
> Hi Fuelers,
> 
> this is another status update.
> 
> - OpenStack-CI is now running pep8 checks [1] for patches to 
> python-fuelclient.
> - The script for running python tests in on review [2] and some guys are 
> requested to test it and give some feedback
> - Fuel CI is now allowed to vote on python-fuelclient [3] so the next stage 
> it to merge both run_test.sh [2] and Jenkins job to FuelCI [4]
> - It’s now planned to finish this migration on Tuesday next week, so it will 
> be possible to build ISO from python-fuelclient repo
> 
> Stay tuned.
> 
> 
> References:
> 
> 1. Run pep8 jobs for python-fuelclient https://review.openstack.org/#/c/147801
> 2. Run Python tests https://review.openstack.org/#/c/146950
> 3. Allow FuelCI voting on python-fuelclient 
> https://review.openstack.org/#/c/147429
> 4. Add verify-python-fuelclient https://review.fuel-infra.org/#/c/1989
> 
> 
> - romcheg
> 
>> 13 січ. 2015 о 15:58 Roman Prykhodchenko  написав(ла):
>> 
>> Folks,
>> 
>> this is another status update.
>> 
>>  • The patch for moving python-fuelclient to a separate project has been 
>> merged. At the moment Stackforge repository, a Gerrit project and all Gerrit 
>> groups have been created. There are two guys in the core group: I and Dmitri 
>> Pyzhov (dpyz...@mirantis.com). You can obtain the sources from 
>> https://github.com/stackforge/python-fuelclient.
>>  • I kindly ask authors of all changes to Fuel Client to start moving 
>> them to the new project.
>>  • At the moment I’m working on enabling the same testing process in 
>> FuelCI, testing in OpenStack CI will be enabled later because that requires 
>> some refactoring of the existing tests in python-fuelclient.
>> 
>> Stay tuned.
>> 
>> 
>> - romcheg
>> 
>>> 12 січ. 2015 о 12:44 Roman Prykhodchenko  написав(ла):
>>> 
>>> Hi folks!
>>> 
>>> This is a status update.
>>> • Right now the patch for creating a new project on Stackforge is 
>>> blocked by a bug in Zuul [1] which is actually a bug in python-daemon, the 
>>> patch for this is already published [2] and waiting for being approved.
>>> • After the patch is merged and all projects and groups are created I 
>>> will file a request to perform initial setup of core groups. Once they are 
>>> created it will be possible to land new patches.
>>> • Meanwhile OSCI team is working [3] on adjusting build system to use 
>>> python-fuelclient from PyPi [4].
>>> Stay tuned for further updates.
>>> 
>>> References:
>>> • Zuul’s tests fail with dependencies error 
>>> https://storyboard.openstack.org/#!/story/2000107
>>> • Pin python-daemon<2.0 https://review.openstack.org/#/c/146350/
>>> • Create repositories for python-fuelclient package 
>>> https://bugs.launchpad.net/fuel/+bug/1409673
>>> • python-fuelclient on PyPi 
>>> https://pypi.python.org/pypi/python-fuelclient
>>> 
>>> 
 9 січ. 2015 о 15:14 Roman Prykhodchenko  написав(ла):
 
 Hi folks,
 
 according to the Fuel client refactoring plan [1] it’s necessary to move 
 it out to a separate repository on Stackforge.
 
 The process of doing that consists of two major steps:
 - Landing a patch [2] to project-config for creating a new Stackforge 
 project
 - Creating an initial core group for python-fuelclient
 - Moving all un-merged patches from fuel-web to python-fuelclient gerrit 
 repo
 
 The first step of this process has already been started so I kindly ask 
 all fuelers to DO NOT MERGE any new patches to fuel-web IF THEY DO touch 
 fuelclient folder.
 After the project is set up I will let everyone know about that and will 
 tell what to do after that so I encourage all interested people to check 
 this thread once in a while.
 
 
 # References:
 
 1. Re-thinking Fuel Client https://review.openstack.org/#/c/145843
 2. Add python-fuelclient to Stackforge 
 https://review.openstack.org/#/c/145843
 
 
 - romcheg
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-26 Thread Ruslan Kamaldinov

On Mon, Jan 26, 2015 at 6:12 PM, Andrew Pashkin  wrote:
> On 26.01.2015 18:05, Ruslan Kamaldinov wrote:
>
> I think it's still important to perform migration specific checks. We want
> to make sure that DB is in expected state after each specific migration.
>
> Why?

1. It's not just the schema we care about. It's the effect of
particular DB migration script on data stored in DB. We need to make
sure that data is not corrupted or lost in any way
2. Some migrations add or remove indexes and constraints, we might
want to test that

Thanks,
Ruslan

__
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] required libvirtd/qemu versions for numa support?

2015-01-26 Thread Chris Friesen


Hi,

I'm interested in the recent work around NUMA support for guest instances 
(https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement), but 
I'm having some difficulty figuring out what versions of libvirt and qemu are 
required.


From the research that I've done it seems like qemu 2.1 might be required, but 
I've been unable to find a specific version listed in the nova requirements or 
in the openstack global requirements.  Is it there and I just can't find it?


If it's not specified, and yet openstack relies on it, perhaps it should be 
added.  (Or at least documented somewhere.)


Thanks,
Chris

__
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] [neutron] lbaas driver implementation question

2015-01-26 Thread Shane McGough

Hi all,

Implementing a driver for lbaas and am running into some trouble.

The load balancer is a VM hosted on the compute node within devstack and the 
driver can create vips, pools and members no problem.

The problem lies when trying to access the service hosted by the VIP.

>From TCP dumps on the load balancer instance we can see that the traffic hits 
>the load balancer and the load balancer replies but the reply does not reach 
>the client.

Is there an implementation reason why this might occur (i.e. not creating a 
port or doing some neutron configuration within the driver) or could there be 
another issue at play here.

We are using stable/juno devstack for test purposes. We can access the load 
balancer GUI no problem via the browser its just anything hosted by the LB 
services is inaccessible.

Any help would be appreciated

Thanks,
Shane.
__
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] [cinder] Request for clarification regarding deadline for new drivers in Kilo

2015-01-26 Thread Mike Perez

On 16:55 Mon 26 Jan , Eduard Matei wrote:
> Hi,
> 
> Any update on this?

No. Updates will be in your review, not this list.

-- 
Mike Perez

__
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] [Fuel] Getting rid of kickstart/preseed for all NEW releases

2015-01-26 Thread Igor Kalnitsky

Just want to be sure I understand you correctly: do you propose to
FORBID kickstart/preseed installation way in upcoming release at all?

On Mon, Jan 26, 2015 at 3:59 PM, Vladimir Kozhukalov
 wrote:
> Subject is changed.
>
> Vladimir Kozhukalov
>
> On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukalov
>  wrote:
>>
>> Dear Fuelers,
>>
>> As you might know we need it to be possible to install several versions of
>> a particular OS (Ubuntu and Centos) by 6.1  As far as having different OS
>> versions also means having different sets of packages and some of  the
>> packages are installed and configured during provisioning stage, we need to
>> have a kind of kickstart/preseed version mechanism.
>>
>> Cobbler is exactly such a mechanism. It allows us to have several Distros
>> (installer images) and profiles (kickstart/preseed files). But
>> unfortunately, for some reasons we have not been using those Cobbler's
>> capabilities since the beginning of Fuel and it doesn't seem to be easily
>> introduced into Nailgun to deal with the whole Cobbler life cycle.
>>
>> Anyway, we are moving towards IBP (image based provisioning) and we
>> already have different images connected to different OpenStack releases
>> (openstack.yaml) and everything else which is necessary for initial node
>> configuration is serialized inside provision data (including profile name
>> like 'ubuntu_1204' or 'ubuntu_1404') and we are able to choose cloud-init
>> template by this profile name.
>>
>> And taking into account what it is written above, the suggestion is to
>> completely avoid using kickstart/preseed based way of OS provisioning by 6.1
>> for all new releases allowing ONLY old ones to use this way.
>>
>> Any opinions about that stuff are welcome.
>>
>> Vladimir Kozhukalov
>
>
>
> __
> 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

Re: [openstack-dev] Changes to Cinder Core

2015-01-26 Thread Ivan Kolodyazhny

Mike,
Thank you for nominating me.

Cores, thanks for voting! It's a big honor for me to be a part of this
great Team! I'll do my best to make Cinder and OpenStack better.

Regards,
Ivan Kolodyazhny

On Mon, Jan 26, 2015 at 4:57 PM, Mike Perez  wrote:

> On 10:14 Wed 21 Jan , Mike Perez wrote:
> > It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for
> > Cinder core. Ivan's reviews have been valuable in decisions, and his
> > contributions to Cinder core code have been greatly appreciated.
> 
> > Cinder core, please reply with a +1 for approval. This will be left
> > open until Jan 26th. Assuming there are no objections, this will go
> > forward after voting is closed.
>
> Ivan Kolodyazhny is now part of Cinder core. Welcome to the team!
>
> --
> Mike Perez
>
> __
> 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

[openstack-dev] [neutron] FYI: Just abandoned old reviews

2015-01-26 Thread Kyle Mestery

I just ran the Nova abandon script [1] against the neutron repositories, so
a lot of old reviews were cleaned out of the system this morning. If your
review needs to be re-instated, you can do this manually as the message
should indicate.

I've also proposed the abandon script into the neutron repository as well
for future use [2]. Thanks to Sean for pointing me at the script last week!

Thanks,
Kyle

[1]
https://github.com/openstack/nova/blob/master/tools/abandon_old_reviews.sh
[2] https://review.openstack.org/150055
__
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] [Murano] SQLite support - drop or not?

2015-01-26 Thread Andrew Pashkin

/On 26.01.2015 18:05, Ruslan Kamaldinov wrote:/
/I think it's still important to perform migration specific checks. We
want to make sure that DB is in expected state after each specific
migration./

Why?

On 26.01.2015 18:05, Ruslan Kamaldinov wrote:

On Mon, Jan 26, 2015 at 3:03 PM, Andrew Pashkin wrote:

On 23.01.2015 23:39, Ruslan Kamaldinov wrote:

1. Use ModelsMigrationsSync from [2] in tests to make sure that SQLAlchemy
models are in sync with migrations. Usage example can be found at [3]

Seems like it is a great helper, as I understand it runs all migrations and
then compares DB state with models state and throws an error if they are out
of sync.
What I don't understand - why they still manually write checks for every
migration [1]? This is redundant, because ModelsMigrationsSync already does
the job testing that DB is in sync with models.

By the way in Heat project they do the same thing [2]. What am I missing?

I think it's still important to perform migration specific checks. We
want to make sure that DB is in expected state after each specific
migration.

[1]
http://git.openstack.org/cgit/openstack/sahara/tree/sahara/tests/unit/db/migration/test_migrations.py#n402
[2]
https://github.com/openstack/heat/blob/7d4c4030c591ef5994db4327d66d353ad83c6ea8/heat/tests/db/test_migrations.py#L288
2. Populate DB schema from SQLAlchemy models in unit-tests which require
access to DB

You mean - using these tools [3]?

[3]
http://docs.sqlalchemy.org/en/rel_0_9/core/metadata.html#creating-and-dropping-database-tables

Yes, this one. We still have this code in source tree:
http://git.openstack.org/cgit/stackforge/murano/tree/murano/db/models.py#n289

In what conditions 5) will fail? I see only these cases:
- If data migrations would be introduced and Murano would require some data
in DB to work correctly.

Actually, we already do that. We populate initial set of categories:
http://git.openstack.org/cgit/stackforge/murano/tree/murano/db/migration/alembic_migrations/versions/001_inital_version.py#n40

Would it affect anyone? I don't think so. You always can populate
these categories manually.

- If Murano would use some database-specific features (stored procedures
etc).

That should never happen :)

There are good chances that these cases will never happen in reality, as I
understand, so I tend to agree.

Agree

--
Ruslan

--
With kind regards, Andrew Pashkin.
cell phone - +7 (985) 898 57 59
Skype - waves_in_fluids
e-mail - apash...@mirantis.com

Re: [openstack-dev] [heat][hot]

On Sun, Jan 25, 2015 at 05:41:33PM +0200, Dmitry wrote:
> Hello,
> I need to receive instance id as part of the instance installation script.
> Something like:
> params:
>   $current_id: {get_param: $this.id}

Please be specific about the 'installation script', i.e. which resource
type and which template version are you using?

Regards,
 Qiming
> 
> 
> Is it possible?
> 
> Thanks,
> Dmitry

> __
> 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

Re: [openstack-dev] [oslo] [nova] [all] potential enginefacade adjustment - can everyone live with this?



On Mon, Jan 26, 2015, at 08:55 AM, Matthew Booth wrote:
> On 23/01/15 19:47, Mike Bayer wrote:
> > 
> > 
> > Doug Hellmann  wrote:
> > 
> >>
> >>
> >> On Fri, Jan 23, 2015, at 12:49 PM, Mike Bayer wrote:
> >>> Mike Bayer  wrote:
> >>>
>  Ihar Hrachyshka  wrote:
> 
> > On 01/23/2015 05:38 PM, Mike Bayer wrote:
> >> Doug Hellmann  wrote:
> >>
> >>> We put the new base class for RequestContext in its own library 
> >>> because
> >>> both the logging and messaging code wanted to influence it's API. 
> >>> Would
> >>> it make sense to do this database setup there, too?
> >> whoa, where’s that? is this an oslo-wide RequestContext class ? that 
> >> would
> >> solve everything b.c. right now every project seems to implement
> >> RequestContext themselves.
> >>>
> >>>
> >>> so Doug -
> >>>
> >>> How does this “influence of API” occur, would oslo.db import
> >>> oslo_context.context and patch onto RequestContext at that point? Or the
> >>> other way around? Or… ?
> >>
> >> No, it's a social thing. I didn't want dependencies between
> >> oslo.messaging and oslo.log, but the API of the context needs to support
> >> use cases in both places.
> >>
> >> Your case might be different, in that we might need to actually have
> >> oslo.context depend on oslo.db in order to call some setup code. We'll
> >> have to think about whether that makes sense and what other dependencies
> >> it might introduce between the existing users of oslo.context.
> > 
> > hey Doug -
> > 
> > for the moment, I have oslo_db.sqlalchemy.enginefacade applying its 
> > descriptors at import time onto oslo_context:

OK. I'll have to think about that. We've been trying to move away from
import-time side-effects elsewhere (especially with configuration
options) so we may want to think about doing the decoration at runtime,
either through a hook discovered by oslo.context or by placing the call
right in oslo.context. Let's talk about options this week.

> > 
> > https://review.openstack.org/#/c/138215/30/oslo_db/sqlalchemy/enginefacade.py
> > 
> > https://review.openstack.org/gitweb?p=openstack/oslo.db.git;a=blob;f=oslo_db/sqlalchemy/enginefacade.py;h=3f76678a6c9788f62288c8fa5ef520db8dff2c0a;hb=bc33d20dc6db2f8e5f8cb02b4eb5f97d24dafb7a#l692
> > 
> > https://review.openstack.org/gitweb?p=openstack/oslo.db.git;a=blob;f=oslo_db/sqlalchemy/enginefacade.py;h=3f76678a6c9788f62288c8fa5ef520db8dff2c0a;hb=bc33d20dc6db2f8e5f8cb02b4eb5f97d24dafb7a#l498
> 
> May I suggest that we decouple these changes by doing both? Oslo's
> RequestContext object can have the enginefacade decorator applied to it,
> so any project which uses it doesn't have to apply it themselves.
> Meanwhile, the decorator remains part of the public api for projects not
> using the oslo RequestContext.

We can leave the function in the public API, but oslo.log assumes the
application is using a context class subclassed from the base class
provided in oslo.context. As we evolve that integration, we'll make
appropriate changes to the base class so they will usually be
transparent to the application code, so it's going to be safer to just
use the base class we provide.

Doug

> 
> I suggest that we'll probably stay with a decorator within oslo, anyway.
> It doesn't lend itself well to a Mixin, as we need a reference to a
> specific _TransactionContextManager, and moving code directly into
> RequestContext would be a very invasive coupling.
> 
> Matt
> -- 
> Matthew Booth
> Red Hat Engineering, Virtualisation Team
> 
> Phone: +442070094448 (UK)
> GPG ID:  D33C3490
> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
> 
> __
> 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

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-26 Thread Ruslan Kamaldinov

On Mon, Jan 26, 2015 at 3:03 PM, Andrew Pashkin  wrote:
> On 23.01.2015 23:39, Ruslan Kamaldinov wrote:
>
> 1. Use ModelsMigrationsSync from [2] in tests to make sure that SQLAlchemy
> models are in sync with migrations. Usage example can be found at [3]
>
> Seems like it is a great helper, as I understand it runs all migrations and
> then compares DB state with models state and throws an error if they are out
> of sync.
> What I don't understand - why they still manually write checks for every
> migration [1]? This is redundant, because ModelsMigrationsSync already does
> the job testing that DB is in sync with models.
>
> By the way in Heat project they do the same thing [2]. What am I missing?

I think it's still important to perform migration specific checks. We
want to make sure that DB is in expected state after each specific
migration.

> [1]
> http://git.openstack.org/cgit/openstack/sahara/tree/sahara/tests/unit/db/migration/test_migrations.py#n402
> [2]
> https://github.com/openstack/heat/blob/7d4c4030c591ef5994db4327d66d353ad83c6ea8/heat/tests/db/test_migrations.py#L288

> 2. Populate DB schema from SQLAlchemy models in unit-tests which require
> access to DB
>
> You mean - using these tools [3]?
>
> [3]
> http://docs.sqlalchemy.org/en/rel_0_9/core/metadata.html#creating-and-dropping-database-tables

Yes, this one. We still have this code in source tree:
http://git.openstack.org/cgit/stackforge/murano/tree/murano/db/models.py#n289

> In what conditions 5) will fail? I see only these cases:
> - If data migrations would be introduced and Murano would require some data
> in DB to work correctly.

Actually, we already do that. We populate initial set of categories:
http://git.openstack.org/cgit/stackforge/murano/tree/murano/db/migration/alembic_migrations/versions/001_inital_version.py#n40

Would it affect anyone? I don't think so. You always can populate
these categories manually.

> - If Murano would use some database-specific features (stored procedures
> etc).

That should never happen :)

> There are good chances that these cases will never happen in reality, as I
> understand, so I tend to agree.

Agree

--
Ruslan

__
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] Changes to Cinder Core

2015-01-26 Thread Mike Perez

On 10:14 Wed 21 Jan , Mike Perez wrote:
> It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for
> Cinder core. Ivan's reviews have been valuable in decisions, and his
> contributions to Cinder core code have been greatly appreciated.

> Cinder core, please reply with a +1 for approval. This will be left
> open until Jan 26th. Assuming there are no objections, this will go
> forward after voting is closed.

Ivan Kolodyazhny is now part of Cinder core. Welcome to the team!

-- 
Mike Perez

__
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] [cinder] Request for clarification regarding deadline for new drivers in Kilo

2015-01-26 Thread Eduard Matei

Hi,

Any update on this?
I added comments to the review.
Meanwhile the nova review got abandoned, but i'll resubmit that once this
is approved.

Thanks,
Eduard

On Wed, Jan 21, 2015 at 7:31 PM, Mike Perez  wrote:

> On 11:24 Wed 21 Jan , Eduard Matei wrote:
> > Hi,
> >
> > This weekend our driver [https://review.openstack.org/#/c/130733/] got
> a -2
> > stating that "This is past the deadline for release of new drivers in
> > Kilo." and "the deadline for new drivers passed at the end of Kilo-1.
> This
> > needs to wait for the L release."
> >
> > But, in another mail on the mailing list we were informed:
> > "
> > If your driver is submitted *LATE* in k-1, and meets *all* the items
> above,
> > but isn't merged, it will be still be considered for merge in k-2 or k-3.
> > "
> > The items above being that the blueprint is submitted, together with cert
> > tests and the code is submitted to gerrit and that a CI is working.
> >
> > We had the blueprint, cert tests and code on gerrit *EARLY* in k-1 (first
> > patchset was on Oct 24), blueprint was approved for k-1 and cert tests
> were
> > posted.
> > CI is under construction, and will be ready by March deadline.
> >
> >
> > So, can someone from cinder core clarify why the driver is delayed to L
> > when all items are met?
>
> Would like to take this off the list. I replied to your review.
>
> --
> Mike Perez
>
> __
> 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
>

-- 

*Eduard Biceri Matei, Senior Software Developer*
www.cloudfounders.com
 | eduard.ma...@cloudfounders.com

*CloudFounders, The Private Cloud Software Company*

Disclaimer:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed.
If you are not the named addressee or an employee or agent responsible
for delivering this message to the named addressee, you are hereby
notified that you are not authorized to read, print, retain, copy or
disseminate this message or any part of it. If you have received this
email in error we request you to notify us by reply e-mail and to
delete all electronic files of the message. If you are not the
intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the content of this
message, and shall have no liability for any loss or damage suffered
by the user, which arise as a result of e-mail transmission.
__
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] [neutron] [rhel7] minimal dnsmasq version

2015-01-26 Thread Andreas Scheuring

Thanks Ihar for sharing your thoughts!


-- 
Andreas 
(irc: scheuran)


On Mon, 2015-01-26 at 11:30 +0100, Ihar Hrachyshka wrote:
> Hi Andreas,
> 
> On 01/26/2015 10:58 AM, Andreas Scheuring wrote:
> > Hi Ihar,
> > we're currently running stable/juno devstack on rhel7 base. But I see
> > troubles to get it running on the master branch due to bug  1408297.
> >
> > The fix for this bug increases the minimal dnsmasq version for master
> > branch up to 2.67. I also recognized the stable/juno item that leaves a
> > warning if this version level is not reached - that's why it is working
> > fine for us so far.
> >
> > You mentioned in the following thread
> >
> > http://lists.openstack.org/pipermail/openstack-dev/2015-January/053980.html
> >
> > , that redhat plans to backport the mac-ip matching feature to version
> > 2.66.
> 
> Not exactly. I only said that for some conservative distributions that 
> strictly control any version bumps, simple bump of dnsmasq to 2.67 may 
> be not an option, and hence they may consider backporting the feature 
> they miss as an alternative. I haven't mentioned which route Red Hat 
> will go though.
> 
> You may be interested in tracking the following Red Hat bug to see how 
> it goes:
> https://bugzilla.redhat.com/show_bug.cgi?id=1179756
> 
> >
> > Are you planning any additional Neutron code changes to also allow the
> > version 2.66 or an older one of dnsmasq or may this new version for rhel
> > come with the kilo rdo release? At least for IPv4 Use cases the 2.67
> > version is not required
> 
> Yes, I have a patch in review to move the version check from DHCP agent 
> to sanity_check tool [1]. I will update it today since it seems the 
> issue gets a lot of traction and attention recently (f.e. see [2]).
> 
> Note that at the moment, there is no RDO Kilo release yet. Though you 
> may find some packages for Kilo in Delorean (RDO based on master) [3].
> 
> We hope that EL7 will receive an update for dnsmasq to allow it to serve 
> IPv6 stateful subnets in the near future, as far as I know teams are 
> actively working on delivering it. Once we get the update, we'll be ok 
> to disable the warning in Juno [4] (in Red Hat repos, not upstream).
> 
> [1]: https://review.openstack.org/148577
> [2]: https://bugs.launchpad.net/bugs/1413042
> [3]: http://209.132.178.33/repos/report.html
> [4]: 
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/linux/dhcp.py?h=stable/juno#n334
> 
> >
> > The only workaround I could imagine so far is to install a fedora
> > package.
> 
> Yes, that's a way to go for now. Sorry for any inconvenience due to that.
> 
> >
> > Thanks!
> >
> >
> 


__
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] [QA] Prototype of the script for Tempest auto-configuration

2015-01-26 Thread Timur Nurlygayanov

Hi,

*Yaroslav*, thank you for raising the question, I realy like this feature,
I discussed this script with several people during the OpenStack summit in
Paris and heard many the same things - we need to have something like this
to execute tempest tests automatically for validation of different
production and test OpenStack clouds - it is real pain to create our own
separate scripts for each project / team which will configure Tempest for
some specific configurations / installations, because tempest configuration
file can be changed and we will need to update our scripts.

We need to discuss, first of all, what we need to change in this script
before this script will be merged.
As I can see, the spec description [1] not fully meet the current
implementation [2] and the spec looks really general - probably we can
describe separate 'simple' spec for this script and just abandon the
current spec or update the spec to sync spec and this script?

*David*, we found many issues with the current version of script, many
tempest tests failed for our custom OpenStack configurations (for example,
with and without Swift or Ceph) and we have our own scripts which already
can solve the problem. Can we join you and edit the patch together? (or we
can describe our ideas in the comments for the patch).

Also, looks like we need review from Tempest core team - they can write
more valuable comments and suggest some cool ideas for the implementation.

[1] https://review.openstack.org/#/c/94473
[2] https://review.openstack.org/#/c/133245

On Fri, Jan 23, 2015 at 7:12 PM, Yaroslav Lobankov 
wrote:

> Hello everyone,
>
> I would like to discuss the following patch [1] for Tempest. I think that
> such feature
> as auto-configuration of Tempest would be very useful for many engineers
> and users.
> I have recently tried to use the script from [1]. I rebased the patch on
> master and ran the script.
> The script was finished without any errors and the tempest.conf was
> generated! Of course,
> this patch needs a lot of work, but the idea looks very cool!
>
> Also I would like to thank David Kranz for his working on initial version
> of the script.
>
> Any thoughts?
>
> [1] https://review.openstack.org/#/c/133245
>
> Regards,
> Yaroslav Lobankov.
>
> __
> 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
>
>

-- 

Timur,
Senior QA Engineer
OpenStack Projects
Mirantis Inc
__
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] Installation problem

2015-01-26 Thread Rajdeep Dua

Tried updating an existing installation..
Did a clean.sh and tried again with stack.sh
Now getting the following error..

ImportError: Could not import settings 'openstack_dashboard.settings' (Is
it on sys.path? Is there an import error in the settings file?): cannot
import name types


On Mon, Jan 26, 2015 at 7:33 PM, Abhishek Shrivastava <
abhis...@cloudbyte.com> wrote:

> Hi Rajdeep,
>
> Can you please send the details of how are you trying to install the
> latest devstack and complete log so that it will be easy to now where are
> you failing.
>
> On Mon, Jan 26, 2015 at 4:56 PM, Rajdeep Dua 
> wrote:
>
>> Getting following exception on latest devstack installation.
>> Please let me know how to resolve this.
>>
>> Thanks
>> Rajdeep
>>
>> + /usr/local/bin/glance-manage db_sync
>> Traceback (most recent call last):
>>   File "/usr/local/bin/glance-manage", line 9, in 
>> load_entry_point('glance==2015.1.dev24', 'console_scripts',
>> 'glance-manage')()
>>   File
>> "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
>> 519, in load_entry_point
>> return get_distribution(dist).load_entry_point(group, name)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
>> 2630, in load_entry_point
>> return ep.load()
>>   File
>> "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
>> 2310, in load
>> return self.resolve()
>>   File
>> "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
>> 2316, in resolve
>> module = __import__(self.module_name, fromlist=['__name__'], level=0)
>>   File "/opt/stack/glance/glance/cmd/manage.py", line 45, in 
>> from glance.common import config
>>   File "/opt/stack/glance/glance/common/config.py", line 29, in 
>> from oslo_concurrency import lockutils
>>   File
>> "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py",
>> line 30, in 
>> from oslo.config import cfgfilter
>> ImportError: cannot import name cfgfilter
>>
>>
>> __
>> 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
>>
>>
>
>
> --
>
>
> *Thanks & Regards,*
> *Abhishek*
> *Cloudbyte Inc. *
>
> __
> 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

Re: [openstack-dev] [devstack] Installation problem

2015-01-26 Thread Abhishek Shrivastava

Hi Rajdeep,

Can you please send the details of how are you trying to install the latest
devstack and complete log so that it will be easy to now where are you
failing.

On Mon, Jan 26, 2015 at 4:56 PM, Rajdeep Dua  wrote:

> Getting following exception on latest devstack installation.
> Please let me know how to resolve this.
>
> Thanks
> Rajdeep
>
> + /usr/local/bin/glance-manage db_sync
> Traceback (most recent call last):
>   File "/usr/local/bin/glance-manage", line 9, in 
> load_entry_point('glance==2015.1.dev24', 'console_scripts',
> 'glance-manage')()
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 519, in load_entry_point
> return get_distribution(dist).load_entry_point(group, name)
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 2630, in load_entry_point
> return ep.load()
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 2310, in load
> return self.resolve()
>   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 2316, in resolve
> module = __import__(self.module_name, fromlist=['__name__'], level=0)
>   File "/opt/stack/glance/glance/cmd/manage.py", line 45, in 
> from glance.common import config
>   File "/opt/stack/glance/glance/common/config.py", line 29, in 
> from oslo_concurrency import lockutils
>   File
> "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py",
> line 30, in 
> from oslo.config import cfgfilter
> ImportError: cannot import name cfgfilter
>
>
> __
> 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
>
>


-- 


*Thanks & Regards,*
*Abhishek*
*Cloudbyte Inc. *
__
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] [Fuel] Getting rid of kickstart/preseed for all NEW releases

Subject is changed.

Vladimir Kozhukalov

On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear Fuelers,
>
> As you might know we need it to be possible to install several versions of
> a particular OS (Ubuntu and Centos) by 6.1  As far as having different OS
> versions also means having different sets of packages and some of  the
> packages are installed and configured during provisioning stage, we need to
> have a kind of kickstart/preseed version mechanism.
>
> Cobbler is exactly such a mechanism. It allows us to have several Distros
> (installer images) and profiles (kickstart/preseed files). But
> unfortunately, for some reasons we have not been using those Cobbler's
> capabilities since the beginning of Fuel and it doesn't seem to be easily
> introduced into Nailgun to deal with the whole Cobbler life cycle.
>
> Anyway, we are moving towards IBP (image based provisioning) and we
> already have different images connected to different OpenStack releases
> (openstack.yaml) and everything else which is necessary for initial node
> configuration is serialized inside provision data (including profile name
> like 'ubuntu_1204' or 'ubuntu_1404') and we are able to choose cloud-init
> template by this profile name.
>
> And taking into account what it is written above, the suggestion is to
> completely avoid using kickstart/preseed based way of OS provisioning by
> 6.1 for all new releases allowing ONLY old ones to use this way.
>
> Any opinions about that stuff are welcome.
>
> Vladimir Kozhukalov
>
__
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] [Fuel]