date:20150521




On 5/14/15 11:40 AM, Mike Bayer wrote:
The online schema changes patch has been abandoned.I regret that 
I was not able to review the full nature of this spec in time to note 
some concerns I have, namely that Alembic does not plan on ever 
acheiving 100% automation of migration generation; such a thing is 
not possible and would require a vast amount of development resources 
in any case to constantly keep up with the ever changing features and 
behaviors of all target databases. The online migration spec, AFAICT, 
does not offer any place for manual migrations to be added, and I 
think this will be a major problem. The decisions made by 
autogenerate I have always stated should always be manually reviewed 
and corrected, so I'd be very nervous about a system that uses 
autogenerate on the fly and sends those changes directly to a 
production database without any review.


So it looks like Nova has decided at the summit to forge ahead with 
online schema migrations.Travel issues prevented me from being 
present at the summit and therefore the session where this was being 
discussed.   But had I been there, a short 40 minute session wouldn't 
have been a venue in which I could have organized my thoughts enough to 
be any more effective in discussing this feature, so it's probably 
better that I wasn't there.   As I've mentioned before, the timing of 
the blueprint on this feature was just not well synchronized for me, it 
being proposed the first month I was working for Red Hat and Openstack 
and hardly knew what things were, and as you can see by my comments at 
https://review.openstack.org/#/c/102545/9, I was primarily alarmed at 
the notion that this system was going to be built entirely on 
SQLAlchemy-Migrate internals, a project which one of my primary tasks at 
my new job was to get replaced with Alembic.   I hardly understood what 
the actual proposal was as I was still learning how to install Openstack 
at that point, so I really missed being able to dig deeply into it.  The 
spec went quiet after a few weeks and I mostly forgot about it, until in 
November when it suddenly awoke, burned ahead through Christmas and was 
approved on Jan 6.  Again, terrible timing for me, as my wife gave birth 
to our son in late October, and I was pretty much 24/7 dealing with a 
newborn, not to mention getting through the holidays.  So I missed the 
boat on the blueprint entirely.


For now, I have to assume that Nova will go ahead with this.  But let me 
at least take some effort to explain more fully what I think the problem 
with this approach is.  I don't think this problem will necessarily be 
that big a deal for Nova, at least most of the time; but when it is a 
problem, it might be pretty bad.   My concern is that the system has no 
way at all to provide for manual migration steps, or any control at all 
as to how schema migrations proceed; and critically, that it makes no 
provisions for the very common case of schema migrations that also need 
data to be moved and manipulated as well.   The blueprint has no mention 
whatsoever regarding how the migrations of data will be handled; not 
even within sections such as Developer impact or Testing.   Right 
now, data migrations are just part of the sqlalchemy-migrate scripts or 
Alembic scripts.  But with the change that we no longer write such 
scripts, nor do we even have a place to put them if we wanted, data 
migrations are no longer integrated within this system and have to be 
dealt with externally.


It may be the case that Nova has a schema that is no longer in need of 
major changes, and we are only talking about adding new columns, new 
tables to support new features, and removing some old cruft; but moving 
data around is just not going to be needed.But once you build a 
system that makes data migrations second class or even non-citizens, you 
close the doors on how much you can do with your schema.   Big changes 
down the road are basically no longer possible without the ability to 
also migrate data as the DDL is emitted.


So OK, of course we can still do data migrations.  The spec doesn't need 
to say anything, it should be obvious that they need to be performed 
during the migrate phase, in between expand and contract when you 
have both the new tables/columns available as a destination for data and 
the old tables/columns still present as the source.   As far as what 
form they take, we no longer have migration scripts or versions within a 
major release, so we have to assume it will be just a big series of 
scripts somewhere, tagged towards the major release like Kilo or 
Liberty, and it's just a bunch of database code that runs at the same 
time we're in migrate.


I have no doubt that's what Nova will do, and usually it will be fine.   
But to illustrate, here's the kind of place that goes wrong in such a 
way that is at best pretty annoying and at worst a serious and 
error-prone development and testing headache.Let's

Re: [openstack-dev] [Nova][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Xav Paice

On 21/05/15 21:23, Daniel P. Berrange wrote:
 On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote:
 I note that we use instance.name to lookup the libvirt domain a bunch
 in the driver. I'm wondering why we don't just use instance.uuid all
 the time -- the code for that already exists. Is there a good reason
 to not move to always using the uuid?

 I ask because instance.name is not guaranteed to be unique depending
 on how weird the nova deployment is.
 Agreed, there's no benefit to using name - internally libvirt will always
 prefer to use the UUID itself too.

 These days though, there is only a single place in nova libvirt driver
 that needs updating - the nova.virt.libvirt.host.Host class get_domain()
 method just needs to be switched to use uuid.

 Regards,
 Daniel

Just a comment from an ops point of view - it would be miles easier when
trying to troubleshoot, if the instance name was the uuid anyway.  I
totally agree on using instance.uuid, just to comment that I find it a
little painful sometimes that instance names don't match the uuid of the
instance, but the directory structure does.  Just a bit of confusion to
avoid at 2am when something isn't working.

__
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] [pbr] 1.0.1 released

2015-05-21 Thread YAMAMOTO Takashi

hi,

can you explain why you want to use pbr 1.0.1 in the first place?
what's wrong with requiring pbr1.0 ?

YAMAMOTO Takashi

 Hi openstack-dev team,
 
 Can you also release latest oslo.config to allow pbr 1.0.1?
 In my convenience I want to use it.
 
 
 Thanks,
 kakuma
 
 On Wed, 20 May 2015 11:07:36 +1200
 Robert Collins robe...@robertcollins.net wrote:
 
 We are super psyched to announce the release of:
 
 pbr 1.0.1: Python Build Reasonableness
 
 With source available at:
 
 http://git.openstack.org/cgit/openstack-dev/pbr
 
 For more details, please see the git log history below and:
 
 http://launchpad.net/pbr/+milestone/1.0.1
 
 Please report issues through launchpad:
 
 http://bugs.launchpad.net/pbr
 
 Changes in pbr 1.0.0..1.0.1
 ---
 
 b72e446 Remove self.pre_run calls in packaging.py
 8e87679 Update hacking to 0.10.x series
 
 Diffstat (except docs and test files)
 -
 
 pbr/packaging.py  | 2 --
 test-requirements.txt | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)
 
 
 Requirements updates
 
 
 diff --git a/test-requirements.txt b/test-requirements.txt
 index 2b33504..6e4521c 100644
 --- a/test-requirements.txt
 +++ b/test-requirements.txt
 @@ -4 +4 @@ fixtures=0.3.14
 -hacking=0.9.2,0.10
 +hacking=0.10.0,0.11
 
 
 
 -- 
 Robert Collins rbtcoll...@hp.com
 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
 
 -- 
 fumihiko kakuma kak...@valinux.co.jp
 
 
 
 __
 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][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Daniel P. Berrange

On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote:
 I note that we use instance.name to lookup the libvirt domain a bunch
 in the driver. I'm wondering why we don't just use instance.uuid all
 the time -- the code for that already exists. Is there a good reason
 to not move to always using the uuid?
 
 I ask because instance.name is not guaranteed to be unique depending
 on how weird the nova deployment is.

Agreed, there's no benefit to using name - internally libvirt will always
prefer to use the UUID itself too.

These days though, there is only a single place in nova libvirt driver
that needs updating - the nova.virt.libvirt.host.Host class get_domain()
method just needs to be switched to use uuid.

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

__
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] [Cue] Design Session

2015-05-21 Thread Vipul Sabhaya

Hi!

Cue is holding a design session to talk about some of the priorities for
Liberty, Thursday from 3:20pm to 4:00pm at the couches outside of room 220.

https://etherpad.openstack.org/p/liberty-cue-design

Come and join us to learn more!
__
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][heat] sqlalchemy-migrate tool to alembic




On 5/21/15 12:28 PM, Jay Pipes wrote:

Hi Mike,

I had some initial concerns around the online db schema migration work 
as you do below. However, once I realized one big thing, those 
concerns were allayed.


Here's the big thing that you're missing: no data migrations are 
allowed any more in DB migration scripts.


Yes, that sounds exceedingly weird, I know, but hear me out in the 
comments inline... :) I've trimmed your original email for brevity.



And this is where you're missing the important piece :) While it *is* 
true that the expand phase would combine the *DDL* schema migrations 
into just a final table structure as shown above, it is actually *not* 
true that the knowledge is lost of how the model schemas changed.


The key to all of this is that each change to the DB schema would be 
in a patch that contained corresponding changes to the nova.objects.* 
classes that are used to represent the data. And it is *these* object 
classes that have object versioning and model changes tracked in them.


Ah.  OK, I didn't even have to read the rest of that to understand 
(well, at least to a minimal degree, as I think more about it) what you 
mean.   You can do data migrations via the API, which is versioned, and 
in between expand and contract, both APIs are available.(Goes to 
read the next several paragraphs to confirm that's what you mean).





So, for instance, let's say the widget class was represented in a 
nova.objects.widget.Widget model in the following code, before the 
patch that added the #1 schema migration:

...
Over time, the modified_timestamp DB field will be populated and there 
will be no need to run a single data migrationin any 
SQLAlchemy-migrate or Alembic script...


OK, I think my understanding is correct, though I'm not sure what over 
time means is there a migrate the data via API version 1.0 - 2.0 
step somewhere?  Or is the idea that, over time definitely is finished 
before contract is ever run, right?




OK, now here comes another developer and she adds DB schema migration 
#2 which adds the status_code field to the widgets table. Note that 
the widget_status table will still be around! The contract phase, 
which would remove the widget_status table isn't going to be run until 
the DBA has determined that all data migrations that happen in the 
Nova objects have occurred...
OK, not knowing the specifics, you just said, all data migrations that 
happen in the Nova objects, so OK, there *are* data migrations that 
someone has to run, somewhere.  They are between API version numbers, 
and the headache Nova has is that they have to constantly update these 
objects to maintain cross-API-version compatibility whenever the schema 
changes, OK.


The Widget class would look like this in the patch that adds the #2 DB 
schema migration:



 class Widget(base.NovaPersistentObject):
 VERSION = '1.1'
 fields = {
 'id': fields.IntegerField(),
 'name': fields.StringField(),
 'modified_timestamp': fields.DatetimeField(),
 'status_code': fields.IntegerField()
 }

 @staticmethod
 def _from_db_object(context, widget, db_obj):
 # db_obj is what comes back from the DB API call
 # widget_get(). The SQL for this call will look like this:
 #
 # SELECT id, modified_date, modified_timestamp,
 #   w.status_code, ws.status_code as ws_status_code
 # FROM widgets w JOIN widget_status ws ON id = widget_id
 # WHERE w.id = ?
 #
 # The returned data will look like this:
 # {'id': 1, 'name': 'my widget',
 #  'modified_date': '20150601',
 #  'modified_timestamp': None or datetime,
 #  'status_code': None or integer,
 #  'ws_status_code': None or integer
 for f in ('id', 'name'):
 widget[f] = db_obj[f]
 ts = db_obj['modified_timestamp']
 if ts is None:
 ts = datetime.datetime.strftime(db_obj['modified_date'])
 widget['modified_timestamp'] = ts
 sc = db_obj['status_code']
 if sc is None:
 sc = db_obj['ws_status_code']


OK now I...well I thought I really get it, but still seems like 
something I'm missing because this seems still very wrong:You not 
only can't do data migrations in the traditional way anymore, you have 
to write *all of your model code to be compatible with all versions of 
the schema at all times*.That is, moving tables, or even columns, 
around and such, very difficult (if not impossible?). For example.   
Your _from_db_object() above calls into a method that has to emit a JOIN 
from widget to widget_status.Meanwhile, the migration we really 
want to do is that we DROP widget_status in the contract phase.   My 
understanding is, a Nova application that is in the migrate stage can 
be sent through the contract stage with no code changes, correct?   
Then how can you possibly write the model code that queries for widget

Re: [openstack-dev] [oslo] Inviting Robert Collins to Oslo core

2015-05-21 Thread Mehdi Abaakouk



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



I'd like to invite Robert Collins (aka lifeless) as an Oslo core.
Robert has been a long time contributor to a whole bunch of OpenStack
projects and a member of our TC. Robert indicated that he can help
across Oslo projects this cycle, so let's please welcome him. Here's
my +1.


+1

- ---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

-BEGIN PGP SIGNATURE-
Version: OpenPGP.js v.1.20131017
Comment: http://openpgpjs.org

wkYEAREIABAFAlVeGWoJEJZbdE7sD8foAAAJ3gCeOdLi3ZpWRW24uk34FKAM
YDYEn1UAn1IQsnD6e8RcyUJEPjMBLubc3n9D
=3tM1
-END 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] [oslo] Inviting Robert Collins to Oslo core

2015-05-21 Thread Victor Stinner

+1 for Robert

Victor

  I'd like to invite Robert Collins (aka lifeless) as an Oslo core.
  Robert has been a long time contributor to a whole bunch of OpenStack
  projects and a member of our TC. Robert indicated that he can help
  across Oslo projects this cycle, so let's please welcome him. Here's
  my +1.

__
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] Stepping down from Neutron core team

2015-05-21 Thread Carl Baldwin

On May 21, 2015 9:06 AM, Kyle Mestery mest...@mestery.com wrote:

 On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando sorla...@nicira.com
wrote:

 After putting the whole OpenStack networking contributors community
through almost 8 cycles of pedant comments and annoying what if
questions, it is probably time for me to relieve neutron contributors from
this burden.

 It has been a pleasure for me serving the Neutron community (or Quantum
as it was called at the time), and now it feel right - and probably overdue
- to relinquish my position as a core team member in a spirit of rotation
and alternation between contributors.

 Note: Before you uncork your champagne bottles, please be aware that I
will stay in the Neutron community as a contributors and I might still end
up reviewing patches.

 Thanks for being so understanding with my pedant remarks,
 Salvatore


 If I could -1 this as a patch, I would.

 But seriously. Salvatore, thanks for all the years of work you've put
into Neutron. Please note that just because you've stepped down from the
core reviewer team doesn't mean we won't be relying on you to be a part of
the community.

 Thanks,
 Kyle

Kyle, I think you should -2 this one.  ;)  Maybe we should put the core
team list in a repo just so you can.

All joking aside, @Salv, I have appreciated your feedback much more than
you give yourself credit for, maybe more than I let on.  You don't need to
be a core to give it, so keep it coming.

Carl
__
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] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

2015-05-21 Thread Adam Harwell

Barbican is using SQLAlchemy, so I assume PostgreSQL is not a hard requirement. 
I know it deploys fine with SQLite for local development, and I am not aware of 
anything that would prevent it from running on MySQL. I am told it actually 
does use MySQL in devstack, so those docs may just be out of date.

--Adam

https://keybase.io/rm_you


From: Maish Saidel-Keesing mais...@maishsk.commailto:mais...@maishsk.com
Reply-To: maishsk+openst...@maishsk.commailto:maishsk+openst...@maishsk.com 
maishsk+openst...@maishsk.commailto:maishsk+openst...@maishsk.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 21, 2015 at 5:45 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

Thanks Doug! PSB my comments within.

On 05/20/15 22:49, Doug Wiegley wrote:
Hi Maish,

Thanks for the feedback, some answers below.  Please also be aware of the lbaas 
use cases session tomorrow at 9am (yuck, I know), 
https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases

Sorry but I will not be able to attend - I will be on a plane. I will look 
monitor the etherpad and pass my comments on.

On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing 
mais...@maishsk.commailto:mais...@maishsk.com wrote:

Hello all,

Going over today's presentation Load Balancing as a Service, Kilo and 
Beyond[1] (great presentation!!) - there are a few questions I have regarding 
the future release:

For Octavia 1.0:

1. Can someone explain to me how the flow would work for spinning up a new 
Amphora with regards to interaction between Neutron, LBaaS and Barbican?
Same question as well regarding how the standby is created and its relationship 
with Barbican.

The lbaas API runs inside neutron-server.  The general flow is:

- User interacts with neutron CLI/API or horizon (in liberty), and creates an 
LB.
- Lbaas plugin in neutron creates logical models, fetches cert data from 
barbican, and calls the backend lbaas driver.
From this I gather that there is a dependency on Barbican. From what I found - 
this thread looks like the HA modelling for barbican [1]. Seems to me to be 
quite solid.

There was one detail that aroused my attention. Barbican is using PostgreSQL as 
the backend database [2].
Is there any specific reason why PostgreSQL and not MySQL like the rest of 
OpenStack? Is there any tehnical limitation that specifically requires 
PostgreSQL?

*From an operators perspective inducing a new database technology (yet again) 
this will is not ideal to say the least.*
- The backend driver does what it needs to to instantiate the LB. Today this is 
a synchronous call that waits for the nova boot, but by Liberty, it will likely 
be an async call to the octavia controller to finish the job.

Once Octavia has control, it is doing:

- Get REST calls for objects,
- Talk to nova, spin up an amphora image,
- Talk to neutron, plumb in the networks,
- Send the amphora its config.


2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is 
released or only further down the line?
If not what would you suggest be the way to orchestrate LBaaS until this is 
ready?

We need to talk to the Heat folks and coordinate this, which we are planning to 
do soon.
Great! It would be ideal that this is available from Day 1, otherwise there 
will be no real to utilize this in production use cases.


3. Is there some kind of hook into Security groups also planned for the Amphora 
to also protect the Load Balancer?

Not at present, but I recorded this in the feature list on the etherpad above.
Much obliged - this is a basic security requirement that should be in place to 
protect/shield the load balancers from unwanted traffic.

[1] http://lists.openstack.org/pipermail/openstack/2014-March/006102.html
[2] https://github.com/cloudkeep/barbican/wiki/Architecture

--
Best Regards,
Maish Saidel-Keesing
__
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][heat] sqlalchemy-migrate tool to alembic




On 5/21/15 2:50 PM, Mike Bayer wrote:


Put another way, if I want to do a migration that someday, over 
time, eventually, etc., will drop the widget_status table and merge 
it into the widget table, how do I write the get_widget() DB API 
call ? Same for just dropping a column.   If we have to write code 
that will return the value of the old table / old column while it 
exists, how does that part work?   Somewhere, there has to be code 
that in one case says: query(Widget).join(WidgetStatus) and in other 
case says query(Widget).   You have to maintain *both* SQL queries 
at the same time?
OK I guess it is this: Kilo queries Widget JOIN WidgetStatus while 
Liberty queries just Widget - e.g. the two versions of the query are 
just in two different releases of the application.You need to run 
exclusively the old sqlalchemy/api.py version of the code before 
contract is run, that is, the new API / nova.objects runs against the 
old model code.


OK!   let me chew on that.


The good news is, online schema migrations does not invalidate all of 
Alembic's approach.   Version files and fixed schema states are still 
essential for mere mortals.   Openstack projects that aren't using 
oslo.objects will still need them.




__
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][Plugins] Instructions on CI were updated

2015-05-21 Thread Irina Povolotskaya

Hi to all,

please be informed that CI [1] section of the Fuel Plugins wiki page was
updated with the following issues:

   - Prerequisite steps for setting devtesting environment [2]
   - CI server configuration steps [3]

Feel free to review, ask questions and comment.

Thanks!
---
[1] https://wiki.openstack.org/wiki/Fuel/Plugins#CI
[2]
https://wiki.openstack.org/wiki/Fuel/Plugins#Steps_to_prepare_development_.26_testing_environments_.28mandatory.29
[3]
https://wiki.openstack.org/wiki/Fuel/Plugins#Steps_to_configure_CI_server_.28optional.29

-- 
Best regards,

Irina

PI Team Technical Writer
skype: ira_live
__
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] [MagnetoDB] IRC team meeting canceled

2015-05-21 Thread Ilya Sviridov

Hello team,

Let us cancel today meeting due to overlapping with summit.

Have a nice day.

-- 
With best regards
Ilya  Sviridov
__
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] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

2015-05-21 Thread Maish Saidel-Keesing


Thanks Brandon

On 05/20/15 22:58, Brandon Logan wrote:


Just to add a few things,

Barbican is not yet implemented in Octavia, though the code is there, 
we just need to spend a few hours hooking it all up and testing it out.



Also, the security groups are used by octavia right now so that only 
the ports on the listener are accessible.  Basically if a loadbalancer 
has listeners on ports 80 and 443, the vip ports will only allow 
traffic on those ports.  It shouldn't allow other traffic.


That is great to hear. I assume that if we are using security groups we 
will also be able to define rules regarding which networks the listeners 
are allowed to accept traffic from?


Is that assumption correct?



Thanks,

Brandon


*From:* Doug Wiegley doug...@parksidesoftware.com
*Sent:* Thursday, May 21, 2015 12:49 AM
*To:* maishsk+openst...@maishsk.com; OpenStack Development Mailing 
List (not for usage questions); Maish Saidel-Keesing
*Subject:* Re: [openstack-dev] [lbaas] [octavia] [barbican] 
Relationship between Octavia and Barbican and Octavia 1.0 questions

Hi Maish,

Thanks for the feedback, some answers below.  Please also be aware of 
the lbaas use cases session tomorrow at 9am (yuck, I know), 
https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases



On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing 
mais...@maishsk.com mailto:mais...@maishsk.com wrote:


Hello all,

Going over today's presentation Load Balancing as a Service, Kilo 
and Beyond[1] (great presentation!!) - there are a few questions I 
have regarding the future release:


For Octavia 1.0:

1. Can someone explain to me how the flow would work for spinning up 
a a new Amphora with regards to interaction between Neutron, LBaaS 
and Barbican?
Same question as well regarding how the standby is created and its 
relationship with Barbican.


The lbaas API runs inside neutron-server.  The general flow is:

- User interacts with neutron CLI/API or horizon (in liberty), and 
creates an LB.
- Lbaas plugin in neutron creates logical models, fetches cert data 
from barbican, and calls the backend lbaas driver.
- The backend driver does what it needs to to instantiate the LB. 
Today this is a synchronous call that waits for the nova boot, but by 
Liberty, it will likely be an async call to the octavia controller to 
finish the job.


Once Octavia has control, it is doing:

- Get REST calls for objects,
- Talk to nova, spin up an amphora image,
- Talk to neutron, plumb in the networks,
- Send the amphora its config.



2. Will the orchestration (Heat) also be implemented when Octavia 1.0 
is released or only further down the line?
If not what would you suggest be the way to orchestrate LBaaS until 
this is ready?


We need to talk to the Heat folks and coordinate this, which we are 
planning to do soon.




3. Is there some kind of hook into Security groups also planned for 
the Amphora to also protect the Load Balancer?


Not at present, but I recorded this in the feature list on the 
etherpad above.




I think that based on the answers to these questions above - 
additional questions will follow.


Thanks

[1] https://www.youtube.com/watch?v=-eAKur8lErU
--
Best Regards,
Maish Saidel-Keesing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org 
mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Best Regards,
Maish Saidel-Keesing
__
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] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

2015-05-21 Thread Maish Saidel-Keesing


Thanks Doug! PSB my comments within.

On 05/20/15 22:49, Doug Wiegley wrote:

Hi Maish,

Thanks for the feedback, some answers below.  Please also be aware of 
the lbaas use cases session tomorrow at 9am (yuck, I know), 
https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases


Sorry but I will not be able to attend - I will be on a plane. I will 
look monitor the etherpad and pass my comments on.


On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing 
mais...@maishsk.com mailto:mais...@maishsk.com wrote:


Hello all,

Going over today's presentation Load Balancing as a Service, Kilo 
and Beyond[1] (great presentation!!) - there are a few questions I 
have regarding the future release:


For Octavia 1.0:

1. Can someone explain to me how the flow would work for spinning up 
a new Amphora with regards to interaction between Neutron, LBaaS and 
Barbican?
Same question as well regarding how the standby is created and its 
relationship with Barbican.


The lbaas API runs inside neutron-server.  The general flow is:

- User interacts with neutron CLI/API or horizon (in liberty), and 
creates an LB.
- Lbaas plugin in neutron creates logical models, fetches cert data 
from barbican, and calls the backend lbaas driver.
From this I gather that there is a dependency on Barbican. From what I 
found - this thread looks like the HA modelling for barbican [1]. Seems 
to me to be quite solid.


There was one detail that aroused my attention. Barbican is using 
PostgreSQL as the backend database [2].
Is there any specific reason why PostgreSQL and not MySQL like the rest 
of OpenStack? Is there any tehnical limitation that specifically 
requires PostgreSQL?


*From an operators perspective inducing a new database technology (yet 
again) this will is not ideal to say the least.*
- The backend driver does what it needs to to instantiate the LB. 
Today this is a synchronous call that waits for the nova boot, but by 
Liberty, it will likely be an async call to the octavia controller to 
finish the job.


Once Octavia has control, it is doing:

- Get REST calls for objects,
- Talk to nova, spin up an amphora image,
- Talk to neutron, plumb in the networks,
- Send the amphora its config.



2. Will the orchestration (Heat) also be implemented when Octavia 1.0 
is released or only further down the line?
If not what would you suggest be the way to orchestrate LBaaS until 
this is ready?


We need to talk to the Heat folks and coordinate this, which we are 
planning to do soon.
Great! It would be ideal that this is available from Day 1, otherwise 
there will be no real to utilize this in production use cases.




3. Is there some kind of hook into Security groups also planned for 
the Amphora to also protect the Load Balancer?


Not at present, but I recorded this in the feature list on the 
etherpad above.
Much obliged - this is a basic security requirement that should be in 
place to protect/shield the load balancers from unwanted traffic.


[1] http://lists.openstack.org/pipermail/openstack/2014-March/006102.html
[2] https://github.com/cloudkeep/barbican/wiki/Architecture

--
Best Regards,
Maish Saidel-Keesing
__
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] [security] / IDS + openstack meeting in Vancouver 4:10 Wednesday May 20

2015-05-21 Thread Dan Lambright

Hello,

Notes from yesterdays IDS + openstack meeting can be found on the ether pad 
link below [1]. 

Going forward we can use that notepad to record ideas, in addition to this 
mailing list.

Thanks,
Dan Lambright

[1]
 
https://etherpad.openstack.org/p/hUNTWLGRok


- Original Message -
 From: Dan Lambright dlamb...@redhat.com
 To: openstack-dev@lists.openstack.org
 Sent: Tuesday, May 19, 2015 2:29:40 PM
 Subject: [security] / IDS + openstack meeting in Vancouver 4:10 Wednesday May 
 20
 
 Hello,
 
 While at the Vancouver summit, it would be good to have an informal meeting
 on IDS + openstack. My understanding is there has not been a community
 driven effort in this area to date. It would be good to kick something off.
 Likely subjects would be neutron plug-ins and scalability (management and
 monitoring).
 
 The best time would probably be after the TaaS talk Wednesday. TaaS may
 influence what direction to take.
 
 I will be next to the ATM machine on the 1st floor, next to where they give
 away the windbreaker SWAG. I’ll hang out there between 4:10 and 4:30. Please
 feel free to find a drink and  walk over. I will also post this announcement
 to the openstack-dev mailing list
 (http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev). The
 subject will contain: [security] {IDS}
 
 Thanks,
 
 Dan Lambright
 Red Hat

__
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] Changes to oslo.log section of Oslo Wiki page for source repo and bug reporting

2015-05-21 Thread Andreas Maier


Hello Dims

 2. Can you please switch it to
 http://git.openstack.org/cgit/openstack/oslo.log/ ? If you see
 http://git.openstack.org/ you will see all the projects

Done.

Andy



__
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] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

2015-05-21 Thread Brandon Logan

?Right now its all or nothing as far as tcp ports go.  It currently does not 
have the functionality of white/black listinging traffic originating from a 
specific network.

From: Maish Saidel-Keesing mais...@maishsk.com
Sent: Thursday, May 21, 2015 7:45 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

Thanks Brandon

On 05/20/15 22:58, Brandon Logan wrote:

?Just to add a few things,

Barbican is not yet implemented in Octavia, though the code is there, we just 
need to spend a few hours hooking it all up and testing it out.

Also, the security groups are used by octavia right now so that only the ports 
on the listener are accessible.  Basically if a loadbalancer has listeners on 
ports 80 and 443, the vip ports will only allow traffic on those ports.  It 
shouldn't allow other traffic.

That is great to hear. I assume that if we are using security groups we will 
also be able to define rules regarding which networks the listeners are allowed 
to accept traffic from?

Is that assumption correct?

Thanks,

Brandon

From: Doug Wiegley 
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com
Sent: Thursday, May 21, 2015 12:49 AM
To: maishsk+openst...@maishsk.commailto:maishsk+openst...@maishsk.com; 
OpenStack Development Mailing List (not for usage questions); Maish 
Saidel-Keesing
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between 
Octavia and Barbican and Octavia 1.0 questions

Hi Maish,

Thanks for the feedback, some answers below.  Please also be aware of the lbaas 
use cases session tomorrow at 9am (yuck, I know), 
https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases

On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing 
mais...@maishsk.commailto:mais...@maishsk.com wrote:

Hello all,

Going over today's presentation Load Balancing as a Service, Kilo and 
Beyond[1] (great presentation!!) - there are a few questions I have regarding 
the future release:

For Octavia 1.0:

1. Can someone explain to me how the flow would work for spinning up a a new 
Amphora with regards to interaction between Neutron, LBaaS and Barbican?
Same question as well regarding how the standby is created and its relationship 
with Barbican.

The lbaas API runs inside neutron-server.  The general flow is:

- User interacts with neutron CLI/API or horizon (in liberty), and creates an 
LB.
- Lbaas plugin in neutron creates logical models, fetches cert data from 
barbican, and calls the backend lbaas driver.
- The backend driver does what it needs to to instantiate the LB. Today this is 
a synchronous call that waits for the nova boot, but by Liberty, it will likely 
be an async call to the octavia controller to finish the job.

Once Octavia has control, it is doing:

- Get REST calls for objects,
- Talk to nova, spin up an amphora image,
- Talk to neutron, plumb in the networks,
- Send the amphora its config.

2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is 
released or only further down the line?
If not what would you suggest be the way to orchestrate LBaaS until this is 
ready?

We need to talk to the Heat folks and coordinate this, which we are planning to 
do soon.

3. Is there some kind of hook into Security groups also planned for the Amphora 
to also protect the Load Balancer?

Not at present, but I recorded this in the feature list on the etherpad above.

I think that based on the answers to these questions above - additional 
questions will follow.

Thanks

[1] https://www.youtube.com/watch?v=-eAKur8lErU
--
Best Regards,
Maish Saidel-Keesing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best Regards,
Maish Saidel-Keesing
__
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] [Barbican] Nominating Chelsea Winfree for Barbican core

2015-05-21 Thread John Wood

?+1

From: Chad Lung chad.l...@gmail.com
Sent: Sunday, May 17, 2015 6:34 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Barbican] Nominating Chelsea Winfree for Barbican core

Hi all,

I'd like to nominate Chelsea Winfree for the Barbican core review team.

Chelsea has been active in Barbican as a regular contributor of code and 
helping always needed documentation. 
http://stackalytics.com/?user_id=chelsea-winfreerelease=all

As a reminder to barbican-core members we use the voting process outlined
in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
team.

Thanks,

Chad Lung
EMC Cloud Services

__
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] Resigning as StoryBoard-Core

2015-05-21 Thread James E. Blair

Michael Krotscheck krotsch...@gmail.com writes:

 I am resigning, effective immediately, as StoryBoard Core, and will no
 longer contribute to the project.

Thank you for your work on Storyboard and I look forward to working with
you as you share your expertise with other parts of the OpenStack
project.

-Jim

__
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] Changes to oslo.log section of Oslo Wiki page for source repo and bug reporting

2015-05-21 Thread Davanum Srinivas

Andreas,

Thanks!

1. https://launchpad.net/oslo is an umbrella and oslo.log is under it.
If you try to create a bug from https://bugs.launchpad.net/oslo you
will be prompted to enter/choose oslo.log. So either way the bug
created from either urls ends up int he same plate. So either url is
ok.

2. Can you please switch it to
http://git.openstack.org/cgit/openstack/oslo.log/ ? If you see
http://git.openstack.org/ you will see all the projects

thanks,
dims

On Thu, May 21, 2015 at 1:35 PM, Andreas Maier mai...@de.ibm.com wrote:

 Hi,
 I'd like to notify the Oslo community of these two changes to the oslo.log
 section on the Oslo Wiki page:

 1. There were conflicting statements about where bugs against oslo.log
 should be created:
   - The CONTRIBUTING.rst file in oslo.log suggests:
   https://bugs.launchpad.net/oslo.log
   - The oslo.log section on the Oslo Wiki page mentions:
   https://bugs.launchpad.net/oslo
Based on where bugs are currently open, I suspected that the information
on the Oslo Wiki page would be outdated, and updated it accordingly.

 2. There was no link to a source repo yet for oslo.log on the Oslo Wiki
 page, so I added one to the github.com repo.

 If any of that was a bad idea, please let me know.

 Andy


 __
 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [pbr] 1.0.1 released

2015-05-21 Thread fumihiko kakuma

Hi,

Thank you for reply.
I'll try those.

On Fri, 22 May 2015 04:52:50 +1200
Robert Collins robe...@robertcollins.net wrote:

 Hi, we've got a day tomorrow where we're going to try and figure out
 the future management of requirements in library packages (amongst
 many other things) - I've advised olso-release to ignore the pbr  1.0
 issue for a little bit, so maybe we can see if other dep changes are
 needed at the same time.
 
 But yes, there are many things that need to release with the broadened
 pbr requirements to become fully resolvable. You can force this by pip
 install -U pbr after your things are installed.

-- 
fumihiko kakuma kak...@valinux.co.jp



__
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] [pbr] 1.0.1 released

2015-05-21 Thread Brant Knudson

On Thu, May 21, 2015 at 10:17 AM, Robert Collins robe...@robertcollins.net
wrote:

 On 22 May 2015 at 05:14, Brant Knudson b...@acm.org wrote:
 
  On Thu, May 21, 2015 at 2:22 AM, YAMAMOTO Takashi 
 yamam...@valinux.co.jp
  wrote:
 
  hi,
 
  can you explain why you want to use pbr 1.0.1 in the first place?
  what's wrong with requiring pbr1.0 ?
 
 
  Global requirements currently has pbr=0.11,2.0[1], and
  keystonemiddleware has the updated requirement which conflicts with
  oslo.config, so now the keystonemiddleware gate is broken[2].

 You can fix this immediately:

 2015-05-21 13:51:45.876 |   File
 keystonemiddleware/tests/unit/test_opts.py, line 80, in
 test_entry_point
 2015-05-21 13:51:45.876 | list_fn = ep.load()

 is the problem: test_opts is unnecessarily cross-checking dependencies are
 met.

 See https://review.openstack.org/#/c/184319/

 (Yes we do need to release all the oslo things, but the test isn't
 interested in dep management, its interested in whether the plugins
 implement the right config options. There is a stevedore API that
 would be even better to use - see the review linked above.)

 -Rob


Here's the proposed change for keystonemiddleware:
https://review.openstack.org/#/c/184864/

Worked for me. Thanks!

 - Brant
__
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] [api] [docs] improving app Dev docs

2015-05-21 Thread michael mccune


On 05/21/2015 01:10 PM, Anne Gentle wrote:

Hi all, please come to the API doc working session this morning at 11:50 in 305 
if you want to work on plans for next-gen API docs in Liberty.

https://libertydesignsummit.sched.org/mobile/#session:29e7d4effc10832b4d6aa50339e0c973


is there an etherpad available for this session?

i was, sadly, unable to attend but i am very interested in this effort.

mike

__
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] Changes to oslo.log section of Oslo Wiki page for source repo and bug reporting

2015-05-21 Thread Andreas Maier


Hi,
I'd like to notify the Oslo community of these two changes to the oslo.log
section on the Oslo Wiki page:

1. There were conflicting statements about where bugs against oslo.log
should be created:
  - The CONTRIBUTING.rst file in oslo.log suggests:
  https://bugs.launchpad.net/oslo.log
  - The oslo.log section on the Oslo Wiki page mentions:
  https://bugs.launchpad.net/oslo
   Based on where bugs are currently open, I suspected that the information
   on the Oslo Wiki page would be outdated, and updated it accordingly.

2. There was no link to a source repo yet for oslo.log on the Oslo Wiki
page, so I added one to the github.com repo.

If any of that was a bad idea, please let me know.

Andy


__
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] [Barbican] Nominating Chelsea Winfree for Barbican core

2015-05-21 Thread Juan Antonio Osorio

+1

On Thu, May 21, 2015 at 11:05 PM, John Wood john.w...@rackspace.com wrote:

  +1
  --
 *From:* Chad Lung chad.l...@gmail.com
 *Sent:* Sunday, May 17, 2015 6:34 PM
 *To:* openstack-dev@lists.openstack.org
 *Subject:* [openstack-dev] [Barbican] Nominating Chelsea Winfree for
 Barbican core

  Hi all,

 I'd like to nominate Chelsea Winfree for the Barbican core review team.

 Chelsea has been active in Barbican as a regular contributor of code and
 helping always needed documentation.
 http://stackalytics.com/?user_id=chelsea-winfreerelease=all

 As a reminder to barbican-core members we use the voting process outlined
 in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
 team.

 Thanks,

 Chad Lung
 EMC Cloud Services



 __
 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




-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.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] [Nova][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Daniel P. Berrange

On Thu, May 21, 2015 at 09:34:20PM +1200, Xav Paice wrote:
 On 21/05/15 21:23, Daniel P. Berrange wrote:
  On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote:
  I note that we use instance.name to lookup the libvirt domain a bunch
  in the driver. I'm wondering why we don't just use instance.uuid all
  the time -- the code for that already exists. Is there a good reason
  to not move to always using the uuid?
 
  I ask because instance.name is not guaranteed to be unique depending
  on how weird the nova deployment is.
  Agreed, there's no benefit to using name - internally libvirt will always
  prefer to use the UUID itself too.
 
  These days though, there is only a single place in nova libvirt driver
  that needs updating - the nova.virt.libvirt.host.Host class get_domain()
  method just needs to be switched to use uuid.
 
 Just a comment from an ops point of view - it would be miles easier when
 trying to troubleshoot, if the instance name was the uuid anyway.  I
 totally agree on using instance.uuid, just to comment that I find it a
 little painful sometimes that instance names don't match the uuid of the
 instance, but the directory structure does.  Just a bit of confusion to
 avoid at 2am when something isn't working.

You do know you can configure the instance name used...

eg in nova.conf

  instance_name_template='inst-%(uuid)s'

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

__
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] What is a best way to find calls to Neutron API in OVS

2015-05-21 Thread Daniel Depaoli

Hi. I think you should start from [1], in particular in the functions
index,show,create,delete,update. Have a look when in this file it uses the
python method 'getattr' to obtain the plugin and method to call.
To understand the way neutron works I used devstack and python debugger to
stop the code in these and others functions and to print the methods and
variables value. It should bu useful also for you!

[1]https://github.com/openstack/neutron/blob/master/neutron/api/v2/base.py

On Wed, May 20, 2015 at 12:43 PM, Leo Y minh...@gmail.com wrote:

 Hello,

 Sorry for newbie question. I'm trying to identify all invocations of
 neutron API in OVS [1] and get lost. What is a best practice to find in
 code all neutron API calls regardless of the method they are done.
 I'll appreciate if anyone can reference me to documentation that describes
 ways to invoke neutron API calls.



 [1]
 https://github.com/openstack/neutron/tree/master/neutron/plugins/openvswitch

 --
 Regards,
 LeoY
 -
 I enjoy the massacre of ads. This sentence will slaughter ads without a
 messy bloodbath

 __
 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




-- 

Daniel Depaoli
CREATE-NET Research Center
Smart Infrastructures Area
Junior Research Engineer

__
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][service] oslo.service puplic repositiry review request

2015-05-21 Thread Elena Ezhova

Hi, all!

As the spec for the graduation of oslo.service [1] is about to merge I have
created a public repository on github [2] with oslo.service initial
version, which is the next step in graduation of a library according to [3].

I would like to ask everyone interested to review it so we can proceed with
the graduation process.

Thanks, Elena


[1] https://review.openstack.org/#/c/142659/9
[2] https://github.com/eezhova/oslo.service
[3] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
__
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][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Sahid Orentino Ferdjaoui

On Thu, May 21, 2015 at 10:23:35AM +0100, Daniel P. Berrange wrote:
 On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote:
  I note that we use instance.name to lookup the libvirt domain a bunch
  in the driver. I'm wondering why we don't just use instance.uuid all
  the time -- the code for that already exists. Is there a good reason
  to not move to always using the uuid?
  
  I ask because instance.name is not guaranteed to be unique depending
  on how weird the nova deployment is.
 
 Agreed, there's no benefit to using name - internally libvirt will always
 prefer to use the UUID itself too.
 
 These days though, there is only a single place in nova libvirt driver
 that needs updating - the nova.virt.libvirt.host.Host class get_domain()
 method just needs to be switched to use uuid.

I'm currently working on the libvirt driver I can add this in my TODO

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

s.

__
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] needed, driver for oslo.db thursday session

2015-05-21 Thread Roman Podoliaka

Will try to make it, but will probably be in 'read-only' mode, sorry :(

On Wed, May 20, 2015 at 5:59 PM, Mike Bayer mba...@redhat.com wrote:


 On 5/20/15 9:31 AM, Davanum Srinivas wrote:

 Thanks Jeremy,

 Mike, Roman, Victor, Please see remote connection details in:
 https://etherpad.openstack.org/p/YVR-oslo-db-plans

 The schedule time for the session is in:

 https://libertydesignsummit.sched.org/event/3571aa54b364c62e097da8cd32d97258

 Hope you can make it :) yes, please pick one of the 2 choices there
 (either sip or google hangout) and drop a note in the etherpad which
 one you want me to connect to


 probably google hangout, maybe my cats can join in that way also.

 confirming this is 2:20 PM PDT and 5:20 PM EDT for me.

 I've updated my calendar, talk to you tomorrow.






 thanks,
 dims


 On Tue, May 19, 2015 at 10:17 AM, Jeremy Stanley fu...@yuggoth.org
 wrote:

 On 2015-05-19 09:06:56 -0700 (-0700), Davanum Srinivas wrote:

 Ouch. Thanks for the heads up Roman

 We have https://wiki.openstack.org/wiki/Infrastructure/Conferencing
 which we used yesterday to successfully bridge Clark B. into an I18n
 tooling session via Jitsi over the normal conference wireless
 network with the built-in mic/speaker in Jim's laptop. Feel free to
 use it in your sessions, just try to pick a random conference number
 between 6000 and 7999 so nobody steps on the toes of other sessions
 which might be using it (maybe add your conference room number to
 6000 or something?). Let me or other Infra people know if you have
 any questions about or trouble using it!
 --
 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





 __
 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][oslo] RPC Asynchronous Communication

2015-05-21 Thread Sahid Orentino Ferdjaoui

On Fri, May 08, 2015 at 09:13:59AM -0400, Doug Hellmann wrote:
 Excerpts from Joe Gordon's message of 2015-05-07 17:43:06 -0700:
  On May 7, 2015 2:37 AM, Sahid Orentino Ferdjaoui 
  sahid.ferdja...@redhat.com wrote:
  
   Hi,
  
   The primary point of this expected discussion around asynchronous
   communication is to optimize performance by reducing latency.
  
   For instance the design used in Nova and probably other projects let
   able to operate ascynchronous operations from two way.
  
   1. When communicate between inter-services
   2. When communicate to the database
  
   1 and 2 are close since they use the same API but I prefer to keep a
   difference here since the high level layer is not the same.
  
   From Oslo Messaging point of view we currently have two methods to
   invoke an RPC:
  
 Cast and Call: The first one is not bloking and will invoke a RPC
   without to wait any response while the second will block the
   process and wait for the response.
  
   The aim is to add new method which will return without to block the
   process an object let's call it Future which will provide some basic
   methods to wait and get a response at any time.
  
   The benefice from Nova will comes on a higher level:
  
   1. When communicate between services it will be not necessary to block
  the process and use this free time to execute some other
  computations.
  
  Isn't this what the use of green threads (and eventlet) is supposed to
  solve. Assuming my understanding is correct, and we can fix any issues
  without adding async oslo.messaging, then adding yet another async pattern
  seems like a bad thing.

The aim is to be not library specific and avoid to add different and
custom patterns on the base code each time we want something not
blocking.
We can let the well experimented community working in olso messaging
to maintain that part and as Doug said oslo can use different
executors so we can avoid the requirement of a specific library.

 Yes, this is what the various executors in the messaging library do,
 including the eventlet-based executor we use by default.
 
 Where are you seeing nova block on RPC calls?

In Nova we use the indirection api to make call to the database by the
conductor through RPCs.
By the solution presented we can create async operations to read and
write from the database.

Olekssi asks me to give an example I will reply to him.

s.
 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

Re: [openstack-dev] [Neutron][Magnum] Container + OpenStack Integration

2015-05-21 Thread Fox, Kevin M

Since docker 1.7 is suposed to support advanced networking, could that just be 
plugged into neutron?

Thanks,
Kevin

From: Brenden Blanco
Sent: Thursday, May 21, 2015 6:40:37 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][Magnum] Container + OpenStack Integration

Hi,

Just brainstorming here, but IMHO it would be good to keep it extensible and 
not to lock in VLAN as the sole container VIF mechanism. For instance, there 
is the ipvlan [1] technology that was purpose-built to be more appropriate for 
container systems. This tech actually comes from some of the Google folks that 
deploy containers at scale, if my memory serves correctly. So, we may want to 
start with VLAN as the reference implementation but should leave it open to try 
out an alternative such as the above in the near future. Perhaps in practice 
this implies that the vid field of the neutron side isn't strictly an int 
field, not sure.

Cheers,
Brenden Blanco

[1] https://lwn.net/Articles/620087/

On Wed, May 20, 2015 at 11:21 PM, Kevin Benton 
blak...@gmail.commailto:blak...@gmail.com wrote:
Hi,

I wasn't able to make it to the session but from the etherpad I saw
that the VLAN-aware VMs mentioned there. Would that be enough to cover
this particular use-case?

On Wed, May 20, 2015 at 3:28 AM, Adrian Otto 
adrian.o...@rackspace.commailto:adrian.o...@rackspace.com wrote:
 Magnum and Neutron Teams,

 If you are in Vancouver today and can help design or implement native
 networking support to obviate the need for overlay networks when using
 containers, please join this design session:

 http://sched.co/3CjK (3:30 PM, Room 303)

 This will be based on feedback gathered at the Fishbowl session earlier in
 the day: http://sched.co/3B0z (11:00 AM, Room 306)

 Thanks,

 Adrian

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

--
Kevin Benton

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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][Magnum] Container + OpenStack Integration

2015-05-21 Thread Brenden Blanco

Hi,

Just brainstorming here, but IMHO it would be good to keep it extensible
and not to lock in VLAN as the sole container VIF mechanism. For
instance, there is the ipvlan [1] technology that was purpose-built to be
more appropriate for container systems. This tech actually comes from some
of the Google folks that deploy containers at scale, if my memory serves
correctly. So, we may want to start with VLAN as the reference
implementation but should leave it open to try out an alternative such as
the above in the near future. Perhaps in practice this implies that the vid
field of the neutron side isn't strictly an int field, not sure.

Cheers,
Brenden Blanco

[1] https://lwn.net/Articles/620087/

On Wed, May 20, 2015 at 11:21 PM, Kevin Benton blak...@gmail.com wrote:

 Hi,

 I wasn't able to make it to the session but from the etherpad I saw
 that the VLAN-aware VMs mentioned there. Would that be enough to cover
 this particular use-case?

 On Wed, May 20, 2015 at 3:28 AM, Adrian Otto adrian.o...@rackspace.com
 wrote:
  Magnum and Neutron Teams,
 
  If you are in Vancouver today and can help design or implement native
  networking support to obviate the need for overlay networks when using
  containers, please join this design session:
 
  http://sched.co/3CjK (3:30 PM, Room 303)
 
  This will be based on feedback gathered at the Fishbowl session earlier
 in
  the day: http://sched.co/3B0z (11:00 AM, Room 306)
 
  Thanks,
 
  Adrian
 
 
 __
  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
 



 --
 Kevin Benton

 __
 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] [Manila] Question to driver maintainers

2015-05-21 Thread Csaba Henk

Hi Ben and Luis,

TL;DR: it was my misunderstanding and both glusterfs* drivers
will be able to support resize (extension and shrinking) without
disruption.

There was no doubt about that GlusterFS supports a volume resize
operation. What I had a problem with is that the API to it is too
low level -- ATM there is no such high-level unary command as
gluster volume resize volume, but one also has to specify the
resources which are pulled in to facilitate the extension
(or the administrator can do the extension out of band, ie. not
through the gluster command). Specifying such entities would be
problematic if it was to be done from Manila context.

However, what I realized after consulting the gluster folks is
that with our data model(s) we don't have to do a volume resize
to facilitate a share resize, we can rely on the high level
part of the gluster management interface. 

Csaba

- Original Message -
 From: Luis Pabon lpa...@redhat.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Wednesday, May 20, 2015 9:13:16 PM
 Subject: Re: [openstack-dev] [Manila] Question to driver maintainers
 
 Hi guys, I am a little confused and would like to maybe clear some things up.
 GlusterFS (the storage system) does support the ability to resize volumes.
 I will talk to Csaba and see what he means, and we will get back to you
 soon.
 
 - Original Message -
 From: Ben Swartzlander b...@swartzlander.org
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Sent: Tuesday, May 19, 2015 12:41:31 PM
 Subject: Re: [openstack-dev] [Manila] Question to driver maintainers
 
 On 05/19/2015 10:42 AM, Csaba Henk wrote:
  Hi Igor,
 
  From: Igor Malinovskiy imalinovs...@mirantis.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  Sent: Monday, May 18, 2015 10:15:25 AM
  Subject: [openstack-dev] [Manila] Question to driver maintainers
  ...
  So I want to ask driver maintainers here:
  Will your driver be able to do share extending without loss of
  connectivity?
  Currenty:
 
  - glusterfs driver can
  - glusterfs-native won't support share extension (*)
 
  in Liberty timeframe, we are to unify the glusterfs* drivers' backend
  management logic, so both glusterfs driver style and glusterfs-native
  driver style backend management will be available for both drivers
  (actual choice made in configuration). So when this will be in place,
  the answer modifies as follows:
 
  - glusterfs and glusterfs-native will either support non-disruptive
 share extension, or won't support share resize at all (*) (depending
 on configuration)
 
 Csaba, this is a truly interesting set of limitations! I'm trying to
 understand what's going on down in the storage system to prevent the
 extension. Is it a case of not having enough free space? Or can you
 support creating new (larger) shares on the same backend while
 simultaneously not being able to resize an existing share? Is there some
 mapping to physical resources that's immutable once configured? What is
 your recommendation to customers who run out of space in a glusterfs
 share today (independent of Manila)?
 
 If your system can't support this case then I'm worried others may have
 similar problems and we could end up having to choose between making
 extend an optional operation (a choice I don't like) or making the
 glusterfs-native driver and possibly other drivers unsupported (also an
 option I don't like).
 
 -Ben
 
  (*) There are efforts to remove this limitation in GlusterFS, but too
  vague at this point to make a statement on it.
 
  Csaba
 
 
  __
  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] [Manila] Question to driver maintainers

2015-05-21 Thread Csaba Henk

Small correction follows, 

Csaba

- Original Message -
 From: Csaba Henk ch...@redhat.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Thursday, May 21, 2015 3:28:04 PM
 Subject: Re: [openstack-dev] [Manila] Question to driver maintainers

 Hi Ben and Luis,

 TL;DR: it was my misunderstanding and both glusterfs* drivers
 will be able to support resize (extension and shrinking) without
 disruption.

 There was no doubt about that GlusterFS supports a volume resize
 operation. What I had a problem with is that the API to it is too
 low level -- ATM there is no such high-level unary command as
 gluster volume resize volume, but one also has to specify the

... that would of course be a binary command like

  gluster volume resize volume size

 resources which are pulled in to facilitate the extension
 (or the administrator can do the extension out of band, ie. not
 through the gluster command). Specifying such entities would be
 problematic if it was to be done from Manila context.

 However, what I realized after consulting the gluster folks is
 that with our data model(s) we don't have to do a volume resize
 to facilitate a share resize, we can rely on the high level
 part of the gluster management interface.

 Csaba

 - Original Message -
  From: Luis Pabon lpa...@redhat.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  Sent: Wednesday, May 20, 2015 9:13:16 PM
  Subject: Re: [openstack-dev] [Manila] Question to driver maintainers

  Hi guys, I am a little confused and would like to maybe clear some things
  up.
  GlusterFS (the storage system) does support the ability to resize volumes.
  I will talk to Csaba and see what he means, and we will get back to you
  soon.

  - Original Message -
  From: Ben Swartzlander b...@swartzlander.org
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  Sent: Tuesday, May 19, 2015 12:41:31 PM
  Subject: Re: [openstack-dev] [Manila] Question to driver maintainers

  On 05/19/2015 10:42 AM, Csaba Henk wrote:
   Hi Igor,

   From: Igor Malinovskiy imalinovs...@mirantis.com
   To: OpenStack Development Mailing List (not for usage questions)
   openstack-dev@lists.openstack.org
   Sent: Monday, May 18, 2015 10:15:25 AM
   Subject: [openstack-dev] [Manila] Question to driver maintainers
   ...
   So I want to ask driver maintainers here:
   Will your driver be able to do share extending without loss of
   connectivity?
   Currenty:

   - glusterfs driver can
   - glusterfs-native won't support share extension (*)

   in Liberty timeframe, we are to unify the glusterfs* drivers' backend
   management logic, so both glusterfs driver style and glusterfs-native
   driver style backend management will be available for both drivers
   (actual choice made in configuration). So when this will be in place,
   the answer modifies as follows:

   - glusterfs and glusterfs-native will either support non-disruptive
  share extension, or won't support share resize at all (*) (depending
  on configuration)

  Csaba, this is a truly interesting set of limitations! I'm trying to
  understand what's going on down in the storage system to prevent the
  extension. Is it a case of not having enough free space? Or can you
  support creating new (larger) shares on the same backend while
  simultaneously not being able to resize an existing share? Is there some
  mapping to physical resources that's immutable once configured? What is
  your recommendation to customers who run out of space in a glusterfs
  share today (independent of Manila)?

  If your system can't support this case then I'm worried others may have
  similar problems and we could end up having to choose between making
  extend an optional operation (a choice I don't like) or making the
  glusterfs-native driver and possibly other drivers unsupported (also an
  option I don't like).

  -Ben

   (*) There are efforts to remove this limitation in GlusterFS, but too
   vague at this point to make a statement on it.

   Csaba

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

Re: [openstack-dev] [Nova][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Mathieu Gagné

On 2015-05-21 3:13 AM, Daniel P. Berrange wrote:
 On Thu, May 21, 2015 at 09:34:20PM +1200, Xav Paice wrote:
 On 21/05/15 21:23, Daniel P. Berrange wrote:
 On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote:
 I note that we use instance.name to lookup the libvirt domain a bunch
 in the driver. I'm wondering why we don't just use instance.uuid all
 the time -- the code for that already exists. Is there a good reason
 to not move to always using the uuid?

 I ask because instance.name is not guaranteed to be unique depending
 on how weird the nova deployment is.
 Agreed, there's no benefit to using name - internally libvirt will always
 prefer to use the UUID itself too.

 These days though, there is only a single place in nova libvirt driver
 that needs updating - the nova.virt.libvirt.host.Host class get_domain()
 method just needs to be switched to use uuid.

 Just a comment from an ops point of view - it would be miles easier when
 trying to troubleshoot, if the instance name was the uuid anyway.  I
 totally agree on using instance.uuid, just to comment that I find it a
 little painful sometimes that instance names don't match the uuid of the
 instance, but the directory structure does.  Just a bit of confusion to
 avoid at 2am when something isn't working.
 
 You do know you can configure the instance name used...
 
 eg in nova.conf
 
   instance_name_template='inst-%(uuid)s'
 

Please note that you CANNOT change instance_name_template ones instances
are created otherwise they become unmanageable by Nova. This is because
Nova tries to find the libvirt instance by its name instead of its UUID.
So since instances were spawned with the old value, it won't find
existing instances using the new value.

And no, I haven't found a way to rename an instance without
redefining/restarting it in libvirt.

-- 
Mathieu

__
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][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Chris Friesen


On 05/21/2015 03:20 PM, Mathieu Gagné wrote:

On 2015-05-21 3:13 AM, Daniel P. Berrange wrote:

On Thu, May 21, 2015 at 09:34:20PM +1200, Xav Paice wrote:

On 21/05/15 21:23, Daniel P. Berrange wrote:

On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote:

I note that we use instance.name to lookup the libvirt domain a bunch
in the driver. I'm wondering why we don't just use instance.uuid all
the time -- the code for that already exists. Is there a good reason
to not move to always using the uuid?

I ask because instance.name is not guaranteed to be unique depending
on how weird the nova deployment is.

Agreed, there's no benefit to using name - internally libvirt will always
prefer to use the UUID itself too.

These days though, there is only a single place in nova libvirt driver
that needs updating - the nova.virt.libvirt.host.Host class get_domain()
method just needs to be switched to use uuid.


Just a comment from an ops point of view - it would be miles easier when
trying to troubleshoot, if the instance name was the uuid anyway.  I
totally agree on using instance.uuid, just to comment that I find it a
little painful sometimes that instance names don't match the uuid of the
instance, but the directory structure does.  Just a bit of confusion to
avoid at 2am when something isn't working.


You do know you can configure the instance name used...

eg in nova.conf

   instance_name_template='inst-%(uuid)s'



Please note that you CANNOT change instance_name_template ones instances
are created otherwise they become unmanageable by Nova. This is because
Nova tries to find the libvirt instance by its name instead of its UUID.
So since instances were spawned with the old value, it won't find
existing instances using the new value.

And no, I haven't found a way to rename an instance without
redefining/restarting it in libvirt.


Is there any reason why we couldn't default to using something like 
'inst-%(uuid)s' for the instance name?


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

Re: [openstack-dev] [all][oslo] disabling pypy unit test jobs for oslo

2015-05-21 Thread Dolph Mathews

Keystone is certainly CPU bound while doing crypto operations
(authentication, token creation, token validation, etc), so we're
experimenting with pypy now, but don't have any strong interest in the gate
jobs running *currently*. We might want to add one for keystone at some
point, though.

On Wed, May 20, 2015 at 10:23 AM, Robert Collins robe...@robertcollins.net
wrote:

 On 11 May 2015 at 23:51, Sean Dague s...@dague.net wrote:
  It appears that we've basically run out of interest / time in
  realistically keeping pypy working in our system.
 
  With the focus on really getting python 3.4 working, it seems like it
  would just be better to drop pypy entirely in the system. In the last
  couple of years we've not seen any services realistically get to the
  point of being used for any of the services. And as seen by this last
  failure, pypy is apparently not keeping up with upstream tooling changes.

 So pypy is useful for clients - so that folk using pypy can talk to
 OpenStack. I don't have a view on the servers today - certainly the
 majority of our servers are not CPU bound.

 I asked for volunteers on Twitter - people that about openstack and
 pypy, and got two, one of whom helped us with the current glitch -
 which was all fixed by using modern virtualenv, so it was easy :).

 I've put a web page together summarising my understanding of the
 situation: https://wiki.openstack.org/wiki/PyPy

 I think we should make the jobs voting again (checking that each one
 is passing first, of course).

 -Rob

 __
 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][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Mathieu Gagné

On 2015-05-21 3:38 PM, Chris Friesen wrote:
 On 05/21/2015 03:20 PM, Mathieu Gagné wrote:
 On 2015-05-21 3:13 AM, Daniel P. Berrange wrote:
 On Thu, May 21, 2015 at 09:34:20PM +1200, Xav Paice wrote:
 On 21/05/15 21:23, Daniel P. Berrange wrote:
 On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote:
 I note that we use instance.name to lookup the libvirt domain a bunch
 in the driver. I'm wondering why we don't just use instance.uuid all
 the time -- the code for that already exists. Is there a good reason
 to not move to always using the uuid?

 I ask because instance.name is not guaranteed to be unique depending
 on how weird the nova deployment is.
 Agreed, there's no benefit to using name - internally libvirt will
 always
 prefer to use the UUID itself too.

 These days though, there is only a single place in nova libvirt driver
 that needs updating - the nova.virt.libvirt.host.Host class
 get_domain()
 method just needs to be switched to use uuid.

 Just a comment from an ops point of view - it would be miles easier
 when
 trying to troubleshoot, if the instance name was the uuid anyway.  I
 totally agree on using instance.uuid, just to comment that I find it a
 little painful sometimes that instance names don't match the uuid of
 the
 instance, but the directory structure does.  Just a bit of confusion to
 avoid at 2am when something isn't working.

 You do know you can configure the instance name used...

 eg in nova.conf

instance_name_template='inst-%(uuid)s'


 Please note that you CANNOT change instance_name_template ones instances
 are created otherwise they become unmanageable by Nova. This is because
 Nova tries to find the libvirt instance by its name instead of its UUID.
 So since instances were spawned with the old value, it won't find
 existing instances using the new value.

 And no, I haven't found a way to rename an instance without
 redefining/restarting it in libvirt.
 
 Is there any reason why we couldn't default to using something like
 'inst-%(uuid)s' for the instance name?
 

I guess it's for the reason I mentioned above:

To not break all OpenStack installations on Earth running with default
config values.

-- 
Mathieu

__
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] Review dashboard for oslo?

2015-05-21 Thread Doug Hellmann

Excerpts from Michael Still's message of 2015-05-21 15:33:21 -0700:
 Oh cool. Thanks!

See also https://review.openstack.org/184825 and tox -e dashboards.

Doug

 
 Michael
 
 On Thu, May 21, 2015 at 10:14 AM, Robert Collins
 robe...@robertcollins.net wrote:
  One is linked from https://wiki.openstack.org/wiki/Oslo#Review_Links
 
  On 22 May 2015 at 05:13, Michael Still mi...@stillhq.com wrote:
  Hi,
 
  I'm finding that oslo being in 1,400 different git repos is making it
  hard to build a gerrit review dashboard URL. Does anyone have one of
  these already built that I can just steal?
 
  Thanks,
  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
 
 
 
  --
  Robert Collins rbtcoll...@hp.com
  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
 

__
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][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Fox, Kevin M

If thats true, then it could probably be changed and a note placed in the 
release/migration notes.

Thanks,
Kevin

From: Chris Friesen
Sent: Thursday, May 21, 2015 4:18:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova][libvirt] Understand why we lookup libvirt 
domains by instance name

On 05/21/2015 03:42 PM, Mathieu Gagné wrote:
 On 2015-05-21 3:38 PM, Chris Friesen wrote:
 On 05/21/2015 03:20 PM, Mathieu Gagné wrote:
 On 2015-05-21 3:13 AM, Daniel P. Berrange wrote:
 You do know you can configure the instance name used...

 eg in nova.conf

 instance_name_template='inst-%(uuid)s'

 Please note that you CANNOT change instance_name_template ones instances
 are created otherwise they become unmanageable by Nova. This is because
 Nova tries to find the libvirt instance by its name instead of its UUID.
 So since instances were spawned with the old value, it won't find
 existing instances using the new value.

 And no, I haven't found a way to rename an instance without
 redefining/restarting it in libvirt.

 Is there any reason why we couldn't default to using something like
 'inst-%(uuid)s' for the instance name?

 I guess it's for the reason I mentioned above:

 To not break all OpenStack installations on Earth running with default
 config values.

So that's not breaking *upgrades* of all OpenStack installations with default
config values, which is a slightly different thing.

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 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] [barbican] Nominating Kaitlin Farr for barbican-core

2015-05-21 Thread Nathan Reller

+1

On Thu, May 21, 2015 at 12:29 PM, John Wood john.w...@rackspace.com wrote:
 +1
 
 From: Douglas Mendizábal douglas.mendiza...@rackspace.com
 Sent: Tuesday, May 19, 2015 7:09 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [barbican] Nominating Kaitlin Farr for barbican-core

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Hi All,

 I would like to nominate Kaitlin Farr for barbican-core.

 Kaitlin has been contributing to the project for a long time, both by
 contributing code to Barbican, python-barbicanclient and Castellan,
 and also by providing valuable reviews. [1]

 As a reminder to the rest of the core team, we use the process
 outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
 members to the barbican-core team.

 Thanks,
 Douglas Mendizábal

 [1] http://stackalytics.com/report/contribution/barbican-group/90
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIcBAEBCgAGBQJVW9CgAAoJEB7Z2EQgmLX7u6kP/22G3NqsnJmKRsnw065btt8z
 /Sb7OqFa2RKuIKk88a9yehwRuunh2YCdfLmXta1+XXpucghG9dbflfFVGU4/VujX
 VG/B3yUXTBYT2kn72mtwpKk4S6mYXBPn+fpKGR7iJrifYSg55XO7a2c2m/xIC8pO
 R9+d5/8ZztxS1UbmhNuqLwBDpo9FIG+5CoWOfYPTAQ1TxB/SIs2ltk4jzLaU05yb
 5LTG3uq5K3CT+LvM3Rl6SCZ7bIiTmaTuPsXMnqqLiqhya90U63VJGGXUE1yjW11G
 Kgm7yxUV8DkcESHXEe0aW8hpLMuGKda/f83XetGN27+YpM3/G1z8N656zLX9sF3t
 oVU7dWnARn9NsByFP9ASg8BCk8iWr/mCeB/fajwXT95C+OXAicNWn5jXKowXQhQH
 v4XaFrjafROLdJocgH0mfcoEbTXZXlsKyHYtnZdwAO+T06RNd21c/lnNiG1rMYeh
 2Yl48nzxxx33YprizHDRMEhABIb11HO040+j+EHNCvbsGSJGZIZmzzbxNe2QGXkx
 q++JvMBW60pPd6pi7nEVjbjSEZhb6f6xHs13/y+nZ9NCSNkUPx1UoxKz18JRtrLi
 /XDZLv6D92Trlaxae9mpVlWTM1elYPWSm3QVMxMrSP9wtAYbUIoq0PN+WwKk/1J7
 WaeQpFjA1SdFHj5uPNZk
 =1OIW
 -END 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

 __
 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] [Barbican] Nominating Chelsea Winfree for Barbican core

2015-05-21 Thread Nathan Reller

+1

On Thu, May 21, 2015 at 4:53 PM, Juan Antonio Osorio
jaosor...@gmail.com wrote:
 +1

 On Thu, May 21, 2015 at 11:05 PM, John Wood john.w...@rackspace.com wrote:

 +1

 
 From: Chad Lung chad.l...@gmail.com
 Sent: Sunday, May 17, 2015 6:34 PM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Barbican] Nominating Chelsea Winfree for
 Barbican core

 Hi all,

 I'd like to nominate Chelsea Winfree for the Barbican core review team.

 Chelsea has been active in Barbican as a regular contributor of code and
 helping always needed documentation.
 http://stackalytics.com/?user_id=chelsea-winfreerelease=all

 As a reminder to barbican-core members we use the voting process outlined
 in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
 team.

 Thanks,

 Chad Lung
 EMC Cloud Services



 __
 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




 --
 Juan Antonio Osorio R.
 e-mail: jaosor...@gmail.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


__
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][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Chris Friesen


On 05/21/2015 03:42 PM, Mathieu Gagné wrote:

On 2015-05-21 3:38 PM, Chris Friesen wrote:

On 05/21/2015 03:20 PM, Mathieu Gagné wrote:

On 2015-05-21 3:13 AM, Daniel P. Berrange wrote:

You do know you can configure the instance name used...

eg in nova.conf

instance_name_template='inst-%(uuid)s'



Please note that you CANNOT change instance_name_template ones instances
are created otherwise they become unmanageable by Nova. This is because
Nova tries to find the libvirt instance by its name instead of its UUID.
So since instances were spawned with the old value, it won't find
existing instances using the new value.

And no, I haven't found a way to rename an instance without
redefining/restarting it in libvirt.


Is there any reason why we couldn't default to using something like
'inst-%(uuid)s' for the instance name?



I guess it's for the reason I mentioned above:

To not break all OpenStack installations on Earth running with default
config values.



So that's not breaking *upgrades* of all OpenStack installations with default 
config values, which is a slightly different thing.


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

Re: [openstack-dev] [Oslo] Review dashboard for oslo?

Oh cool. Thanks!

Michael

On Thu, May 21, 2015 at 10:14 AM, Robert Collins
robe...@robertcollins.net wrote:
 One is linked from https://wiki.openstack.org/wiki/Oslo#Review_Links

 On 22 May 2015 at 05:13, Michael Still mi...@stillhq.com wrote:
 Hi,

 I'm finding that oslo being in 1,400 different git repos is making it
 hard to build a gerrit review dashboard URL. Does anyone have one of
 these already built that I can just steal?

 Thanks,
 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



 --
 Robert Collins rbtcoll...@hp.com
 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

Re: [openstack-dev] [Nova][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Mathieu Gagné

On 2015-05-21 4:18 PM, Chris Friesen wrote:


 I guess it's for the reason I mentioned above:

 To not break all OpenStack installations on Earth running with default
 config values.

 
 So that's not breaking *upgrades* of all OpenStack installations with
 default config values, which is a slightly different thing.
 

Yes it will. Try to change instance_template_name and manage existing
instances. You won't be able.

The above scenario is the same as upgrading OpenStack Nova and having
instance_template_name changes its default value. Unless someone patches
Nova to use the instance UUID instead of its name to find it in libvirt.

-- 
Mathieu

__
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][heat] sqlalchemy-migrate tool to alembic

On 5/21/15 3:36 PM, Mike Bayer wrote:

On 5/21/15 2:57 PM, Mike Bayer wrote:

On 5/21/15 2:50 PM, Mike Bayer wrote:

Put another way, if I want to do a migration that someday, over
time, eventually, etc., will drop the widget_status table and
merge it into the widget table, how do I write the get_widget()
DB API call ? Same for just dropping a column. If we have to
write code that will return the value of the old table / old column
while it exists, how does that part work? Somewhere, there has to
be code that in one case says: query(Widget).join(WidgetStatus)
and in other case says query(Widget). You have to maintain
*both* SQL queries at the same time?
OK I guess it is this: Kilo queries Widget JOIN WidgetStatus while
Liberty queries just Widget - e.g. the two versions of the query are
just in two different releases of the application. You need to run
exclusively the old sqlalchemy/api.py version of the code before
contract is run, that is, the new API / nova.objects runs against
the old model code.

OK! let me chew on that.

A side-channel convo with Jay confirms that he had all these same
questions / confusion as well - somewhere, his confusion was cleared
up, though I don't know where that is. Might this be a really good
reason for this architecture to somewhere be documented really, really
completely and thoroughly, with detailed workflow examples and such?
If that's been done, can someone link me please?

Here's that link, from way up in this thread:

http://docs.openstack.org/developer/nova/devref/upgrade.html

To the degree that people can help me get on board with how they are
architecting these things only makes things better, because I'll be
giving out consistent advice and information to people asking me
things. I know I am asking for special treatment, but because I
maintain the upstream libraries that the work here depends highly on, it
makes my job a *ton* easier if folks help to keep me in the loop.

Reading in the example here:
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html#proposed-change

This is the part I'm still unclear on:

The database migration for this change will simply add the new column,
but not perform a data migration. Instead, the migration from
system_metadata to instance_extra will be managed by the objects layer.
The objects code will handle honoring the system_metadata flavor data,
if present, otherwise using the new format in instance_extra.

How do we write the database access code for this ? Using ORM-mapped
objects, it implies you have an object that has both the system_metadata
and instance_extra columns on it at the same time. When you run
contract and system_metadata is dropped, that mapping will fail.
I'm looking through all the patches at
https://blueprints.launchpad.net/nova/+spec/flavor-from-sysmeta-to-blob
and I'm not seeing where this part happens. From everything I've read
today, the data migration between versions A and B is still seeming like
the key friction point, and while it appears to have a well-defined
place, I need to be involved with these friction points - Nova's
database access code has a lot of issues I've been trying to work to
improve (poor performance, transaction boundaries all over the place,
lots of boilerplate), and this seems like a new aspect of it that I'd
need to take into account.

Can I please have help understanding this? 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] [Neutron][Magnum] Container + OpenStack Integration

2015-05-21 Thread Antoni Segura Puimedon

On Thu, May 21, 2015 at 8:04 AM, Fox, Kevin M kevin@pnnl.gov wrote:

  Since docker 1.7 is suposed to support advanced networking, could that
 just be plugged into neutron?


Yes, we'd be looking at doing a docker libnetwork driver that uses the
remote driver interface.

The remote driver would request the ports/networks to neutron and then use
that information and the port type to plug the port into the container in
the appropriate way.



 Thanks,
 Kevin

 --
 *From:* Brenden Blanco
 *Sent:* Thursday, May 21, 2015 6:40:37 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron][Magnum] Container + OpenStack
 Integration

  Hi,

  Just brainstorming here, but IMHO it would be good to keep it extensible
 and not to lock in VLAN as the sole container VIF mechanism. For
 instance, there is the ipvlan [1] technology that was purpose-built to be
 more appropriate for container systems. This tech actually comes from some
 of the Google folks that deploy containers at scale, if my memory serves
 correctly. So, we may want to start with VLAN as the reference
 implementation but should leave it open to try out an alternative such as
 the above in the near future. Perhaps in practice this implies that the vid
 field of the neutron side isn't strictly an int field, not sure.

  Cheers,
 Brenden Blanco

  [1] https://lwn.net/Articles/620087/

 On Wed, May 20, 2015 at 11:21 PM, Kevin Benton blak...@gmail.com wrote:

 Hi,

 I wasn't able to make it to the session but from the etherpad I saw
 that the VLAN-aware VMs mentioned there. Would that be enough to cover
 this particular use-case?

 On Wed, May 20, 2015 at 3:28 AM, Adrian Otto adrian.o...@rackspace.com
 wrote:
  Magnum and Neutron Teams,
 
  If you are in Vancouver today and can help design or implement native
  networking support to obviate the need for overlay networks when using
  containers, please join this design session:
 
  http://sched.co/3CjK (3:30 PM, Room 303)
 
  This will be based on feedback gathered at the Fishbowl session earlier
 in
  the day: http://sched.co/3B0z (11:00 AM, Room 306)
 
  Thanks,
 
  Adrian
 
 
 __
  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
 



 --
 Kevin Benton

 __
 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] [neutron][vpnaas] Etherpad for Friday Neutron Contributors' session

2015-05-21 Thread Paul Michali

I created an etherpad to help focus the discussion. We'll try to form a
collective in the morning and start talking through these items.

https://etherpad.openstack.org/p/YVR-neutron-vpnaas

Regards,

Paul Michali (pc_m)
__
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] [Manila] Question to driver maintainers

2015-05-21 Thread Jason Bishop

Hi Igor, Hitachi SOP drive can support share extending online without
disruption.

cheers
jason


On Mon, May 18, 2015 at 1:15 AM, Igor Malinovskiy imalinovs...@mirantis.com
 wrote:

 Hello, everyone!

 My letter is mainly addressed to driver maintainers, but could be
 interesting to everybody.

 As you probably know, on Kilo midcycle meetup we discussed share resize
 functionality (extend and shrink) and I already have implemented 'extend'
 API in Generic driver (https://review.openstack.org/182383/). After
 implementation review we

 noticed that some backends are able to resize a share without causing
 disruptions, but others might only be able to do it disruptively (Generic
 driver case).

 So I want to ask driver maintainers here:

 Will your driver be able to do share extending without loss of
 connectivity?

 Depending on your answers, we will handle this situation differently.

 Best regards,

 Igor Malinovskiy (IRC: u_glide)
 Manila Core Team

 __
 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] [trove][zaqar] Trove and Zaqar integration. Summit working session

2015-05-21 Thread Li Tianqing

Is it the discussion live? I am not in vancouver...  




--

Best
Li Tianqing

At 2015-05-21 04:18:13, Nikhil Manchanda nik...@manchanda.me wrote:

The session where we're planning to discuss this is at 5:00 pm on Thursday in 
Room 302.


Thanks,
Nikhil



On May 20, 2015, at 11:09 AM, Georgy Okrokvertskhov 
gokrokvertsk...@mirantis.com wrote:


I think Sergey will present Murano team. I added him to CC as he probably 
filters out Zaqar and Trove e-mails.


Thanks
Gosha


On Wed, May 20, 2015 at 10:34 AM, Georgy Okrokvertskhov 
gokrokvertsk...@mirantis.com wrote:

Hi,


What is the final decision about this discussion? When will it happen?


thanks
Gosha


On Thu, May 14, 2015 at 3:49 PM, Douglas Mendizábal 
douglas.mendiza...@rackspace.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm very much interested in talking with some Keystone folks about
this auth issue.  I would be willing to dedicate a Barbican Working
Session to this discussion if there is a time slot that works for all
the interested parties.

- - Douglas Mendizabal


On 5/14/15 3:13 PM, Fox, Kevin M wrote:
 If there's a free session, can we dedicate a session specifically
 to the zaqar, barbican, sahara, heat, trove, guestagent, keystone
 auth thingy so everyone's all together?

 Thanks, Kevin  From: Flavio
 Percoco [fla...@redhat.com] Sent: Thursday, May 14, 2015 12:15 PM
 To: Sergey Lukjanov Cc: OpenStack Development Mailing List (not for
 usage questions) Subject: Re: [openstack-dev] [trove][zaqar] Trove
 and Zaqar integration. Summit working session

 On 14/05/15 10:07 -0700, Sergey Lukjanov wrote:
 Hey,

 in Sahara we're looking on using Zaqar as a transport for agent
 some day as well. Unfortunately this section overlaps with Sahara
 sessions.

 Sergey,

 We still have some free sessions, we'd be happy to dedicate one to
 Sahara. Any slot that looks good for you?

 http://libertydesignsummit.sched.org/overview/type/design+summit/Zaqar
#.VVT0CvYU9hE

  Thanks, Flavio


 On Thu, May 14, 2015 at 12:19 AM, Flavio Percoco
 fla...@redhat.com wrote:

 On 13/05/15 18:06 +, Fox, Kevin M wrote:

 Sahara also has the same problem, but worse, since they currently
 only support ssh with their agent, so its either assign floating
 ip's to all nodes, or your sahara controller must be on your one
 and only network node so it can tunnel. :/

 Should we have a chat with them too?


 We've scheduled a discussion with Trove's team on Thursday at
 5pm. It'd be great to have this discussion once and together to
 know what the common issues are and what things need to be done.

 I'll ping folks from both teams to invite them to this session.
 If they can't make it, I'm happy to use another working session
 slot.

 Cheers, Flavio

 http://libertydesignsummit.sched.org/event/59dc6ec910a732cdbf5970b679
2e1cef


#.VVRL0PYU9hE




 Thanks, Kevin  From: Zane
 Bitter [zbit...@redhat.com] Sent: Wednesday, May 13, 2015 10:26
 AM To: openstack-dev@lists.openstack.org Subject: Re:
 [openstack-dev] [trove][zaqar] Trove and Zaqar integration.
 Summit working session

 On 11/05/15 05:49, Flavio Percoco wrote:

 On 08/05/15 00:45 -0700, Nikhil Manchanda wrote:

 3)  The trove-guest-agent is in vm. it is connected by
 taskmanager by rabbitmq. We designed it. But is there some
 prectise to do this? how to make the vm be connected in
 vm-network and management network?


 Most deployments of Trove that I am familiar with set up a
 separate RabbitMQ server in cloud that is used by Trove. It is
 not recommended to use the same infrastructure RabbitMQ server
 for Trove for security reasons. Also most deployments of Trove
 set up a private (neutron) network that the RabbitMQ server and
 guests are connected to, and all RPC messages are sent over this
 network.


 We've discussed trove+zaqar in the past and I believe some folks
 from the Trove team have been in contact with Fei Long lately
 about this. Since one of the projects goal's for this cycle is to
 provide support to other projects and contribute to the adoption,
 I'm wondering if any of the members of the trove team would be
 willing to participate in a Zaqar working session completely
 dedicated to this integration?


 +1

 I learned from a concurrent thread ([Murano] [Mistral] SSH
 workflow action) that Murano are doing exactly the same thing
 with a separate RabbitMQ server to communicate with guest agents.
 It's a real waste of energy when multiple OpenStack projects all
 have to solve the same problem from scratch, so a single answer
 to this would be great.

 In that thread I suggested (and Murano developers agreed with)
 making the transport pluggable so that operators could choose
 Zaqar instead. I would strongly support doing the same here.


 +1 :)

 Flavio




 cheers, Zane.


 It'd be a great opportunity to figure out what's really needed,
 edge cases and get some work done on this specific case.

 Thanks,

[openstack-dev] [nova] Does Nova has a command line to restart an instance?

2015-05-21 Thread Lily.Sing

Hi experts,

I setup an OpenStack multinode environment without Horizon installed. After
host rebooting, the instances are in 'shutoff' status. I hope to re-use
these instances, but seems there is no command line for this. Any
suggestion?

Thanks.

Best regards,
Lily Xing(邢莉莉)
__
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] Does Nova has a command line to restart an instance?

2015-05-21 Thread Fei Long Wang


Did you try 'nova start server'?

On 22/05/15 16:16, Lily.Sing wrote:

Hi experts,

I setup an OpenStack multinode environment without Horizon installed. 
After host rebooting, the instances are in 'shutoff' status. I hope to 
re-use these instances, but seems there is no command line for this. 
Any suggestion?


Thanks.

Best regards,
Lily Xing(邢莉莉)


__
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


--
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] Does Nova has a command line to restart an instance?

2015-05-21 Thread Deepak Shetty

nova start existing instance name or uuid

On Fri, May 22, 2015 at 9:46 AM, Lily.Sing lily.s...@gmail.com wrote:

 Hi experts,

 I setup an OpenStack multinode environment without Horizon installed.
 After host rebooting, the instances are in 'shutoff' status. I hope to
 re-use these instances, but seems there is no command line for this. Any
 suggestion?

 Thanks.

 Best regards,
 Lily Xing(邢莉莉)

 __
 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][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Deepak Shetty

On Fri, May 22, 2015 at 5:19 AM, Mathieu Gagné mga...@iweb.com wrote:

 On 2015-05-21 4:18 PM, Chris Friesen wrote:
 
 
  I guess it's for the reason I mentioned above:
 
  To not break all OpenStack installations on Earth running with default
  config values.
 
 
  So that's not breaking *upgrades* of all OpenStack installations with
  default config values, which is a slightly different thing.
 

 Yes it will. Try to change instance_template_name and manage existing
 instances. You won't be able.

 The above scenario is the same as upgrading OpenStack Nova and having
 instance_template_name changes its default value. Unless someone patches
 Nova to use the instance UUID instead of its name to find it in libvirt.


Novice question:
   For each instance I believe we store the name (instance-xx) and uuid
in
the DB ? If yes, then can't nova lookup using uuid given the name or vice
versa
since the mapping to name - uuid is possible from DB ?



 --
 Mathieu

 __
 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] Does Nova has a command line to restart an instance?

2015-05-21 Thread Chet Burgess

If you add the following option to your nova.conf file then when nova-compute 
restarts (at boot or simple on a restart) it will check the instances in the DB 
and attempt to start any instances that are marked as running in the DB but not 
running on the hypervisor.

resume_guests_state_on_host_boot=True

 On May 21, 2015, at 21:16, Lily.Sing lily.s...@gmail.com wrote:
 
 Hi experts,
 
 I setup an OpenStack multinode environment without Horizon installed. After 
 host rebooting, the instances are in 'shutoff' status. I hope to re-use these 
 instances, but seems there is no command line for this. Any suggestion?
 
 Thanks.
 
 Best regards,
 Lily Xing(邢莉莉)
 __
 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] Resigning as StoryBoard-Core

2015-05-21 Thread Michael Krotscheck

Hey everyone!

As many of you know, storyboard's been on a bit of a back burner recently,
largely because members of the TC have acknowledged that the project was
never properly resourced, and therefore have reversed their opinion on
whether we should be trying to build our own task tracker that meets
OpenStack's needs.

The discussion of whether to continue working on StoryBoard, and what to
replace it with, had similarly been halted, with me being told explicitly
that a decision would be made in Vancouver.

The session during which the decision was to be made just concluded, and
the decision was to continue maintaining StoryBoard in a Status Quo mode
until we can evaluate alternatives. These alternatives had been under
evaluation since April. In short, the future of StoryBoard continues to
remain uncertain, and I, as sole remaining active contributor, am again
left hanging.

I am resigning, effective immediately, as StoryBoard Core, and will no
longer contribute to the project. This moves the number of active
contributors to the project to zero, effectively killing it. I also propose
that storyboard, storyboard-webclient, and puppet-storyboard are
immediately moved to the attic, as without contributors, there is no real
narrative in which it could continue to live on its own.

Now that StoryBoard is no longer a viable alternative in the Task Tracking
discussion, I trust that the TC and Infra team will come to a quick
resolution on the topic.

Michael
__
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][heat] sqlalchemy-migrate tool to alembic




On 5/21/15 2:57 PM, Mike Bayer wrote:



On 5/21/15 2:50 PM, Mike Bayer wrote:


Put another way, if I want to do a migration that someday, over 
time, eventually, etc., will drop the widget_status table and 
merge it into the widget table, how do I write the get_widget() 
DB API call ? Same for just dropping a column.   If we have to 
write code that will return the value of the old table / old column 
while it exists, how does that part work?   Somewhere, there has to 
be code that in one case says: query(Widget).join(WidgetStatus) and 
in other case says query(Widget).   You have to maintain *both* SQL 
queries at the same time?
OK I guess it is this: Kilo queries Widget JOIN WidgetStatus while 
Liberty queries just Widget - e.g. the two versions of the query are 
just in two different releases of the application. You need to run 
exclusively the old sqlalchemy/api.py version of the code before 
contract is run, that is, the new API / nova.objects runs against 
the old model code.


OK!   let me chew on that.

hmm, still not grokking this.


Kilo application has:

query(Widget).join(WidgetStatus)  # for queries, and:

session.add(Widget)
session.add(WidgetStatus) # for persistence.

It has no knowledge that Widget and WidgetStatus are merged.  Or does 
it?  (in which case, yuk?)


Liberty application has:

query(Widget)  # for queries, and:

session.add(Widget) # for persistence.


It has no knowledge that WidgetStatus exists.  Or does it?  (in which 
case, yuk?)


It seems like the two possibilities are that either a database API 
somewhere needs to know of both endpoint states of the schema, or the 
oslo.objects API needs to ensure that it communicates data across two 
different versions of the SQL API at the same time in order to do data 
migrations. Either way I don't know how that works.


My concern that given a series of migrations A, B, C, D, and E, the 
states of B, C and D *do* disappear as new states are added, is true.   
It's just that the data migrations here are not simplistic scripts but 
are instead embedded into the oslo.objects and possibly the model 
objects as well, and these must be maintained as new states are added to 
accommodate the new reality of the schema from a POV of only the 
previous major release to the next major release.


I understand that this is all towards the notion that an operator can 
have dozens of apps hitting the same database and all those apps are in 
a mixture of Kilo / Liberty and all work the same.   That is a hard 
problem to solve.I only regret that I haven't had the opportunity to 
put any thinking of my own into this problem; while it was part of my 
original mandate starting work at Red Hat, the versioned objects 
approach was already moving 100 miles an hour from my first day on the 
job and this is not a train I've been able to catch.   I'm really hoping 
to be involved with it, as it is my job, though each time I attempt to 
go there it feels a bit impenetrable.


A side-channel convo with Jay confirms that he had all these same 
questions / confusion as well - somewhere, his confusion was cleared up, 
though I don't know where that is.   Might this be a really good reason 
for this architecture to somewhere be documented really, really 
completely and thoroughly, with detailed workflow examples and such?  If 
that's been done, can someone link me please?













__
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] Stepping down from Neutron core team

2015-05-21 Thread Gary Kotton

-1

From: Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 21, 2015 at 11:32 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Stepping down from Neutron core team

On May 21, 2015 9:06 AM, Kyle Mestery 
mest...@mestery.commailto:mest...@mestery.com wrote:

 On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando 
 sorla...@nicira.commailto:sorla...@nicira.com wrote:

 After putting the whole OpenStack networking contributors community through 
 almost 8 cycles of pedant comments and annoying what if questions, it is 
 probably time for me to relieve neutron contributors from this burden.

 It has been a pleasure for me serving the Neutron community (or Quantum as 
 it was called at the time), and now it feel right - and probably overdue - 
 to relinquish my position as a core team member in a spirit of rotation and 
 alternation between contributors.

 Note: Before you uncork your champagne bottles, please be aware that I will 
 stay in the Neutron community as a contributors and I might still end up 
 reviewing patches.

 Thanks for being so understanding with my pedant remarks,
 Salvatore

 If I could -1 this as a patch, I would.

 But seriously. Salvatore, thanks for all the years of work you've put into 
 Neutron. Please note that just because you've stepped down from the core 
 reviewer team doesn't mean we won't be relying on you to be a part of the 
 community.

 Thanks,
 Kyle

Kyle, I think you should -2 this one.  ;)  Maybe we should put the core team 
list in a repo just so you can.

All joking aside, @Salv, I have appreciated your feedback much more than you 
give yourself credit for, maybe more than I let on.  You don't need to be a 
core to give it, so keep it coming.

Carl
__
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] Stepping down from Neutron core team

2015-05-21 Thread Salvatore Orlando

After putting the whole OpenStack networking contributors community through
almost 8 cycles of pedant comments and annoying what if questions, it is
probably time for me to relieve neutron contributors from this burden.

It has been a pleasure for me serving the Neutron community (or Quantum as
it was called at the time), and now it feel right - and probably overdue -
to relinquish my position as a core team member in a spirit of rotation and
alternation between contributors.

Note: Before you uncork your champagne bottles, please be aware that I will
stay in the Neutron community as a contributors and I might still end up
reviewing patches.

Thanks for being so understanding with my pedant remarks,
Salvatore
__
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] [release] Kilo EL7 and Juno EL6 repos available from CentOS Cloud SIG

2015-05-21 Thread Rich Bowen

The CentOS Cloud SIG is pleased to announce the availability of 
OpenStack Kilo package repositories for CentOS 7, and Juno repositories 
for CentOS 6. These are the result of the last few months of work by the 
Cloud SIG membership, and, of course, we owe a great deal of gratitude 
to the upstream OpenStack community as well.


The CentOS 7 Kilo repository may be found at 
http://mirror.centos.org/centos/7/cloud/x86_64/


The Juno CentOS 6 repository may be found at 
http://mirror.centos.org/centos/6/cloud/x86_64/


The actual -release files will reside in Extras, so that you can yum 
install centos-release-openstack-kilo for Kilo and yum install 
centos-release-openstack-juno for Juno, without needing to mess with 
repo configurations.


See also the Juno EL6 RDO QuickStart at 
http://wiki.centos.org/Cloud/OpenStack/JunoEL6QuickStart


CentOS cares about OpenStack. We test all of our cloud images against 
OpenStack, in the CentOS 5, 6, and 7 branches. The CentOS Cloud SIG is 
very keen on facilitating community efforts at CentOS, and we have 
resources available for CI, repos, and other needs, which the community 
can use. We welcome your participation in this effort. We're dedicated 
to ensuring that CentOS is a solid, dependable platform for deploying 
OpenStack, and that all versions of OpenStack are thoroughly tested 
against CentOS, and vice versa.


You can find out more about the CentOS Cloud SIG, and how to get 
involved, at http://wiki.centos.org/SpecialInterestGroup/Cloud and about 
the RDO project at http://rdoproject.org/


--
Rich Bowen - rbo...@redhat.com
http://rdoproject.org/

__
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] Stepping down from Neutron core team

2015-05-21 Thread Kyle Mestery

On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando sorla...@nicira.com
wrote:

 After putting the whole OpenStack networking contributors community
 through almost 8 cycles of pedant comments and annoying what if
 questions, it is probably time for me to relieve neutron contributors from
 this burden.

 It has been a pleasure for me serving the Neutron community (or Quantum as
 it was called at the time), and now it feel right - and probably overdue -
 to relinquish my position as a core team member in a spirit of rotation and
 alternation between contributors.

 Note: Before you uncork your champagne bottles, please be aware that I
 will stay in the Neutron community as a contributors and I might still end
 up reviewing patches.

 Thanks for being so understanding with my pedant remarks,
 Salvatore


If I could -1 this as a patch, I would.

But seriously. Salvatore, thanks for all the years of work you've put into
Neutron. Please note that just because you've stepped down from the core
reviewer team doesn't mean we won't be relying on you to be a part of the
community.

Thanks,
Kyle


 __
 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] [barbican] regarding certificate generation

2015-05-21 Thread Ganesh Narayanan (ganeshna)

Hi,

I am running devstack on Ubuntu as a virtual machine.  Please let me know how 
do I enable dogtag and symantec plugins for certificates.  Should I enable them 
in local.conf of devstack ?  I see the below check for BARBICAN_USE_DOGTAG, but 
not sure what option I should enable for this.

Also to use dogtag CA, should I be running devstack on Fedora instead of Ubuntu 
for local development ?

devstack/extras.d/70-barbican.sh:

elif [[ $1 == stack  $2 == post-config ]]; then
echo_summary Configuring Barbican
configure_barbican
if [[ -n $BARBICAN_USE_DOGTAG ]]; then  
configure_dogtag_plugin
Fi

CA Plugins installed


curl  -H 'content-type:application/json' -H 
X-Auth-Token:ea0454c4e1b9404c8405c20f4a54c390 http://localhost:9311/v1/cas/
{cas: [http://localhost:9311/v1/cas/c1ca4ea6-0b93-47aa-90ed-a52352e67468;], 
total: 1}

curl  -H 'content-type:application/json' -H 
X-Auth-Token:ea0454c4e1b9404c8405c20f4a54c390 
http://localhost:9311/v1/cas/c1ca4ea6-0b93-47aa-90ed-a52352e67468
{status: ACTIVE, updated: 2015-05-21T16:27:04, created: 
2015-05-21T16:27:04, plugin_name: 
barbican.plugin.simple_certificate_manager.SimpleCertificatePlugin, meta: 
[{ca_signing_cert: X}, {intermediates: 
}, {name: Simple CA}, {description: Certificate 
Authority - Simple CA}], ca_id: c1ca4ea6-0b93-47aa-90ed-a52352e67468, 
plugin_ca_id: Simple CA, expiration: 2015-05-22T16:27:04”}


Certificate creation request
===

With the default CA, if I try to generate certificate, it stays in the Pending 
state:

test@ubuntu:~/devstack$
test@ubuntu:~/devstack$ curl -X POST -H 'content-type:application/json' -H 
X-Auth-Token:6df4ccb04575456cbd284eee99afa9eb 
-d'{type:certificate,meta:{profile_id:caServCert,cert_request_type:pkcs10,cert_request:MII}}'
 http://localhost:9311/v1/orders/
{order_ref: 
http://localhost:9311/v1/orders/6ec10fb0-c4b4-418f-8d56-af48a85c1e7f”}


test@ubuntu:~/devstack$
test@ubuntu:~/devstack$ curl -H X-Auth-Token:488903bb6dbf4cd3a10f2eb10a7e54e0 
http://localhost:9311/v1/orders/6ec10fb0-c4b4-418f-8d56-af48a85c1e7f
{status: PENDING, sub_status: cert_request_pending, updated: 
2015-05-21T16:44:28, created: 2015-05-21T16:44:28, order_ref: 
http://localhost:9311/v1/orders/6ec10fb0-c4b4-418f-8d56-af48a85c1e7f;, 
creator_id: 992f4bb2499a473d9e40dc44dc9633ed, meta: {profile_id: 
caServCert, cert_request: MII, cert_request_type: pkcs10}, 
sub_status_message: Request has been submitted to the CA.  Waiting for 
certificate to be generated, type: certificate}test@ubuntu:~/devstack$

Links that I referred
=
https://wiki.openstack.org/wiki/BarbicanDevStack

Thanks,
Ganesh


__
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] [pbr] 1.0.1 released

On 21 May 2015 at 16:30, fumihiko kakuma kak...@valinux.co.jp wrote:
 Hi openstack-dev team,

 Can you also release latest oslo.config to allow pbr 1.0.1?
 In my convenience I want to use it.

Hi, we've got a day tomorrow where we're going to try and figure out
the future management of requirements in library packages (amongst
many other things) - I've advised olso-release to ignore the pbr  1.0
issue for a little bit, so maybe we can see if other dep changes are
needed at the same time.

But yes, there are many things that need to release with the broadened
pbr requirements to become fully resolvable. You can force this by pip
install -U pbr after your things are installed.

-Rob


-- 
Robert Collins rbtcoll...@hp.com
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] [pbr] 1.0.1 released

On 21 May 2015 at 21:22, YAMAMOTO Takashi yamam...@valinux.co.jp wrote:
 hi,

 can you explain why you want to use pbr 1.0.1 in the first place?
 what's wrong with requiring pbr1.0 ?

pbr 1.0 adds important features for python 2.x  3.x management and
optional dependencies via extras.

-Rob


-- 
Robert Collins rbtcoll...@hp.com
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] [Neutron] Stepping down from Neutron core team

2015-05-21 Thread Doug Wiegley


 On May 21, 2015, at 9:14 AM, Armando M. arma...@gmail.com wrote:
 
 
 
 On 21 May 2015 at 08:58, Salvatore Orlando sorla...@nicira.com 
 mailto:sorla...@nicira.com wrote:
 After putting the whole OpenStack networking contributors community through 
 almost 8 cycles of pedant comments and annoying what if questions, it is 
 probably time for me to relieve neutron contributors from this burden.
 
 It has been a pleasure for me serving the Neutron community (or Quantum as it 
 was called at the time), and now it feel right - and probably overdue - to 
 relinquish my position as a core team member in a spirit of rotation and 
 alternation between contributors.
 
 Note: Before you uncork your champagne bottles, please be aware that I will 
 stay in the Neutron community as a contributors and I might still end up 
 reviewing patches.
 
 Thanks for being so understanding with my pedant remarks,
 Salvatore
 
 +1

+2

  
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 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] [Neutron] Stepping down from Neutron core team

2015-05-21 Thread Kyle Mestery

On Thu, May 21, 2015 at 9:51 AM, Doug Wiegley doug...@parksidesoftware.com
wrote:


 On May 21, 2015, at 9:14 AM, Armando M. arma...@gmail.com wrote:



 On 21 May 2015 at 08:58, Salvatore Orlando sorla...@nicira.com wrote:

 After putting the whole OpenStack networking contributors community
 through almost 8 cycles of pedant comments and annoying what if
 questions, it is probably time for me to relieve neutron contributors from
 this burden.

 It has been a pleasure for me serving the Neutron community (or Quantum
 as it was called at the time), and now it feel right - and probably overdue
 - to relinquish my position as a core team member in a spirit of rotation
 and alternation between contributors.

 Note: Before you uncork your champagne bottles, please be aware that I
 will stay in the Neutron community as a contributors and I might still end
 up reviewing patches.

 Thanks for being so understanding with my pedant remarks,
 Salvatore


 +1


 +2


+2





 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://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][heat] sqlalchemy-migrate tool to alembic

2015-05-21 Thread Dan Smith

Here's the big thing that you're missing: no data migrations are allowed
any more in DB migration scripts.

Correct, online-schema-migrations aside, we're trying to avoid ever
doing data migrations in schema migrations anymore.

In this way, data migrations occur *over time* in the nova.objects
classes, and the contract phase can be delayed indefinitely until such a
point that the DBA has determined all data has been properly migrated.

Right. We just pivoted flavors from one place and format to another
place and format in kilo, and we did it without touching any data inside
the schema migration. Flavors get converted over time, but we also
provide a nova-manage command that allows pushing along instances that
aren't being touched. This allows the DBA to make sure that everything
gets migrated online before potentially running the contract phase (if
we had online migrations now). If this flavor thing ended up vacating a
column, we could drop that column in lemming and require all the online
migrations to be performed before we upgrade. That's precisely why we
landed this as our first lemming migration:

https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/migrate_repo/versions/291_enforce_flavors_migrated.py#L29-34

The flavor thing didn't actually, so we have nothing to drop, but in the
case of another change (like the example earlier in the thread) you do.

--Dan

signature.asc
Description: OpenPGP digital 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] [Neutron] Stepping down from Neutron core team

2015-05-21 Thread Armando M.

On 21 May 2015 at 09:58, Kyle Mestery mest...@mestery.com wrote:

 On Thu, May 21, 2015 at 9:51 AM, Doug Wiegley 
 doug...@parksidesoftware.com wrote:


 On May 21, 2015, at 9:14 AM, Armando M. arma...@gmail.com wrote:



 On 21 May 2015 at 08:58, Salvatore Orlando sorla...@nicira.com wrote:

 After putting the whole OpenStack networking contributors community
 through almost 8 cycles of pedant comments and annoying what if
 questions, it is probably time for me to relieve neutron contributors from
 this burden.

 It has been a pleasure for me serving the Neutron community (or Quantum
 as it was called at the time), and now it feel right - and probably overdue
 - to relinquish my position as a core team member in a spirit of rotation
 and alternation between contributors.

 Note: Before you uncork your champagne bottles, please be aware that I
 will stay in the Neutron community as a contributors and I might still end
 up reviewing patches.

 Thanks for being so understanding with my pedant remarks,
 Salvatore


 +1


 +2


 +2


+A








 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://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][libvirt] Understand why we lookup libvirt domains by instance name

On Thu, May 21, 2015 at 7:49 AM, Sahid Orentino Ferdjaoui
sahid.ferdja...@redhat.com wrote:
 On Thu, May 21, 2015 at 10:23:35AM +0100, Daniel P. Berrange wrote:
 On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote:
  I note that we use instance.name to lookup the libvirt domain a bunch
  in the driver. I'm wondering why we don't just use instance.uuid all
  the time -- the code for that already exists. Is there a good reason
  to not move to always using the uuid?
 
  I ask because instance.name is not guaranteed to be unique depending
  on how weird the nova deployment is.

 Agreed, there's no benefit to using name - internally libvirt will always
 prefer to use the UUID itself too.

 These days though, there is only a single place in nova libvirt driver
 that needs updating - the nova.virt.libvirt.host.Host class get_domain()
 method just needs to be switched to use uuid.

 I'm currently working on the libvirt driver I can add this in my TODO

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

Well, I am playing in this code to do some qemu stuff, so I will throw
something out in the next day or so anyways. If you beat me to it then
that's fine as well.

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] [Neutron] Stepping down from Neutron core team

2015-05-21 Thread Armando M.

On 21 May 2015 at 08:58, Salvatore Orlando sorla...@nicira.com wrote:

 After putting the whole OpenStack networking contributors community
 through almost 8 cycles of pedant comments and annoying what if
 questions, it is probably time for me to relieve neutron contributors from
 this burden.

 It has been a pleasure for me serving the Neutron community (or Quantum as
 it was called at the time), and now it feel right - and probably overdue -
 to relinquish my position as a core team member in a spirit of rotation and
 alternation between contributors.

 Note: Before you uncork your champagne bottles, please be aware that I
 will stay in the Neutron community as a contributors and I might still end
 up reviewing patches.

 Thanks for being so understanding with my pedant remarks,
 Salvatore


+1



 __
 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] [barbican] Nominating Kaitlin Farr for barbican-core

2015-05-21 Thread Paul Kehrer

+1 she has been an invaluable contributor.

 On May 19, 2015, at 5:09 PM, Douglas Mendizábal 
 douglas.mendiza...@rackspace.com wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Hi All,
 
 I would like to nominate Kaitlin Farr for barbican-core.
 
 Kaitlin has been contributing to the project for a long time, both by
 contributing code to Barbican, python-barbicanclient and Castellan,
 and also by providing valuable reviews. [1]
 
 As a reminder to the rest of the core team, we use the process
 outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
 members to the barbican-core team.
 
 Thanks,
 Douglas Mendizábal
 
 [1] http://stackalytics.com/report/contribution/barbican-group/90
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org
 
 iQIcBAEBCgAGBQJVW9CgAAoJEB7Z2EQgmLX7u6kP/22G3NqsnJmKRsnw065btt8z
 /Sb7OqFa2RKuIKk88a9yehwRuunh2YCdfLmXta1+XXpucghG9dbflfFVGU4/VujX
 VG/B3yUXTBYT2kn72mtwpKk4S6mYXBPn+fpKGR7iJrifYSg55XO7a2c2m/xIC8pO
 R9+d5/8ZztxS1UbmhNuqLwBDpo9FIG+5CoWOfYPTAQ1TxB/SIs2ltk4jzLaU05yb
 5LTG3uq5K3CT+LvM3Rl6SCZ7bIiTmaTuPsXMnqqLiqhya90U63VJGGXUE1yjW11G
 Kgm7yxUV8DkcESHXEe0aW8hpLMuGKda/f83XetGN27+YpM3/G1z8N656zLX9sF3t
 oVU7dWnARn9NsByFP9ASg8BCk8iWr/mCeB/fajwXT95C+OXAicNWn5jXKowXQhQH
 v4XaFrjafROLdJocgH0mfcoEbTXZXlsKyHYtnZdwAO+T06RNd21c/lnNiG1rMYeh
 2Yl48nzxxx33YprizHDRMEhABIb11HO040+j+EHNCvbsGSJGZIZmzzbxNe2QGXkx
 q++JvMBW60pPd6pi7nEVjbjSEZhb6f6xHs13/y+nZ9NCSNkUPx1UoxKz18JRtrLi
 /XDZLv6D92Trlaxae9mpVlWTM1elYPWSm3QVMxMrSP9wtAYbUIoq0PN+WwKk/1J7
 WaeQpFjA1SdFHj5uPNZk
 =1OIW
 -END 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

__
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] Stepping down from Neutron core team

2015-05-21 Thread Edgar Magana

Not even sure why I am even sending this email when I am behind you right now  
:-)

Probably to make sure that the rest of the folks know that your pedant remarks 
where so important to keep going the Quantum/Neutron project and even more 
important to have the right code in place.

Best Wishes!

Edgar

From: Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, May 21, 2015 at 8:58 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Stepping down from Neutron core team

After putting the whole OpenStack networking contributors community through 
almost 8 cycles of pedant comments and annoying what if questions, it is 
probably time for me to relieve neutron contributors from this burden.

It has been a pleasure for me serving the Neutron community (or Quantum as it 
was called at the time), and now it feel right - and probably overdue - to 
relinquish my position as a core team member in a spirit of rotation and 
alternation between contributors.

Note: Before you uncork your champagne bottles, please be aware that I will 
stay in the Neutron community as a contributors and I might still end up 
reviewing patches.

Thanks for being so understanding with my pedant remarks,
Salvatore
__
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] [Barbican] Nominating Chelsea Winfree for Barbican core

2015-05-21 Thread Paul Kehrer

+1

Chelsea has been jumping on all sorts of issues for us.

On May 17, 2015, at 4:34 PM, Chad Lung 
chad.l...@gmail.commailto:chad.l...@gmail.com wrote:

Hi all,

I'd like to nominate Chelsea Winfree for the Barbican core review team.

Chelsea has been active in Barbican as a regular contributor of code and 
helping always needed documentation. 
http://stackalytics.com/?user_id=chelsea-winfreerelease=all

As a reminder to barbican-core members we use the voting process outlined
in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
team.

Thanks,

Chad Lung
EMC Cloud Services


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto: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][heat] sqlalchemy-migrate tool to alembic

2015-05-21 Thread Jay Pipes


Hi Mike,

I had some initial concerns around the online db schema migration work 
as you do below. However, once I realized one big thing, those concerns 
were allayed.


Here's the big thing that you're missing: no data migrations are allowed 
any more in DB migration scripts.


Yes, that sounds exceedingly weird, I know, but hear me out in the 
comments inline... :) I've trimmed your original email for brevity.


On 05/20/2015 11:57 PM, Mike Bayer wrote:

But to illustrate, here's the kind of place that goes wrong in such a
way that is at best pretty annoying and at worst a serious and
error-prone development and testing headache.Let's start with a
hypothetical schema that has some design issues. Two tables widget
and widget_status, where widget_status has some kind of information
about a widget, and it also stores a timestamp, unfortunately as a
string:

CREATE TABLE widget (
 id INTEGER PRIMARY KEY,
 name VARCHAR(30) NOT NULL
)

CREATE TABLE widget_status (
widget_id INTEGER PRIMARY KEY REFERENCES widget(id),
status_flag INTEGER NOT NULL,
modified_date VARCHAR(30)
)

Let's say that two entirely different changes by two different
developers want to accomplish two things:  1. convert modified_date
into a new column modified_timestamp which is a DATETIME type, not a
string and 2. merge these two tables into one, as the need to JOIN all
the time is non-performant and unnecessary.   That is, we'll end up with
this:

CREATE TABLE widget (
 id INTEGER PRIMARY KEY,
 name VARCHAR(30) NOT NULL
status_flag INTEGER NOT NULL,
modified_timestamp DATETIME
)

Right off, let's keep in mind that when online schema migrations runs,
the fact that there's a #1 and a #2 migration to the schema is lost.


And this is where you're missing the important piece :) While it *is* 
true that the expand phase would combine the *DDL* schema migrations 
into just a final table structure as shown above, it is actually *not* 
true that the knowledge is lost of how the model schemas changed.


The key to all of this is that each change to the DB schema would be in 
a patch that contained corresponding changes to the nova.objects.* 
classes that are used to represent the data. And it is *these* object 
classes that have object versioning and model changes tracked in them.


So, for instance, let's say the widget class was represented in a 
nova.objects.widget.Widget model in the following code, before the patch 
that added the #1 schema migration:


 class Widget(base.NovaPersistentObject):
 VERSION = '1.0'
 fields = {
 'id': fields.IntegerField(),
 'name': fields.StringField(),
 'modified_date': fields.StringField(),
 'status_code': fields.IntegerField()
 }

The above object would have two important methods on it; one that would 
know how to save the data in the object's fields to the backend database 
and another method (obj_make_compatible()) that would know how to return 
the object to callers that expected the object's schema to look a 
certain way at a certain version of the object.


Before the patch that landed DB schema migration #1, the Widget object's 
obj_make_compatible() method would be blank -- since there's no version 
transformations that need to occur. The Widget.save() method would take 
the values in the fields and write those to the widgets and 
widget_status table in a single transaction.


Now, along comes the patch that adds DB schema migration #1 that changes 
the data type of the underlying widget_status.modified_date from a 
VARCHAR to a DATETIME, and simultaneously changes the name of the DB 
column from modified_date to modified_timestamp. In this same patch, 
there would be a corresponding change to the nova.objects.Widget class 
that would make the class definition look something like this:


 class Widget(base.NovaPersistentObject):
 VERSION = '1.1'
 fields = {
 'id': fields.IntegerField(),
 'name': fields.StringField(),
 'modified_timestamp': fields.DatetimeField(),
 'status_code': fields.IntegerField()
 }

 @staticmethod
 def _from_db_object(context, widget, db_obj):
 # db_obj is what comes back from the DB API call
 # widget_get(). The SQL for this call will look like this:
 #
 # SELECT id, modified_date, modified_timestamp, status_code
 # FROM widgets JOIN widget_status ON id = widget_id
 # WHERE widgets.id = ?
 #
 # The returned data will look like this:
 # {'id': 1, 'name': 'my widget',
 #  'modified_date': None or string,
 #  'modified_timestamp': None or datetime,
 #  'status_code': 42
 for f in ('id', 'status_code', 'name'):
 widget[f] = db_obj[f]
 ts = db_obj['modified_timestamp']
 if ts is None:
 ts = datetime.datetime.strftime(db_obj['modified_date'])
 widget['modified_timestamp'] = ts

 def

Re: [openstack-dev] [Nova][libvirt] Understand why we lookup libvirt domains by instance name

2015-05-21 Thread Sahid Orentino Ferdjaoui

On Thu, May 21, 2015 at 09:11:57AM -0700, Michael Still wrote:
 On Thu, May 21, 2015 at 7:49 AM, Sahid Orentino Ferdjaoui
 sahid.ferdja...@redhat.com wrote:
  On Thu, May 21, 2015 at 10:23:35AM +0100, Daniel P. Berrange wrote:
  On Wed, May 20, 2015 at 03:01:50PM -0700, Michael Still wrote:
   I note that we use instance.name to lookup the libvirt domain a bunch
   in the driver. I'm wondering why we don't just use instance.uuid all
   the time -- the code for that already exists. Is there a good reason
   to not move to always using the uuid?
  
   I ask because instance.name is not guaranteed to be unique depending
   on how weird the nova deployment is.
 
  Agreed, there's no benefit to using name - internally libvirt will always
  prefer to use the UUID itself too.
 
  These days though, there is only a single place in nova libvirt driver
  that needs updating - the nova.virt.libvirt.host.Host class get_domain()
  method just needs to be switched to use uuid.
 
  I'm currently working on the libvirt driver I can add this in my TODO
 
https://review.openstack.org/#/c/181969/
 
 Well, I am playing in this code to do some qemu stuff, so I will throw
 something out in the next day or so anyways. If you beat me to it then
 that's fine as well.

Nothing hurry in my side I let you play with this part of code :)

s.

__
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] [barbican] Nominating Kaitlin Farr for barbican-core

2015-05-21 Thread John Wood

+1

From: Douglas Mendizábal douglas.mendiza...@rackspace.com
Sent: Tuesday, May 19, 2015 7:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [barbican] Nominating Kaitlin Farr for barbican-core

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi All,

I would like to nominate Kaitlin Farr for barbican-core.

Kaitlin has been contributing to the project for a long time, both by
contributing code to Barbican, python-barbicanclient and Castellan,
and also by providing valuable reviews. [1]

As a reminder to the rest of the core team, we use the process
outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
members to the barbican-core team.

Thanks,
Douglas Mendizábal

[1] http://stackalytics.com/report/contribution/barbican-group/90
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVW9CgAAoJEB7Z2EQgmLX7u6kP/22G3NqsnJmKRsnw065btt8z
/Sb7OqFa2RKuIKk88a9yehwRuunh2YCdfLmXta1+XXpucghG9dbflfFVGU4/VujX
VG/B3yUXTBYT2kn72mtwpKk4S6mYXBPn+fpKGR7iJrifYSg55XO7a2c2m/xIC8pO
R9+d5/8ZztxS1UbmhNuqLwBDpo9FIG+5CoWOfYPTAQ1TxB/SIs2ltk4jzLaU05yb
5LTG3uq5K3CT+LvM3Rl6SCZ7bIiTmaTuPsXMnqqLiqhya90U63VJGGXUE1yjW11G
Kgm7yxUV8DkcESHXEe0aW8hpLMuGKda/f83XetGN27+YpM3/G1z8N656zLX9sF3t
oVU7dWnARn9NsByFP9ASg8BCk8iWr/mCeB/fajwXT95C+OXAicNWn5jXKowXQhQH
v4XaFrjafROLdJocgH0mfcoEbTXZXlsKyHYtnZdwAO+T06RNd21c/lnNiG1rMYeh
2Yl48nzxxx33YprizHDRMEhABIb11HO040+j+EHNCvbsGSJGZIZmzzbxNe2QGXkx
q++JvMBW60pPd6pi7nEVjbjSEZhb6f6xHs13/y+nZ9NCSNkUPx1UoxKz18JRtrLi
/XDZLv6D92Trlaxae9mpVlWTM1elYPWSm3QVMxMrSP9wtAYbUIoq0PN+WwKk/1J7
WaeQpFjA1SdFHj5uPNZk
=1OIW
-END 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

__
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-docker] Status update

2015-05-21 Thread Matt Riedemann




On 5/17/2015 1:22 PM, Adrian Otto wrote:

Good questions Matt and Alex. Currently Magnum creates Bays (places that can 
run containers, or pods of containers, and other high level resources such as 
service, replication controllers, etc.) composed of one or more Nova instances 
(Nodes). This way, we can potentially allow the creation and management for 
containers on any compute form factor (bare metal, VM, container, etc.). The 
Nova instances Magnum uses to form the Bays come from Heat.

NOTE: There is no such thing as a nova-magnum virt driver today. The following 
discussion is theoretical.

Understanding that, it would be possible to make a nova-magnum virt driver that 
talks to Magnum to ask for an instance of type container from an *existing* 
Bay, but then Magnum would need to have access to Nova instances that are NOT 
produced by the nova-magnum driver in order to scale out the Bay by adding more 
nodes to it. If we do this, and the cloud operator does not realize the 
circular dependency when setting Nova to use a nova-magnum virt driver, it 
would be possible to create a loop where nova-magnum provides containers to 
Magnum that come from the same bay we are attempting to scale out. This would 
prevent the Bay from actually scaling out because it will be sourcing capacity 
from itself. We could allow this to work by requiring anyone who uses 
nova-magnum to also have another Nova host aggregate that uses an alternate 
virt driver (Ironic, libvirt, etc.), and having some way for Magnum’s Heat 
template to ask only for instances produced without the Magnum virt driv!
er when 
forming or scaling Bays. I suppose a scheduling hint might be adequate for this.


Adrian


On May 17, 2015, at 11:48 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:



On 5/16/2015 10:52 PM, Alex Glikson wrote:

If system containers is a viable use-case for Nova, and if Magnum is
aiming at both application containers and system containers, would it
make sense to have a new virt driver in nova that would invoke Magnum
API for container provisioning and life cycle? This would avoid (some of
the) code duplication between Magnum and whatever nova virt driver would
support system containers (such as nova-docker). Such an approach would
be conceptually similar to nova virt driver invoking Ironic API,
replacing nova-baremetal (here again, Ironic surfaces various
capabilities which don't make sense in Nova).
We have recently started exploring this direction, and would be glad to
collaborate with folks if this makes sense.

Regards,
Alex


Adrian Otto adrian.o...@rackspace.com wrote on 09/05/2015 07:55:47 PM:


From: Adrian Otto adrian.o...@rackspace.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 09/05/2015 07:57 PM
Subject: Re: [openstack-dev] [nova-docker] Status update

John,

Good questions. Remarks in-line from the Magnum perspective.

On May 9, 2015, at 2:51 AM, John Garbutt j...@johngarbutt.com wrote:


On 1 May 2015 at 16:14, Davanum Srinivas dava...@gmail.com wrote:

Anyone still interested in this work? :)

* there's a stable/kilo branch now (see
http://git.openstack.org/cgit/stackforge/nova-docker/).
* CI jobs are running fine against both nova trunk and nova's
stable/kilo branch.
* there's an updated nova-spec to get code back into nova tree (see
https://review.openstack.org/#/c/128753/)


To proxy the discussion from the etherpad onto the ML, we need to work
out why this lives in nova, given Magnum is the place to do container
specific things.


To the extent that users want to control Docker containers through
the Nova API (without elaborate extensions), I think a stable in-
tree nova-docker driver makes complete sense for that.


[...]



Now whats the reason for adding the Docker driver, given Nova is
considering container specific APIs out of scope, and expecting
Magnum to own that kind of thing.


I do think nova-docker should find it’s way into the Nova tree. This
makes containers more accessible in OpenStack, and appropriate for
use cases where users want to treat containers like they treat
virtual machines. On the subject of extending the Nova API to
accommodate special use cases of containers that are beyond the
scope of the Nova API, I think we should resist that, and focus
those container-specific efforts in Magnum. That way, cloud
operators can choose whether to use Nova or Magnum for their
container use cases depending on the range of features they desire
from the API. This approach should also result in less overlap of

efforts.



[...]

To sum up, I strongly support merging in nova-docker, with the
caveat that it operates within the existing Nova API (with few minor
exceptions). For features that require API features that are truly
container specific, we should land those in Magnum, and keep the
Nova API scoped to operations that are appropriate for “all instance

types.


Adrian



Thanks,
John

Re: [openstack-dev] [barbican] Nominating Kaitlin Farr for barbican-core

2015-05-21 Thread Ade Lee

+1

On Tue, 2015-05-19 at 17:09 -0700, Douglas Mendizábal wrote:
 Hi All,
 
 I would like to nominate Kaitlin Farr for barbican-core.
 
 Kaitlin has been contributing to the project for a long time, both by
 contributing code to Barbican, python-barbicanclient and Castellan,
 and also by providing valuable reviews. [1]
 
 As a reminder to the rest of the core team, we use the process
 outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
 members to the barbican-core team.
 
 Thanks,
 Douglas Mendizábal
 
 [1] http://stackalytics.com/report/contribution/barbican-group/90
 __
 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] [barbican] Nomination of Kaitlin Farr for core

2015-05-21 Thread Steve Heyman

+1 from me.

[cid:EED0E042-E892-4105-9EAD-66D943BF937E]
__
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] [api] [docs] improving app Dev docs

2015-05-21 Thread Anne Gentle

Hi all, please come to the API doc working session this morning at 11:50 in 305 
if you want to work on plans for next-gen API docs in Liberty.

https://libertydesignsummit.sched.org/mobile/#session:29e7d4effc10832b4d6aa50339e0c973

Thanks,
Anne


__
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] Abandoning old specs for Nova

I just did an abandon run for specs that meet this criteria and
haven't been touched since March. Once again, this isn't a kiss of
death, just an attempt at review backlog hygiene.

Cheers,
Michael

On Tue, May 5, 2015 at 1:26 AM, John Garbutt j...@johngarbutt.com wrote:
 On Monday, May 4, 2015, Michael Still mi...@stillhq.com wrote:

 Hi,

 I just wanted to let people know that I am going through abandoning
 old specs for Nova at the moment. The criteria I am using is:

  - spec targets kilo
  - no review comments or other activity since January or February

 I think its worth reinforcing that an abandon isn't a -2... An upload
 of a new version of the spec will re-open reviews on it. Here's the
 message I've been using while abandoning:

 Please update this spec for Liberty if you're still interested in
 pursuing it.


 Thanks, I already did the ones not touched this year. Makes sense to take
 that a bit further.

 We should probably automate this to get parity with code patches, or
 something similar at least?

 Thanks,
 John


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

Re: [openstack-dev] [pbr] 1.0.1 released

2015-05-21 Thread Brant Knudson

On Thu, May 21, 2015 at 2:22 AM, YAMAMOTO Takashi yamam...@valinux.co.jp
wrote:

 hi,

 can you explain why you want to use pbr 1.0.1 in the first place?
 what's wrong with requiring pbr1.0 ?


Global requirements currently has pbr=0.11,2.0[1], and
keystonemiddleware has the updated requirement which conflicts with
oslo.config, so now the keystonemiddleware gate is broken[2].

According to the pkg_resources output, all of these packages are
conflicting:
'oslo.utils', 'python-keystoneclient', 'oslo.config', 'oslo.serialization',
'oslo.i18n', 'oslo.context'.

[1]
http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n94
[2]
http://logs.openstack.org/60/179460/3/check/gate-keystonemiddleware-python26/335fcfa/console.html#_2015-05-21_13_51_45_876

- Brant



 YAMAMOTO Takashi

  Hi openstack-dev team,
 
  Can you also release latest oslo.config to allow pbr 1.0.1?
  In my convenience I want to use it.
 
 
  Thanks,
  kakuma
 
  On Wed, 20 May 2015 11:07:36 +1200
  Robert Collins robe...@robertcollins.net wrote:
 
  We are super psyched to announce the release of:
 
  pbr 1.0.1: Python Build Reasonableness
 
  With source available at:
 
  http://git.openstack.org/cgit/openstack-dev/pbr
 
  For more details, please see the git log history below and:
 
  http://launchpad.net/pbr/+milestone/1.0.1
 
  Please report issues through launchpad:
 
  http://bugs.launchpad.net/pbr
 
  Changes in pbr 1.0.0..1.0.1
  ---
 
  b72e446 Remove self.pre_run calls in packaging.py
  8e87679 Update hacking to 0.10.x series
 
  Diffstat (except docs and test files)
  -
 
  pbr/packaging.py  | 2 --
  test-requirements.txt | 2 +-
  2 files changed, 1 insertion(+), 3 deletions(-)
 
 
  Requirements updates
  
 
  diff --git a/test-requirements.txt b/test-requirements.txt
  index 2b33504..6e4521c 100644
  --- a/test-requirements.txt
  +++ b/test-requirements.txt
  @@ -4 +4 @@ fixtures=0.3.14
  -hacking=0.9.2,0.10
  +hacking=0.10.0,0.11
 
 
 
  --
  Robert Collins rbtcoll...@hp.com
  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
 
  --
  fumihiko kakuma kak...@valinux.co.jp
 
 
 
 
 __
  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] [Oslo] Review dashboard for oslo?

One is linked from https://wiki.openstack.org/wiki/Oslo#Review_Links

On 22 May 2015 at 05:13, Michael Still mi...@stillhq.com wrote:
 Hi,

 I'm finding that oslo being in 1,400 different git repos is making it
 hard to build a gerrit review dashboard URL. Does anyone have one of
 these already built that I can just steal?

 Thanks,
 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



-- 
Robert Collins rbtcoll...@hp.com
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

[openstack-dev] [Oslo] Review dashboard for oslo?

Hi,

I'm finding that oslo being in 1,400 different git repos is making it
hard to build a gerrit review dashboard URL. Does anyone have one of
these already built that I can just steal?

Thanks,
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] [pbr] 1.0.1 released