Re: [openstack-dev] How to implement and configure a new Neutron vpnaas driver from scratch?

[Bo Lin]

I wonder whether your neutron server codes have added the " VPNaaS integration 
with service type framework " change on 
https://review.openstack.org/#/c/41827/21 , if not, the service_provider option 
is useless. You need to include the change before developing your own driver. 

QA (In my opinion and sth may be missing): 
- What is the difference between service drivers and device drivers? 
service drivers are driven by vpn service plugin and are responsible for 
casting rpc request (CRUD of vpnservices) to and do callbacks from vpn agent. 
device drivers are driven by vpn agent and are responsible for implementing 
specific vpn operations and report vpn running status. 

- Could I implement only one of them? 
device driver must be implemented based on your own device. Unless the default 
ipsec service driver is definitely appropriate, suggest you implement both of 
them. After including "VPNaaS integration with service type framework", the 
service driver work is simple. 

- Whe re I need to put my Python implementation in my OpenStack instance? 
Do you mean let your instance runs your new codes? The default source codes dir 
is /opt/stack/neutron, you need to put your new changes into the dir and 
restart the neutron server. 

- How could I configure my OpenStack instance to use this implementation? 
1. Add your new codes into source dir 
2. Add appropriate vpnaas service_provider into neutron.conf and add 
appropriate "vpn_device_driver" option into vpn_agent.ini 
3. restart n-svc and q-vpn 

Hope help you. 

- Original Message -

From: "Julio Carlos Barrera Juez"  
To: "OpenStack Development Mailing List"  
Sent: Monday, February 17, 2014 7:18:44 PM 
Subject: [openstack-dev] How to implement and configure a new Neutron vpnaas 
driver from scratch? 

Hi. 

I have asked in the Q&A website without success ( 
https://ask.openstack.org/en/question/12072/how-to-implement-and-configure-a-new-vpnaas-driver-from-scratch/
 ). 

I want to develop a vpnaas implementation. It seems that since Havana, there 
are plugins, services and device implementations. I like the plugin and his 
current API, then I don't need to reimplement it. Now I want yo implement a 
vpnaas driver, and I see I have two main parts to take into account: the 
service_drivers and the device_drivers. IPsec/OpenSwan implementation is the 
unique sample I've found. 

I'm using devstack to test my experiments. 

I tried to implement VpnDriver Python class extending the main API methods like 
IPsecVPNDriver does. I placed basic implementation files at the same level of 
IPsec/OpenSwan does and configured Neutron adding this line to 
/etc/neutron/neutron.conf file: 

service_provider = 
VPN:VPNaaS:neutron.services.vpn.service_drivers.our_python_filename.OurClassName:default
 

I restarted Neutron related services in my devstack instance, but it seemed it 
didn't work. 



- What is the difference between service drivers and device drivers? 
- Could I implement only one of them? 
- Whe re I need to put my Python implementation in my OpenStack instance? 
- How could I configure my OpenStack instance to use this implementation? 



I didn't find almost any documentation about these topics. 

Thank you very much. 

___ 
OpenStack-dev mailing list 
OpenStack-dev@lists.openstack.org 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=9uhm%2F59JRfiZ3CXzuhBOpqcTqWk8APswRGJFZ8H2Tos%3D%0A&s=46fe06049efb1d29a85b63f7ce101cd69695a368c3da6ea3a91bcd7d2b71ce59
 

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

Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy

[Samuel Bercovici]

Hi,

It matters, as someone might need to "debug" the backend setup and the name, if 
exists, can add details.
This obviously a vendor's choice if they wish to push this back to backend but 
the API should not remove this as a choice.

-Sam.


From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Monday, February 17, 2014 12:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy

Folks,

I wonder why using names on the backend could be needed? For the code there is 
no much difference between name and the id.

Thanks,
Eugene.

On Mon, Feb 17, 2014 at 1:57 PM, Samuel Bercovici 
mailto:samu...@radware.com>> wrote:
Hi,

My concern is that if from some reason the driver implementer would like to 
reflect the name also in the backend device, than an update should also be 
calling the driver.
Using readable names also makes sense on the back-end device.

-Sam.


From: Oleg Bondarev 
[mailto:obonda...@mirantis.com]
Sent: Monday, February 17, 2014 11:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy

Hi,

On Mon, Feb 17, 2014 at 1:23 PM, Eugene Nikanorov 
mailto:enikano...@mirantis.com>> wrote:
Hi Avishay,

1) I think name might be useful. Consider user forms a list of rules which 
route requests to a pool with static images or static pages, it may make sense 
to give those policy a name 'static-iamges', 'static-pages', rather then 
operate on ids.
+1


2) I think updating the name is useful as well, but just on DB level, so there 
is no point in calling the driver and communicating with the backend.
+1

Thanks,
Eugene.

On Mon, Feb 17, 2014 at 12:58 PM, Avishay Balderman 
mailto:avish...@radware.com>> wrote:
Hi
L7Policy  holds a list of L7rules plus 1 attribute: "name" .
Questions:

1)  Do we need to have this name attribute?

2)  Do we want to allow update operation of the name attribute? Do we need 
to invoke the driver when such update occurred?

Thanks

Avishay

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


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


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

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

Re: [openstack-dev] [keystone] Centralized policy rules and quotas

[Qiu Yu]

On Fri, Feb 7, 2014 at 4:46 AM, Raildo Mascena  wrote:

> Hello,
>
> Currently, there is a blueprint for creating a Domain in New Quota Driver
> who is waiting approval, but that is already implemented. I believe that is
> worth checking out.
>
> https://blueprints.launchpad.net/nova/+spec/domain-quota-driver
>
> Any questions I am available.
>
> Regards,
>
> Raildo Mascena
>

Hi Raildo,

Is this domain quota driver code now available to review?

I'm asking this because work items in the blueprint[1] have already been
marked as done, and there is also some relevant work (quotas for domain)
mentioned by Vinod in another thread. But found nowhere for the domain
quota driver code. Appreciated if you can share me some pointers.

[1] https://blueprints.launchpad.net/nova/+spec/domain-quota-driver

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

Re: [openstack-dev] [keystone] Centralized policy rules and quotas

[Vinod Kumar Boppanna]

Dear Qiu Yu,

The domain quota driver as well as the APIs to access the domain quota driver 
is available. Please check the following

BluePrint -> https://blueprints.launchpad.net/nova/+spec/domain-quota-driver-api
Wiki Page -> https://wiki.openstack.org/wiki/APIs_for_Domain_Quota_Driver
GitHub Code -> https://github.com/vinodkumarboppanna/DomainQuotaAPIs

The APIs are implemented in the above code. Currently, working to add the 
options for accessing domain quotas in the command line (like for eg:  nova 
domain-quota-show --domain  --tenant  --user )

Thanks & Regards,
Vinod Kumar Boppanna

From: Qiu Yu [unic...@gmail.com]
Sent: 18 February 2014 09:52
To: OpenStack Development Mailing List (not for usage questions)
Cc: Vinod Kumar Boppanna; tiago.mart...@hp.com
Subject: Re: [openstack-dev] [keystone] Centralized policy rules and quotas


On Fri, Feb 7, 2014 at 4:46 AM, Raildo Mascena 
mailto:rail...@gmail.com>> wrote:
Hello,

Currently, there is a blueprint for creating a Domain in New Quota Driver who 
is waiting approval, but that is already implemented. I believe that is worth 
checking out.

https://blueprints.launchpad.net/nova/+spec/domain-quota-driver

Any questions I am available.

Regards,

Raildo Mascena

Hi Raildo,

Is this domain quota driver code now available to review?

I'm asking this because work items in the blueprint[1] have already been marked 
as done, and there is also some relevant work (quotas for domain) mentioned by 
Vinod in another thread. But found nowhere for the domain quota driver code. 
Appreciated if you can share me some pointers.

[1] https://blueprints.launchpad.net/nova/+spec/domain-quota-driver

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

[openstack-dev] [Neutron] port forwarding from gateway to internal hosts

[Yair Fried]

Hi,
What's the status of this BP? - 
https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding
will it be ready for I3?
The BP is approved but the patch is abandoned

Regards
Yair

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

[openstack-dev] [GSoC] Participate as participant

[Robber Phex]

Hello everyone,

I am RobberPhex, a junior in Donghua University(Shanghai, China). I want to
participate in GSoC this year as Student. I know that OpenStack as a
potential org in GSoC, so I decide to participate.

I am a Student major in software engineering. In 2012 August, I first touch
OpenStack. After that, I learn OpenStack (included KVM, Python). In 2013
December, I deploy OpenStack on Server.
For participation, in this winter vacation, I read a book that about
Python, and I try to write Python program (in Github).

But, I cannot decide (sub)project to participate. If a mentor can guide me
with a easy or medium  difficulty project in Openstack, I would be very
grateful.

BTW, I have added my name to OpenStack GSoC 2014 page.

Thanks.

-- 
Regards,
RobberPhex

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

Re: [openstack-dev] [GSoC] Participate as participant

[Robber Phex]

And, should I CC this mail to OpenStack maillist?


On Tue, Feb 18, 2014 at 5:14 PM, Robber Phex  wrote:

> Hello everyone,
>
> I am RobberPhex, a junior in Donghua University(Shanghai, China). I want
> to participate in GSoC this year as Student. I know that OpenStack as a
> potential org in GSoC, so I decide to participate.
>
> I am a Student major in software engineering. In 2012 August, I first
> touch OpenStack. After that, I learn OpenStack (included KVM, Python). In
> 2013 December, I deploy OpenStack on Server.
> For participation, in this winter vacation, I read a book that about
> Python, and I try to write Python program (in Github).
>
> But, I cannot decide (sub)project to participate. If a mentor can guide me
> with a easy or medium  difficulty project in Openstack, I would be very
> grateful.
>
> BTW, I have added my name to OpenStack GSoC 2014 page.
>
> Thanks.
>
> --
> Regards,
> RobberPhex
>
> About me: http://about.me/RobberPhex
>



-- 
Regards,
RobberPhex

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

Re: [openstack-dev] [Tripleo]help needed - nodepool and zuul support for ci-overcloud

[Derek Higgins]

On 17/02/14 23:43, Robert Collins wrote:
> So we experimented with the ci-overcloud (a TripleO deployed cloud for
> running CI for TripleO) and it uncovered some bugs/limitations in
> nodepool and zuul.
> 
> We need to fix these to reduce our negative impact on the
> Openstack-infra team, before they'll be comfortable having the
> ci-overcloud back in rotation... and certainly before we can start
> checking  /  gating (because the reality is, until we're truely
> stable, things will go wrong).
> 
> https://bugs.launchpad.net/openstack-ci/+bug/1281319
I'll take a look at this one.

> https://bugs.launchpad.net/openstack-ci/+bug/1281320
> 
> One bug is to teach nodepool to startup even if a provider can't be
> contacted. The other is to have zuul timeout jobs that don't start at
> all. Both should be small - < 1 day of dev for a cold start on the
> project. Pure python.
> 
> -Rob
> 


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

Re: [openstack-dev] [Nova] libvirt doesn't migrate cdrom devices?

[Daniel P. Berrange]

On Mon, Feb 17, 2014 at 11:34:46PM -0700, Michael Still wrote:
> Hi.
> 
> For the last day or so I've been chasing
> https://bugs.launchpad.net/nova/+bug/1246201, and I think I've found
> the problem... libvirt doesn't migrate devices of type cdrom, even if
> they're virtual. If I change the type of the config drive to disk,
> then block migration works just fine.
> 
> Does anyone know if this is a bug in libvirt? How would people feel
> about me changing the type of config drives from cdrom to disk, which
> is something that other hypervisors already do?

Be good to know what the reason was for it being set as a cdrom in the
first place, before we change it to disk.

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-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Centralized policy rules and quotas

[Qiu Yu]

On Tue, Feb 18, 2014 at 4:59 PM, Vinod Kumar Boppanna <
vinod.kumar.boppa...@cern.ch> wrote:

>  Dear Qiu Yu,
>
> The domain quota driver as well as the APIs to access the domain quota
> driver is available. Please check the following
>
> BluePrint ->
> https://blueprints.launchpad.net/nova/+spec/domain-quota-driver-api
> Wiki Page -> https://wiki.openstack.org/wiki/APIs_for_Domain_Quota_Driver
> GitHub Code -> https://github.com/vinodkumarboppanna/DomainQuotaAPIs
>

Vinod,

Thank you for sharing. I did try to dig up in your repo before sending the
last email.

It looks like domain quota driver code has already been included in your
base commit, that is not quite easy for me to read. Do you happen to have a
link for the clean commit / patch of just domain quota driver code itself?
Thanks!

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

Re: [openstack-dev] [Nova] libvirt doesn't migrate cdrom devices?

[Daniel P. Berrange]

On Tue, Feb 18, 2014 at 09:38:49AM +, Daniel P. Berrange wrote:
> On Mon, Feb 17, 2014 at 11:34:46PM -0700, Michael Still wrote:
> > Hi.
> > 
> > For the last day or so I've been chasing
> > https://bugs.launchpad.net/nova/+bug/1246201, and I think I've found
> > the problem... libvirt doesn't migrate devices of type cdrom, even if
> > they're virtual. If I change the type of the config drive to disk,
> > then block migration works just fine.
> > 
> > Does anyone know if this is a bug in libvirt? How would people feel
> > about me changing the type of config drives from cdrom to disk, which
> > is something that other hypervisors already do?
> 
> Be good to know what the reason was for it being set as a cdrom in the
> first place, before we change it to disk.

And here's that reason:

  commit 7f4b5771633f519a54aae985ae526418114b1a29
  Author: Tony Yang 
  Date:   Thu Jul 18 18:45:24 2013 +0800

Config drive attached as cdrom

Some guest OSes (e.g. Windows) require config drive to be a cdrom device
to access the iso9660 filesystem on it. Option config_drive_format is
therefore set to also control the device type of config drive. If it's
set to 'iso9660', config drive will be cdrom; if it's 'vfat', config
drive will be disk.

DocImpact
Fixes: bug #1155842
Change-Id: I6c08b1b8040a1fd0db8e2b3b1fc798060733001f

So I'd saying changing it to 'disk' is out of the question unless
we unconditionally use vfat as the filesystem instead of iso9660.

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-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Centralized policy rules and quotas

[Vinod Kumar Boppanna]

Dear Qiu Yu,

Yes, the domain quota driver is included in the base commit. But if you just 
want the domain quota driver and nothing else, then you can just download the 
following files (Hope i haven't missed any file required just for domain quota 
driver)

https://github.com/vinodkumarboppanna/DomainQuotaAPIs/blob/master/nova/quota.py

https://github.com/vinodkumarboppanna/DomainQuotaAPIs/blob/master/nova/db/sqlalchemy/models.py

https://github.com/vinodkumarboppanna/DomainQuotaAPIs/blob/master/nova/db/sqlalchemy/migrate_repo/versions/230_create_domain_quotas_tables.py


The file "quota.py" contains the domain quota driver implemented by Tiago and 
his team (I have just added few more functions to complete it).

Hope this is ok. If you are finding problem with this as well, then let me 
know...I will try to create a patch then (I am new to all this code commit, 
patch etc..so please bare with me for the inconvenience).

Tiago once had given me this link

https://github.com/tellesnobrega/nova/tree/master/nova (where he has put up the 
domain quota driver). But again as i said, it was little in-complete ..and some 
of the functions are missing.

Thanks & Regards,
Vinod Kumar Boppanna


From: Qiu Yu [unic...@gmail.com]
Sent: 18 February 2014 10:26
To: Vinod Kumar Boppanna
Cc: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone] Centralized policy rules and quotas

On Tue, Feb 18, 2014 at 4:59 PM, Vinod Kumar Boppanna 
mailto:vinod.kumar.boppa...@cern.ch>> wrote:
Dear Qiu Yu,

The domain quota driver as well as the APIs to access the domain quota driver 
is available. Please check the following

BluePrint -> https://blueprints.launchpad.net/nova/+spec/domain-quota-driver-api
Wiki Page -> https://wiki.openstack.org/wiki/APIs_for_Domain_Quota_Driver
GitHub Code -> https://github.com/vinodkumarboppanna/DomainQuotaAPIs

Vinod,

Thank you for sharing. I did try to dig up in your repo before sending the last 
email.

It looks like domain quota driver code has already been included in your base 
commit, that is not quite easy for me to read. Do you happen to have a link for 
the clean commit / patch of just domain quota driver code itself? Thanks!

Thanks,
Qiu Yu

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

Re: [openstack-dev] Glance v1 and v2

[Joe Hakim Rahme]

I have only played with Glance v2 locally on a devstack, so take what I write
with a graing of salt.

What's new in API v2?
-

+ registry: You don't need to run glance-registry anymore. Unless you still
 support v1.

+ tags: Every image has a tag list metadata. A tag can be
 created/updated/deleted by an image owner. A tag can be read by any member of
 the image.

+ New membership mechanism: You can read about it here[1].

+ You can query the API for JSON schemas describing resources.


How well is it supported?
-

+ python-glanceclient: Supports API v2 through the cli flag  
--os-image-api-version.

+ Cinder: Supports API v2 (for volume creation from images). You specify the API
 version in cinder.conf (glance_api_version option).

+ Nova: doesn't support v2. This mailing thread[2] gives a good overview of the
 situation.

+ Horizon: To the best of my knowledge, Horizon doesn't support v2 yet.


How well is it tested?
--

I tried a few manual tests on a local devstack and it seemed to work. And the v2
seems to be pretty well covered in Tempest[3].


Can v1 and v2 coexist?
--

>From whatever little I've seen, both APIs can safely be activated alongside 
>each
other. Some things to note:

+ v2 membership is not really taken into account if v1 is still activated.
+ you still need to run glance-registry if v1 is activated

Conclusion
--
Again, I have just spent a couple of days playing with it on a devstack. I'm by
no means a reference on the subject of the API v2. I hope this will help you get
a better idea of where it stands today. And if anyone notices something I may
have missed or anything wrong in my summary, please do point it out so I can
correct it.

[1]: 
http://docs.openstack.org/api/openstack-image-service/2.0/content/image-sharing.html
[2]: 
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026849.html
[3]: http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2

---
Joe H. Rahme
IRC: rahmu

On 14 Feb 2014, at 19:37, Pete Zaitcev  wrote:

> Hello:
> 
> does anyone happen to know, or have a detailed write-up, on the
> differences between so-called "Glance v1" and "Glance v2"?
> 
> In particular do we still need Glance Registry in Havana, or
> do we not? The best answer so far was to run the registry anyway,
> "just in case", which does not feel entirely satisfactory.
> Surely someone should know exactly what is going on in the API
> and have a good idea what the implications are for the users
> of Glance (API, CLI, and Nova (I include Horizon into API)).
> 
> Thanks,
> -- Pete
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Nova] libvirt doesn't migrate cdrom devices?

[Michael Still]

On Tue, Feb 18, 2014 at 2:43 AM, Daniel P. Berrange  wrote:

> So I'd saying changing it to 'disk' is out of the question unless
> we unconditionally use vfat as the filesystem instead of iso9660.

So, at the moment we conflate a flag about format (iso9660 or vfat)
with a flag about device type. We could have both as separate flags
with reasonable defaults. However, at the moment we're pretty much
presented with a choice of either having a working Windows instance,
or working block migration. I suspect that's a trade off we don't want
to have to make.

Do you have any visibility into why cdrom devices don't get migrated
by libvirt correctly? Is there perhaps a flag to the migrate call we
could twiddle to make it magically work right?

(I did look at simply re-creating the config drive from scratch on the
destination node, but its not possible. Much of the information needed
to create the drive such as admin password and injected files is gone
by the time the migration occurs).

Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] [Nova] libvirt doesn't migrate cdrom devices?

[Daniel P. Berrange]

On Tue, Feb 18, 2014 at 03:08:59AM -0700, Michael Still wrote:
> On Tue, Feb 18, 2014 at 2:43 AM, Daniel P. Berrange  
> wrote:
> 
> > So I'd saying changing it to 'disk' is out of the question unless
> > we unconditionally use vfat as the filesystem instead of iso9660.
> 
> So, at the moment we conflate a flag about format (iso9660 or vfat)
> with a flag about device type. We could have both as separate flags
> with reasonable defaults. However, at the moment we're pretty much
> presented with a choice of either having a working Windows instance,
> or working block migration. I suspect that's a trade off we don't want
> to have to make.

Why do we need to support both iso9660 and vfat ?  If we only cared
to support vfat, then we could have working Windows and working block
migration.

Incidentally since you say other virt drivers don't use cdrom, does
this mean they only use vfat, or are they using iso9660 + disk and
thus broken for windows too ?

> Do you have any visibility into why cdrom devices don't get migrated
> by libvirt correctly? Is there perhaps a flag to the migrate call we
> could twiddle to make it magically work right?

It seems to be done on the assumption that we only care about
migrating data for writable disks. I think that was just copied
from QEMU's original built-in block migration so that we had
consistent behaviour. So there's no quick fix in libvirt we can
do - we'd probably have to figure out a way to pass in a list of
disks to be mirrored.

/* skip shared, RO and source-less disks */
if (disk->shared || disk->readonly || !disk->src)
continue;

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-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] libvirt doesn't migrate cdrom devices?

[Michael Still]

On Tue, Feb 18, 2014 at 3:14 AM, Daniel P. Berrange  wrote:
> On Tue, Feb 18, 2014 at 03:08:59AM -0700, Michael Still wrote:
>> On Tue, Feb 18, 2014 at 2:43 AM, Daniel P. Berrange  
>> wrote:
>>
>> > So I'd saying changing it to 'disk' is out of the question unless
>> > we unconditionally use vfat as the filesystem instead of iso9660.
>>
>> So, at the moment we conflate a flag about format (iso9660 or vfat)
>> with a flag about device type. We could have both as separate flags
>> with reasonable defaults. However, at the moment we're pretty much
>> presented with a choice of either having a working Windows instance,
>> or working block migration. I suspect that's a trade off we don't want
>> to have to make.
>
> Why do we need to support both iso9660 and vfat ?  If we only cared
> to support vfat, then we could have working Windows and working block
> migration.

iso9660 was made the default at the request of the cloud-init author.
IIRC the decision was based on it being a "cleaner" interface than
vfat (read only, etc). I certainly think we could make vfat the
default, and put a big ugly warning about iso9660 in the flag which
lets operators select which to use.

> Incidentally since you say other virt drivers don't use cdrom, does
> this mean they only use vfat, or are they using iso9660 + disk and
> thus broken for windows too ?

I'm specifically thinking of hyper-v here, and I am sure they tested
with Windows. To be honest I don't remember all the details, I just
recall that at least one hypervisor had issues with attaching a second
cdrom (we support boot from cdrom).

>> Do you have any visibility into why cdrom devices don't get migrated
>> by libvirt correctly? Is there perhaps a flag to the migrate call we
>> could twiddle to make it magically work right?
>
> It seems to be done on the assumption that we only care about
> migrating data for writable disks. I think that was just copied
> from QEMU's original built-in block migration so that we had
> consistent behaviour. So there's no quick fix in libvirt we can
> do - we'd probably have to figure out a way to pass in a list of
> disks to be mirrored.
>
> /* skip shared, RO and source-less disks */
> if (disk->shared || disk->readonly || !disk->src)
> continue;

H. Shame that.

Ok, I'll take a pass at changing the default tomorrow.

Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] [keystone] Centralized policy rules and quotas

[Qiu Yu]

On Feb 18, 2014 5:48 PM, "Vinod Kumar Boppanna" <
vinod.kumar.boppa...@cern.ch> wrote:



> The file "quota.py" contains the domain quota driver implemented by Tiago
and his team (I have just added few more functions to complete it).
>
> Hope this is ok. If you are finding problem with this as well, then let
me know...I will try to create a patch then (I am new to all this code
commit, patch etc..so please bare with me for the inconvenience).
>
> Tiago once had given me this link
>
> https://github.com/tellesnobrega/nova/tree/master/nova (where he has put
up the domain quota driver). But again as i said, it was little in-complete
..and some of the functions are missing.
>

Thanks Vinod, that answers all my questions. Thank you so much for the
detail information! :)

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

[openstack-dev] [Neutron] DVR blueprint document locked / private

[Assaf Muller]

Regarding the DVR blueprint [1], I noticed that its corresponding Google Doc [2]
has been private / blocked for nearly a week now. It's very difficult to 
participate
in upstream design discussions when the document is literally locked.

I would appreciate the re-opening of the document, especially considering the 
recent
face to face meeting and the contested discussion points that were raised.

[1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
[2] 
https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit


Thank you,
Assaf Muller, Cloud Networking Engineer 
Red Hat 

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

Re: [openstack-dev] [GSoC] Participate as participant

[Damon Wang]

Hi Robber,

There are a number of discussions at OpenStack mail-list, you can find them
at mail-archive.

Hope it helps

Damon


2014-02-18 17:15 GMT+08:00 Robber Phex :

> And, should I CC this mail to OpenStack maillist?
>
>
> On Tue, Feb 18, 2014 at 5:14 PM, Robber Phex  wrote:
>
>> Hello everyone,
>>
>> I am RobberPhex, a junior in Donghua University(Shanghai, China). I want
>> to participate in GSoC this year as Student. I know that OpenStack as a
>> potential org in GSoC, so I decide to participate.
>>
>> I am a Student major in software engineering. In 2012 August, I first
>> touch OpenStack. After that, I learn OpenStack (included KVM, Python). In
>> 2013 December, I deploy OpenStack on Server.
>> For participation, in this winter vacation, I read a book that about
>> Python, and I try to write Python program (in Github).
>>
>> But, I cannot decide (sub)project to participate. If a mentor can guide
>> me with a easy or medium  difficulty project in Openstack, I would be very
>> grateful.
>>
>> BTW, I have added my name to OpenStack GSoC 2014 page.
>>
>> Thanks.
>>
>> --
>> Regards,
>> RobberPhex
>>
>> About me: http://about.me/RobberPhex
>>
>
>
>
> --
> Regards,
> RobberPhex
>
> About me: http://about.me/RobberPhex
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] libvirt doesn't migrate cdrom devices?

[Sean Dague]

On 02/18/2014 05:20 AM, Michael Still wrote:
> On Tue, Feb 18, 2014 at 3:14 AM, Daniel P. Berrange  
> wrote:
>> On Tue, Feb 18, 2014 at 03:08:59AM -0700, Michael Still wrote:
>>> On Tue, Feb 18, 2014 at 2:43 AM, Daniel P. Berrange  
>>> wrote:
>>>
 So I'd saying changing it to 'disk' is out of the question unless
 we unconditionally use vfat as the filesystem instead of iso9660.
>>>
>>> So, at the moment we conflate a flag about format (iso9660 or vfat)
>>> with a flag about device type. We could have both as separate flags
>>> with reasonable defaults. However, at the moment we're pretty much
>>> presented with a choice of either having a working Windows instance,
>>> or working block migration. I suspect that's a trade off we don't want
>>> to have to make.
>>
>> Why do we need to support both iso9660 and vfat ?  If we only cared
>> to support vfat, then we could have working Windows and working block
>> migration.
> 
> iso9660 was made the default at the request of the cloud-init author.
> IIRC the decision was based on it being a "cleaner" interface than
> vfat (read only, etc). I certainly think we could make vfat the
> default, and put a big ugly warning about iso9660 in the flag which
> lets operators select which to use.
> 
>> Incidentally since you say other virt drivers don't use cdrom, does
>> this mean they only use vfat, or are they using iso9660 + disk and
>> thus broken for windows too ?
> 
> I'm specifically thinking of hyper-v here, and I am sure they tested
> with Windows. To be honest I don't remember all the details, I just
> recall that at least one hypervisor had issues with attaching a second
> cdrom (we support boot from cdrom).

I think that's a xen limitation. I vaguely remember John Garbutt
bringing that up at a previous summit.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] time consuming of listing resource

[Mitsuru Kanabuchi]

Hi Liusheng,

We are having the same performance issues and interested in
the following bug ticket.

  https://bugs.launchpad.net/ceilometer/+bug/1264434

You said,

> As you said.both the schema level and the code level,the SQL driver in
> Ceilometer should be optimized. thanks for your advicese.I will search
> around about this.

Could you please share the current status of this work.
Do you have any specific time line for patch release?

Regards,


On Mon, 06 Jan 2014 11:12:26 -0500
Jay Pipes  wrote:

> On Mon, 2014-01-06 at 21:06 +0800, 刘胜 wrote:
> > Hi jay,Thank you for the comments, I have simply tested the
> > performance of ceilometer with mysql driver.,while,the DB table may
> > become huge in few days.Unfortunately,the result is not satisfied .
> > As you said.both the schema level and the code level,the SQL driver in
> > Ceilometer should be optimized. thanks for your advicese.I will search
> > around about this.
> 
> Hi there :) Please do let me know what performance improvements you see
> by following the steps I listed below.
> 
> All the best,
> -jay
> 
> > 
> > 在 2013-12-29 00:16:47，"Jay Pipes"  写道：
> > >On 12/28/2013 05:51 AM, 刘胜 wrote:
> > >> Hi all：
> > >> I have reported a bug about time consuming of “resource-list” in
> > >> ceilometer CLI：
> > >> https://bugs.launchpad.net/ceilometer/+bug/1264434
> > >>
> > >> In order to Identify the causes of this phenomenon, I have pdb the codes
> > >> in my invironment(configured  mysql as db driver):
> > >> the most import part of process of listing resource is implemented in
> > >> following codes:
> > >>
> > >> code of get_resources() in /ceilometer/storage/impl_sqlalchemy.py：
> > >> 
> > >>   for meter, first_ts, last_ts in query.all():
> > >>  yield api_models.Resource(
> > >>  resource_id=meter.resource_id,
> > >>  project_id=meter.project_id,
> > >>  first_sample_timestamp=first_ts,
> > >>  last_sample_timestamp=last_ts,
> > >>  source=meter.sources[0].id,
> > >>  user_id=meter.user_id,
> > >>  metadata=meter.resource_metadata,
> > >>  meter=[
> > >>  api_models.ResourceMeter(
> > >>  counter_name=m.counter_name,
> > >>  counter_type=m.counter_type,
> > >>  counter_unit=m.counter_unit,
> > >>  )
> > >> for m in meter.resource.meters
> > >>  ],
> > >>  )
> > >> The method  generate iterator of object of api_models.Resource for
> > >> ceilometer API to show.
> > >> 1.The operation “query.all()” will query the DB table “meter” with the
> > >> expression generated forward,in my invironment the DB table “meter” have
> > >> more than 30 items, so this operation may consume about 30 seconds;
> > >> 2.The operation"for m in meter.resource.meters" will circulate the
> > >> meters of this resource . a resource of server may have more than 10
> > >> meter iterms in my invironment.  So the time of whole process is too
> > >> long. I think the meter of Resource object can be reduced and I have
> > >> tested this modification, it is OK for listing resource,and reduce the
> > >> most time consumption
> > >>
> > >> I have noticed that there are many methods of db operation may time
> > >> consumption.
> > >>
> > >> ps: I have configured the ceilometer pulling interval from 600s to 60s
> > >> in /etc/ceilometer/pipeline.yaml, but the invironment has just run 10 
> > >> days!
> > >>
> > >> I'm a beginner of ceilometer,and want to fix this bug,but I haven't
> > >> found a suitable way
> > >> may be someone can help me with this?
> > >
> > >Yep. The performance of the SQL driver in Ceilometer out-of-the-box with 
> > >that particular line is unusable in our experience. We have our Chef 
> > >cookbook literally patch Ceilometer's source code and comment out that 
> > >particular line because it makes performance of Ceilometer unusable.
> > >
> > >I hate to say it, but the SQL driver in Ceilometer really needs an 
> > >overhaul, both at the schema level and the code level:
> > >
> > >On the schema level:
> > >
> > >* The indexes, especially on sourceassoc, are wrong:
> > >  ** The order of the columns in the multi-column indexes like idx_sr, 
> > >idx_sm, idx_su, idx_sp is incorrect. Columns used in predicates should 
> > >*precede* columns (like source_id) that are used in joins. The way the 
> > >indexes are structured now makes them unusable by the query optimizer 
> > >for 99% of queries on the sourceassoc table, which means any queries on 
> > >sourceassoc trigger a full table scan of the hundreds of millions of 
> > >records in the table. Things are made worse by the fact that INSERT 
> > >operations are slowed for each index on a table, and the fact that none 
> > >of these indexes are used just means we're wasting cycles on each INSERT 
> > >for no reason.
> > >  **

Re: [openstack-dev] [Neutron][LBaaS] L7 data types

[Avishay Balderman]

Here are the suggested values for the attributes below:

· Entity: L7Rule

o   Attribute: type

§  Possible values:

· HOST_NAME

· PATH

· FILE_NAME

· FILE_TYPE

· HEADER

· COOKIE

o   Attribute: compare_type

§  Possible values:

· EQUAL

· CONTAINS

· REGEX

· STARTS_WITH

· ENDS_WITH

· Entity:L7VipPolicyAssociation

o   Attribute:action

§  Possible values:

· POOL (must have pool id)

· REDIRECT(must have a url to be used as redirect destination)

· REJECT


From: Oleg Bondarev [mailto:obonda...@mirantis.com]
Sent: Monday, February 17, 2014 9:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] L7 data types

Hi,

I would add another candidate for being a closed set: 
L7VipPolicyAssociation.action (use_backend, block, etc.)

Thanks,
Oleg

On Sun, Feb 16, 2014 at 3:53 PM, Avishay Balderman 
mailto:avish...@radware.com>> wrote:
(removing extra space from the subject – let email clients apply their filters)

From: Avishay Balderman
Sent: Sunday, February 16, 2014 9:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] L7 data types

Hi
There are 2 fields in the L7 model that are candidates for being a closed set 
(Enum).
I would like to hear your opinion.

Entity:  L7Rule
Field : type
Description:  this field holds the part of the request where we should look for 
a value
Possible values: URL,HEADER,BODY,(?)

Entity:  L7Rule
Field : compare_type
Description: The way we compare the value against a given value
Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?)
Note: With REG_EXP we can cover the rest of the values.

In general In the L7rule one can express the following (Example):
“check if in the value of header named ‘Jack’  starts with X” – if this is true 
– this rule “returns” true


Thanks

Avishay

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

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

Re: [openstack-dev] [infra] reverify/recheck

[Christopher Yeoh]

On Tue, Feb 18, 2014 at 12:27 AM, Gary Kotton  wrote:

> Thanks!
> That makes sense. Just odd how a -1 was received.
>
>
So I think that now a "check" run is automatically done if the latest
Jenkins run is too old (7 days?)
This is done because gate failures are so costly. The check run failing
would return -1 instead of a
gate failure of -2.




> On 2/17/14 3:15 PM, "Akihiro Motoki"  wrote:
>
> >Hi Gary,
> >
> >According to zuul layout.yaml [1], "reverify bug #" should still work
> >but it seems to work only when verified score from jenkins is -2.
> >
> https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack-in
> >fra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml%23
> >L25&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg4
> >5MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&
> >s=8fc4d7e6970936977dc85989e4e7e9429afb15f5091a768efa4ce236417d9c9b
> >
> >Note that core team can trigger gate jobs by re-approving the patch.
> >
> >Thanks,
> >Akihiro
> >
> >(2014/02/17 22:03), Gary Kotton wrote:
> >> Hi,
> >> The "reverify no bug" was removed. But "reverify bug #" used to work.
> >>That no longer does. With the constant gate failures how can we ensure
> >>that a approved patch does a retry?
> >> Thanks
> >> Gary
> >>
> >> From: Sylvain Bauza  >>>
> >> Reply-To: "OpenStack Development Mailing List (not for usage
> >>questions)"  >>>
> >> Date: Monday, February 17, 2014 2:53 PM
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> >>>
> >> Subject: Re: [openstack-dev] [infra] reverify/recheck
> >>
> >> Hi Gary,
> >>
> >> That's normal, this command has been removed since Dec'13, see
> >>
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pip
> >>ermail/openstack-dev/2013-December/021649.html&k=oIvRg1%2BdGAgOoM1BIlLLqw
> >>%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2Fy
> >>HMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=826274ca8ad9562b557322274a
> >>cdacd97482338456820af8c330b76ea7639838
> >>
> >><
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pi
> >>permail/openstack-dev/2013-December/021649.html&k=oIvRg1%2BdGAgOoM1BIlLLq
> >>w%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=B8yQ75
> >>uRFa7dyD%2FbgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0A&s=d9cbcbde99b7c88c15ca138
> >>499de8f36edd4247ce351e41b241d675b09b79956>
> >>
> >> -Sylvain
> >>
> >>
> >> 2014-02-17 13:00 GMT+01:00 Gary Kotton  >>>:
> >>
> >> Hi,
> >> It seems that the command 'reverify bug ' is not working.
> >>Anyone else experienced this lately.
> >> Thanks
> >> Gary
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >>
> >>
> >>
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
> >>-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r
> >>=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59x
> >>Icg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=1a2a59024e18b786b5c2c13535b7f3d050363
> >>ff628dc96b8561e12489d30c0bd
> >>
> >><
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cg
> >>i-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&
> >>r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=B8yQ75uRFa7dyD%2F
> >>bgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0A&s=21e7f4ebc24f0a13780981720f9332111d
> >>d603f3c0661229dc90d82bfb5c3122>
> >>
> >>
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >>
> >>
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
> >>-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r
> >>=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59x
> >>Icg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=1a2a59024e18b786b5c2c13535b7f3d050363
> >>ff628dc96b8561e12489d30c0bd
> >>
> >___
> >OpenStack-dev mailing list
> >OpenStack-dev@lists.openstack.org
> >
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
> >bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
> >H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59xIcg
> >6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=1a2a59024e18b786b5c2c13535b7f3d050363ff62
> >8dc96b8561e12489d30c0bd
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-b

Re: [openstack-dev] [GSoC] Participate as participant

[Robber Phex]

I mean, should I CC this mail to openst...@lists.openstack.org?

Because I see this:
"Get in touch with mentors and students through the openstack-dev mailing
list" from wiki.


On Tue, Feb 18, 2014 at 6:39 PM, Damon Wang  wrote:

> Hi Robber,
>
> There are a number of discussions at OpenStack mail-list, you can find
> them at mail-archive.
>
> Hope it helps
>
> Damon
>
>
> 2014-02-18 17:15 GMT+08:00 Robber Phex :
>
>> And, should I CC this mail to OpenStack maillist?
>>
>>
>> On Tue, Feb 18, 2014 at 5:14 PM, Robber Phex wrote:
>>
>>> Hello everyone,
>>>
>>> I am RobberPhex, a junior in Donghua University(Shanghai, China). I want
>>> to participate in GSoC this year as Student. I know that OpenStack as a
>>> potential org in GSoC, so I decide to participate.
>>>
>>> I am a Student major in software engineering. In 2012 August, I first
>>> touch OpenStack. After that, I learn OpenStack (included KVM, Python). In
>>> 2013 December, I deploy OpenStack on Server.
>>> For participation, in this winter vacation, I read a book that about
>>> Python, and I try to write Python program (in Github).
>>>
>>> But, I cannot decide (sub)project to participate. If a mentor can guide
>>> me with a easy or medium  difficulty project in Openstack, I would be very
>>> grateful.
>>>
>>> BTW, I have added my name to OpenStack GSoC 2014 page.
>>>
>>> Thanks.
>>>
>>> --
>>> Regards,
>>> RobberPhex
>>>
>>> About me: http://about.me/RobberPhex
>>>
>>
>>
>>
>> --
>> Regards,
>> RobberPhex
>>
>> About me: http://about.me/RobberPhex
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
RobberPhex

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

Re: [openstack-dev] [infra] reverify/recheck

[Sergey Lukjanov]

You already can reverify on any approved change. Jenkins automatically runs
check pipeline jobs after 3 days.


On Tue, Feb 18, 2014 at 4:29 PM, Christopher Yeoh  wrote:

> On Tue, Feb 18, 2014 at 12:27 AM, Gary Kotton  wrote:
>
>> Thanks!
>> That makes sense. Just odd how a -1 was received.
>>
>>
> So I think that now a "check" run is automatically done if the latest
> Jenkins run is too old (7 days?)
> This is done because gate failures are so costly. The check run failing
> would return -1 instead of a
> gate failure of -2.
>
>
>
>
>> On 2/17/14 3:15 PM, "Akihiro Motoki"  wrote:
>>
>> >Hi Gary,
>> >
>> >According to zuul layout.yaml [1], "reverify bug #" should still work
>> >but it seems to work only when verified score from jenkins is -2.
>> >
>> https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack-in
>>
>> >fra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml%23
>>
>> >L25&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg4
>>
>> >5MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&
>> >s=8fc4d7e6970936977dc85989e4e7e9429afb15f5091a768efa4ce236417d9c9b
>> >
>> >Note that core team can trigger gate jobs by re-approving the patch.
>> >
>> >Thanks,
>> >Akihiro
>> >
>> >(2014/02/17 22:03), Gary Kotton wrote:
>> >> Hi,
>> >> The "reverify no bug" was removed. But "reverify bug #" used to work.
>> >>That no longer does. With the constant gate failures how can we ensure
>> >>that a approved patch does a retry?
>> >> Thanks
>> >> Gary
>> >>
>> >> From: Sylvain Bauza > >>>
>> >> Reply-To: "OpenStack Development Mailing List (not for usage
>> >>questions)" > >>>
>> >> Date: Monday, February 17, 2014 2:53 PM
>> >> To: "OpenStack Development Mailing List (not for usage questions)"
>> >>> >>>
>> >> Subject: Re: [openstack-dev] [infra] reverify/recheck
>> >>
>> >> Hi Gary,
>> >>
>> >> That's normal, this command has been removed since Dec'13, see
>> >>
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pip
>>
>> >>ermail/openstack-dev/2013-December/021649.html&k=oIvRg1%2BdGAgOoM1BIlLLqw
>>
>> >>%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2Fy
>>
>> >>HMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=826274ca8ad9562b557322274a
>> >>cdacd97482338456820af8c330b76ea7639838
>> >>
>> >><
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pi
>>
>> >>permail/openstack-dev/2013-December/021649.html&k=oIvRg1%2BdGAgOoM1BIlLLq
>>
>> >>w%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=B8yQ75
>>
>> >>uRFa7dyD%2FbgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0A&s=d9cbcbde99b7c88c15ca138
>> >>499de8f36edd4247ce351e41b241d675b09b79956>
>> >>
>> >> -Sylvain
>> >>
>> >>
>> >> 2014-02-17 13:00 GMT+01:00 Gary Kotton > >>>:
>> >>
>> >> Hi,
>> >> It seems that the command 'reverify bug ' is not working.
>> >>Anyone else experienced this lately.
>> >> Thanks
>> >> Gary
>> >>
>> >> ___
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev@lists.openstack.org
>> >>
>> >>
>> >>
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
>>
>> >>-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r
>>
>> >>=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59x
>>
>> >>Icg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=1a2a59024e18b786b5c2c13535b7f3d050363
>> >>ff628dc96b8561e12489d30c0bd
>> >>
>> >><
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cg
>>
>> >>i-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&
>>
>> >>r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=B8yQ75uRFa7dyD%2F
>>
>> >>bgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0A&s=21e7f4ebc24f0a13780981720f9332111d
>> >>d603f3c0661229dc90d82bfb5c3122>
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev@lists.openstack.org
>> >>
>> >>
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
>>
>> >>-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r
>>
>> >>=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59x
>>
>> >>Icg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=1a2a59024e18b786b5c2c13535b7f3d050363
>> >>ff628dc96b8561e12489d30c0bd
>> >>
>> >___
>> >OpenStack-dev mailing list
>> >OpenStack-dev@lists.openstack.org
>> >
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
>>
>> >bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
>>
>> >H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59xIcg
>>
>> >6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=1a2a59024e18b786b5c2c13535b7f3d050363

Re: [openstack-dev] [savanna] plugin version or hadoop version?

[Sergey Lukjanov]

Matt,

thanks, I'm agree with hadoop_version to version transition in v2 api.


On Tue, Feb 18, 2014 at 5:02 AM, Matthew Farrellee  wrote:

> ok, i spent a little time looking at what the change impacts and it looks
> like all the template validations we have currently require hadoop_version.
> additionally, the client uses the name and documentation references it.
>
> due to the large number of changes and the difficulty in providing
> backward compatibility, i propose that we leave it as is for the v1 api &
> client and we change it for the v2 api & client.
>
> to that end, i've added 'verifying hadoop_version -> version' as a work
> item for both the v2-api-impl and v2-client.
>
> https://blueprints.launchpad.net/savanna/+spec/v2-api-impl
>
> and
>
> https://blueprints.launchpad.net/python-savannaclient/+spec/v2-client
>
> best,
>
>
> matt
>
>
> On 02/17/2014 04:23 PM, Alexander Ignatov wrote:
>
>> Agree to rename this legacy field to 'version'. Adding to John's words
>> about HDP, Vanilla plugin is able to run different hadoop versions by
>> doing some manipulations with DIB scripts :-) So the right name of this
>> field should be 'version' as version of engine of concrete plugin.
>>
>> Regards,
>> Alexander Ignatov
>>
>>
>>
>> On 18 Feb 2014, at 01:01, John Speidel > > wrote:
>>
>>  Andrew +1
>>>
>>> The HDP plugin also returns the HDP distro version.  The version needs
>>> to make sense in the context of the plugin.
>>> Also, many plugins including the HDP plugin will support deployment of
>>> several hadoop versions.
>>>
>>> -John
>>>
>>>
>>> On Mon, Feb 17, 2014 at 2:36 PM, Andrew Lazarev >> > wrote:
>>>
>>> IDH uses version of IDH distro and there is no direct mapping
>>> between distro version and hadoop version. E.g. IDH 2.5.1 works
>>> with apache hadoop 1.0.3.
>>>
>>> I suggest to call the field as just 'version' everywhere and
>>> assume this version as plugin specific property.
>>>
>>> Andrew.
>>>
>>>
>>> On Mon, Feb 17, 2014 at 5:06 AM, Matthew Farrellee
>>> mailto:m...@redhat.com>> wrote:
>>>
>>> $ savanna plugins-list
>>> +-+--+__---+
>>> | name| versions | title |
>>> +-+--+__---+
>>>
>>> | vanilla | 1.2.1| Vanilla Apache Hadoop |
>>> | hdp | 1.3.2| Hortonworks Data Platform |
>>> +-+--+__---+
>>>
>>>
>>> above is output from the /plugins endpoint -
>>> http://docs.openstack.org/__developer/savanna/userdoc/__
>>> rest_api_v1.0.html#plugins
>>>
>>> >> rest_api_v1.0.html#plugins>
>>>
>>> the question is, should the version be the version of the
>>> plugin or the version of hadoop the plugin installs?
>>>
>>> i ask because it seems like we have version == plugin version
>>> for hdp and version == hadoop version for vanilla.
>>>
>>> the documentation is somewhat vague on the subject, mostly
>>> stating "version" without qualification. however, the json
>>> passed to the service references "hadoop_version" and the
>>> arguments in the client are called "hadoop_version"
>>>
>>> fyi, this could be complicated by the idh and spark plugins.
>>>
>>> best,
>>>
>>>
>>> matt
>>>
>>> _
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.__org
>>> 
>>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__
>>> openstack-dev
>>>
>>> >> openstack-dev>
>>>
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> 
>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE
>>> NOTICE: This message is intended for the use of the individual or
>>> entity to which it is addressed and may contain information that is
>>> confidential, privileged and exempt from disclosure under applicable
>>> law. If the reader of this message is not the intended recipient, you
>>> are hereby notified that any printing, copying, dissemination,
>>> distribution, disclosure or forwarding of this communication is
>>> strictly prohibited. If you have received this communication in error,
>>> please contact the sender immediately and delete it from your system.
>>> Thank You.___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> 
>>> http://lists.openstack.org/cgi-bi

Re: [openstack-dev] [GSoC] Participate as participant

[Davanum Srinivas]

Robber,

Adding your name in wiki is good, we have prepared the organization
application for OpenStack Foundation and submitted it. We will hear
from them in on 24th
(http://www.google-melange.com/gsoc/events/google/gsoc2013) if
OpenStack Foundation has been accepted into the GSoC program or not.

-- dims

On Tue, Feb 18, 2014 at 7:32 AM, Robber Phex  wrote:
> I mean, should I CC this mail to openst...@lists.openstack.org?
>
> Because I see this:
> "Get in touch with mentors and students through the openstack-dev mailing
> list" from wiki.
>
>
> On Tue, Feb 18, 2014 at 6:39 PM, Damon Wang  wrote:
>>
>> Hi Robber,
>>
>> There are a number of discussions at OpenStack mail-list, you can find
>> them at mail-archive.
>>
>> Hope it helps
>>
>> Damon
>>
>>
>> 2014-02-18 17:15 GMT+08:00 Robber Phex :
>>>
>>> And, should I CC this mail to OpenStack maillist?
>>>
>>>
>>> On Tue, Feb 18, 2014 at 5:14 PM, Robber Phex 
>>> wrote:

 Hello everyone,

 I am RobberPhex, a junior in Donghua University(Shanghai, China). I want
 to participate in GSoC this year as Student. I know that OpenStack as a
 potential org in GSoC, so I decide to participate.

 I am a Student major in software engineering. In 2012 August, I first
 touch OpenStack. After that, I learn OpenStack (included KVM, Python). In
 2013 December, I deploy OpenStack on Server.
 For participation, in this winter vacation, I read a book that about
 Python, and I try to write Python program (in Github).

 But, I cannot decide (sub)project to participate. If a mentor can guide
 me with a easy or medium  difficulty project in Openstack, I would be very
 grateful.

 BTW, I have added my name to OpenStack GSoC 2014 page.

 Thanks.

 --
 Regards,
 RobberPhex

 About me: http://about.me/RobberPhex
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> RobberPhex
>>>
>>> About me: http://about.me/RobberPhex
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> RobberPhex
>
> About me: http://about.me/RobberPhex
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com

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

Re: [openstack-dev] [infra] reverify/recheck

[Sean Dague]

We're still working through kinks in the new system, which is why it's
not fully documented yet.

During the 2 weeks of gate wedging in January, we discovered a number of
interesting things. Some review teams are really slow at dealing with
patches with a +2 already on them, and may wait 2 - 6 *weeks* before a
second core reviewer shows up to approve. In that period of time the
dependencies used in the tests probably changed 3 or 4 times. Which
means the test results were invalid.

We also found that once a patch gets a +A people (core and non-core)
blindly reverify on any failure, over and over and over again. I saw one
core developer "reverify 123456789" on a patch.

Or that when trying to land a patch people will recheck half a dozen
times to get one clean run, then get their patch pushed to the gate.

All this blind meatgrinder behavior was putting tons of code into the
gate that could not pass. That, coupled with other race conditions we
were dealing with, put us into a state where we had a 60hr gate queue.

So we're trying out a new system. A change will not move into the gate
unless there is both a +A and Jenkins +1 on the patch.

We also rerun check results on comment if the test results are > 72hrs
old, so there is always a reasonably fresh version of the results. This
also helps detect merge conflicts early.

Also when you +A a patch, if there aren't 24hr fresh test results, we
rerun check first, then if that passes, it gets sent to the gate.

There is still a bit of a sticky part of the flow if it fails in the
gate. Because that means you don't satisfy the +1 jenkins requirement.
Still trying to get the right flow worked out there.

-Sean

On 02/18/2014 07:51 AM, Sergey Lukjanov wrote:
> You already can reverify on any approved change. Jenkins automatically
> runs check pipeline jobs after 3 days.
> 
> 
> On Tue, Feb 18, 2014 at 4:29 PM, Christopher Yeoh  > wrote:
> 
> On Tue, Feb 18, 2014 at 12:27 AM, Gary Kotton  > wrote:
> 
> Thanks!
> That makes sense. Just odd how a -1 was received.
> 
> 
> So I think that now a "check" run is automatically done if the
> latest Jenkins run is too old (7 days?)
> This is done because gate failures are so costly. The check run
> failing would return -1 instead of a
> gate failure of -2.
> 
> 
>  
> 
> On 2/17/14 3:15 PM, "Akihiro Motoki"  > wrote:
> 
> >Hi Gary,
> >
> >According to zuul layout.yaml [1], "reverify bug #" should
> still work
> >but it seems to work only when verified score from jenkins is -2.
> 
> >https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack-in
> 
> >fra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml%23
> 
> >L25&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg4
> 
> >5MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&
> >s=8fc4d7e6970936977dc85989e4e7e9429afb15f5091a768efa4ce236417d9c9b
> >
> >Note that core team can trigger gate jobs by re-approving the
> patch.
> >
> >Thanks,
> >Akihiro
> >
> >(2014/02/17 22:03), Gary Kotton wrote:
> >> Hi,
> >> The "reverify no bug" was removed. But "reverify bug #" used
> to work.
> >>That no longer does. With the constant gate failures how can
> we ensure
> >>that a approved patch does a retry?
> >> Thanks
> >> Gary
> >>
> >> From: Sylvain Bauza  
> >>>>
> >> Reply-To: "OpenStack Development Mailing List (not for usage
> >>questions)"  
> >> >>
> >> Date: Monday, February 17, 2014 2:53 PM
> >> To: "OpenStack Development Mailing List (not for usage
> questions)"
> >> 
> >> >>
> >> Subject: Re: [openstack-dev] [infra] reverify/recheck
> >>
> >> Hi Gary,
> >>
> >> That's normal, this command has been removed since Dec'13, see
> 
> >>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pip
> 
> >>ermail/openstack-dev/2013-December/021649.html&k=oIvRg1%2BdGAgOoM1BIlLLqw
> 
> >>%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2Fy
> 
> >>HMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=826274ca8ad9562b557322274a
> >>cdacd97482338456820af8c330b76ea7639838
> >>
> 
> >><

Re: [openstack-dev] [qa][tempest][rally] Rally & Tempest integration: tempest.conf autogeneration

[Frittoli, Andrea (Cloud Services)]

+1 for decoupling Tempest from devstack

 

Openstack deployment tool is TripleO / Heat -so it would be good to have an
Heat template to deploy and configure Tempest

 

andrea

 

From: David Kranz [mailto:dkr...@redhat.com] 
Sent: 12 February 2014 23:23
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [qa][tempest][rally] Rally & Tempest
integration: tempest.conf autogeneration

 

On 02/12/2014 05:55 PM, Sean Dague wrote:

On 02/12/2014 05:08 PM, Boris Pavlovic wrote:

Hi all, 
 
It goes without saying words that actually tempest[1] is only one public
known tool that could fully verify deployments and ensure dthat they work.
 
In Rally[2] we would like to use it as a cloud verifier (before
benchmarking it is actually very useful;) to ensure that cloud work). We
are going to build on top of tempest pretty interface and aliases &
support of working with different clouds. E.g.: 
 
rally use deployment  # use some deployment that is registered in
Rally
rally verify nova # Run only nova tests against `in-use` deployment 
rally verify small/big/full # set of tests
rally verify list # List all verification results for this deployment
rally verify show  # Show detailed information
# Okay we found that something failed, fixed it in cloud, restart
service and we would like you to run only failed tests
rally verify latest_failed # do it in one simple command
 
These commands should be very smart, generate proper tempest.conf for
specific cloud, prepare cloud for tempest testing, store somewhere
results and so on and so on. So at the end we will have very simple way
to work with tempest. 
 
We added first patch that adds base functionality to Rally [3]: 
https://review.openstack.org/#/c/70131/
 
At QA meeting I discussed it with David Kranz, as a result we agree that 
part of this functionality (tempest.conf generator & cloud prepare),
should be implemented inside tempest.
 
Current situation is not super cool because, there are at least 4
projects where we are generating in different way tempest.conf: 
1) DevStack
2) Fuel CI
3) Rally
4) Tempest (currently broken)
 
 
To put it in a nutshell, it's clear that we should make only 1
tempest.conf generator [4], that will cover all cases, and will be
enough simple to be used in all other projects. 

 
So in the past the issue was we could never get anyone to agree on one.
For instance, devstack makes some really fine grained decisions, and the
RDO team showed up with a very different answer file approach, which
wouldn't work for devstack (it had the wrong level of knob changing).
 
And if the end of the day you replace build a tempest config generator,
which takes 200 options, I'm not entirely sure how that was better than
just setting those 200 options directly.
 
So while happy to consider options here, realize that there is a reason
this has been punted before.
 
   -Sean

I have thought about this and think we can do better. I will present a spec
when I get a chance if no one else does. I would leave devstack out
of it, at least for now. In general it would be good to decouple tempest
from devstack a little more, especially as it gains wider use in rally,
refstack, etc. For example, there are default paths and stuff in
tempest.conf.sample that refer to files that are only put there by devstack.

 -David



 
 






___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][all] Keystone V2 and V3 support in icehouse

[Dolph Mathews]

On Mon, Feb 10, 2014 at 5:23 PM, Frittoli, Andrea (Cloud Services) <
fritt...@hp.com> wrote:

> Hi,
>
>
>
> I’m working on a tempest blueprint to make tempest able to run 100% on
> keystone v3 (or later versions) – the auth version to be used will be
> available via a configuration switch.
>

>
> The rationale is that Keystone V2 is deprecated in icehouse, V3 being the
> primary version. Thus it would be good to have (at least) one of the  gate
> jobs running entirely with keystone v3.
>

Much appreciated! Have a link to that bp?


>
>
> There are other components beyond tempest that would need some changes to
> make this happen.
>
>
>
> Nova and cinder python bindings work only with keystone v2 [0], and as far
> as I know all core services work with keystone v2 (at least by default).
>
> Is there a plan to support identity v3 there until the end of icehouse?
>

Yes (but maybe not by the end of icehouse)- we'd like to make all other
client libraries depend on keystoneclient's library for authentication in
the long run. Jamie Lennox has done a ton of great work to prepare
keystoneclient for that responsibility during Icehouse.


>  If not I think we may have to consider still supporting v2 in icehouse.
>

v2 should certainly be supported in icehouse; which version other projects
default to is up to them, but I'd like to see *all* projects at least
defaulting to v3 by the end of Juno.


>
>
> Andrea
>
>
>
> [0] https://bugs.launchpad.net/python-novaclient/+bug/1262843
>
>
>
> --
>
> Andrea Frittoli
>
> IaaS Systems Engineering Team
>
> HP Cloud ☁
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] reverify/recheck

[Christopher Yeoh]

On Tue, Feb 18, 2014 at 11:52 PM, Sean Dague  wrote:

>
> All this blind meatgrinder behavior was putting tons of code into the
> gate that could not pass. That, coupled with other race conditions we
> were dealing with, put us into a state where we had a 60hr gate queue.
>
> So we're trying out a new system. A change will not move into the gate
> unless there is both a +A and Jenkins +1 on the patch.
>
> We also rerun check results on comment if the test results are > 72hrs
> old, so there is always a reasonably fresh version of the results. This
> also helps detect merge conflicts early.
>
>
Thanks for the update Sean. I think the check re-run currently gets done
even if the new comment is a -2. Perhaps we could skip
it in that case?

Also when you +A a patch, if there aren't 24hr fresh test results, we
> rerun check first, then if that passes, it gets sent to the gate.
>
> There is still a bit of a sticky part of the flow if it fails in the
> gate. Because that means you don't satisfy the +1 jenkins requirement.
> Still trying to get the right flow worked out there.
>
> -Sean
>
> On 02/18/2014 07:51 AM, Sergey Lukjanov wrote:
> > You already can reverify on any approved change. Jenkins automatically
> > runs check pipeline jobs after 3 days.
> >
> >
> > On Tue, Feb 18, 2014 at 4:29 PM, Christopher Yeoh  > > wrote:
> >
> > On Tue, Feb 18, 2014 at 12:27 AM, Gary Kotton  > > wrote:
> >
> > Thanks!
> > That makes sense. Just odd how a -1 was received.
> >
> >
> > So I think that now a "check" run is automatically done if the
> > latest Jenkins run is too old (7 days?)
> > This is done because gate failures are so costly. The check run
> > failing would return -1 instead of a
> > gate failure of -2.
> >
> >
> >
> >
> > On 2/17/14 3:15 PM, "Akihiro Motoki"  > > wrote:
> >
> > >Hi Gary,
> > >
> > >According to zuul layout.yaml [1], "reverify bug #" should
> > still work
> > >but it seems to work only when verified score from jenkins is
> -2.
> > >
> https://urldefense.proofpoint.com/v1/url?u=https://github.com/openstack-in
> >
> >fra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml%23
> >
> >L25&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg4
> >
> >5MkPhCZFxPEq8%3D%0A&m=Nf6%2FyHMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&
> >
> >s=8fc4d7e6970936977dc85989e4e7e9429afb15f5091a768efa4ce236417d9c9b
> > >
> > >Note that core team can trigger gate jobs by re-approving the
> > patch.
> > >
> > >Thanks,
> > >Akihiro
> > >
> > >(2014/02/17 22:03), Gary Kotton wrote:
> > >> Hi,
> > >> The "reverify no bug" was removed. But "reverify bug #" used
> > to work.
> > >>That no longer does. With the constant gate failures how can
> > we ensure
> > >>that a approved patch does a retry?
> > >> Thanks
> > >> Gary
> > >>
> > >> From: Sylvain Bauza  > 
> > >>>>
> > >> Reply-To: "OpenStack Development Mailing List (not for usage
> > >>questions)"  > 
> > >> > >>
> > >> Date: Monday, February 17, 2014 2:53 PM
> > >> To: "OpenStack Development Mailing List (not for usage
> > questions)"
> > >> > 
> > >> > >>
> > >> Subject: Re: [openstack-dev] [infra] reverify/recheck
> > >>
> > >> Hi Gary,
> > >>
> > >> That's normal, this command has been removed since Dec'13, see
> > >>
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pip
> >
> >>ermail/openstack-dev/2013-December/021649.html&k=oIvRg1%2BdGAgOoM1BIlLLqw
> >
> >>%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=Nf6%2Fy
> >
> >>HMSSchQO59xIcg6NKX1O2wlkkHHd42bYQim0k0%3D%0A&s=826274ca8ad9562b557322274a
> > >>cdacd97482338456820af8c330b76ea7639838
> > >>
> > >><
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pi
> >
> >>permail/openstack-dev/2013-December/021649.html&k=oIvRg1%2BdGAgOoM1BIlLLq
> >
> >>w%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=B8yQ75
> >
> >>uRFa7dyD%2FbgPgO%2FMT2x229MkK1vHWBVAzpFtM%3D%0A&s=d9cbcbde99b7c88c15ca138
> > >>499de8f36edd4247ce351e41b241d675b09b79956>
> > >>
> > >> -Sylvain
> > >>
> > >>
> > >> 2014-02-17 13:00 GMT+01:00 Gary Kotton  

Re: [openstack-dev] [Murano] Repositoris re-organization

[Ruslan Kamaldinov]

I'd suggest to reduce number of Murano repositories for several reasons:

* All other OpenStack projects have a single repo per project. While this
point might look like something not worth mentioning, it's really important:
- unified project structure simplifies life for new developers. once they
get familiar with one project, they can expect something similar from
another project
- unified project structure simplifies life for deployers. similar project
structure simplifies packaging and deployment automation

* Another important reason is to simplify gated testing. Just take a look at
Solum layout [1], they have everything needed (contrib, functionaltests) to
run dvsm job in a single repo. One simple job definition [2] allows to
install Solum in DevStack and run Tempest tests for Solum.

* As a side-effect, this approach will improve integrity of project
components. Having murano-common in the same repo with other components will
help to catch integration issues earlier.


In an ideal world there will be only the following repos:
- murano (api, common, conductor, docs, repository, tests)
- python-muranoclient
- murano-dashboard
- murano-agent
- puppet-murano (optional, but nice to have)


[1] https://github.com/stackforge/solum
[2]
https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/solum.yaml


Thanks,
Ruslan


On Thu, Feb 6, 2014 at 3:14 PM, Serg Melikyan wrote:

> Hi, Alexander,
>
> In general I am completely agree with Clint and Robert, and as one of
> contributors of Murano I don't see any practical reasons for repositories
> reorganization. And regarding of your proposal I have a few thoughts that I
> would like to share below:
>
> >This enourmous amount of repositories adds too much infrustructural
> complexity
> Creating a new repository is a quick, easy and completely automated
> procedure that requires only simple commit to Zuul configuration. All
> infrastructure related to repositories is handled by Openstack CI and
> supported by Openstack Infra Team, and actually don't require anything from
> project development team. About what infrastructure complexity you are
> talking about?
>
> >I actually think keeping them separate is a great way to make sure you
> have ongoing API stability. (c) Clint
> I would like to share a little statistic gathered by Stan Lagun
> a little time ago regarding repositories count in different PaaS solution.
> If you are concerned about large number of repositories used by Murano, you
> will be quite amused:
>
>- https://github.com/heroku - 275
>- https://github.com/cloudfoundry - 132
> - https://github.com/openshift - 49
>- https://github.com/CloudifySource - 46
>
> >First of all, I would suggest to have a single reposository for all the
> three main components of Murano: main murano API (the contents of the
> present), workflow execution engine (currently murano-conductor; also it
> was suggested to rename the component itself to murano-engine for more
> consistent naming) and metadata repository (currently murano-repository).
>
> *murano-api* and *murano-repository* have many things in common, they are
> both present HTTP API to the user, and I hope would be rewritten to common
> framework (Pecan?). But *murano-conductor* have only one thing in common
> with other two components: code shared under *murano-common*. That
> repository may be eventually eliminated by moving to Oslo (as it should be
> done).
>
> >Also, it has been suggested to move our agents (both windows and unified
> python) into the main repository as well - just to put them into a separate
> subfolder. I don't see any reasons why they should be separated from core
> Murano: I don't believe we are going to have any third-party
> implementations of our "Unified agent" proposals, while this possibility
> was the main reason for separatinng them.
>
> Main reason for murano-agent to have separate repository was not a
> possibility to have another implementation, but that all sources that
> should be able to be built as package, have tests and can be uploaded to
> PyPI (or any other gate job) should be placed in different repository.
> OpenStack CI have several rules regarding how repositories should be
> organized to support running different gate jobs. For example, to run tests
> *tox.ini* is need to be present in root directory, to build package
> *setup.py* should be present in root directory. So we could not simply
> move them to separate directories in main repository and have same
> capabilities as in separate repository.
>
> >Next, deployment scripts and auto-generated docs: are there reasons why
> they should be in their own repositories, instead of "docs" and
> "tools/deployment" folders of the primary repo? I would prefer the latter:
> docs and deployment scripts have no meaning without the sources which they
> document/deploy - so it is better to have them consistent.
> We have *developers documentation* alongside

Re: [openstack-dev] Glance v1 and v2

[Flavio Percoco]

On 18/02/14 10:57 +0100, Joe Hakim Rahme wrote:

I have only played with Glance v2 locally on a devstack, so take what I write
with a graing of salt.

What's new in API v2?
-

+ registry: You don't need to run glance-registry anymore. Unless you still
support v1.


You can still run it for V2, it's just optional.



+ tags: Every image has a tag list metadata. A tag can be
created/updated/deleted by an image owner. A tag can be read by any member of
the image.

+ New membership mechanism: You can read about it here[1].

+ You can query the API for JSON schemas describing resources.


How well is it supported?
-

+ python-glanceclient: Supports API v2 through the cli flag  
--os-image-api-version.

+ Cinder: Supports API v2 (for volume creation from images). You specify the API
version in cinder.conf (glance_api_version option).


It's worth noting that you can't upload images to Cinder - meaning,
create volumes by uploading images to Glance - yet.

--
@flaper87
Flavio Percoco


pgp64T1frieP4.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [solum] Question about solum-minimal-cli BP

[Shaunak Kashyap]

Thanks Angus and Devdatta. I think I understand.

Angus -- what you said seems to mirror the Heroku CLI usage: a) User runs 
"app/plan create" (to create the remote repo), then b) user runs "git push ..." 
(which pushes the code to the remote repo and creates 1 assembly, resulting in 
a running application). If this is the intended flow for the user, it makes 
sense to me.

One follow up question: under what circumstances will the user need to 
explicitly run "assembly create"? Would it be used exclusively for adding more 
assemblies to an already running app?

Thanks,

Shaunak


From: Angus Salkeld [angus.salk...@rackspace.com]
Sent: Monday, February 17, 2014 5:54 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [solum] Question about solum-minimal-cli BP

On 17/02/14 21:47 +, Shaunak Kashyap wrote:
>Hey folks,
>
>I was reading through 
>https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/CLI-minimal-implementation
> and have a question.
>
>If I’m understanding “app create” and “assembly create” correctly, the user 
>will have to run “app create” first, followed by “assembly create” to have a 
>running application. Is this correct? If so, what is the reason for “app 
>create” not automatically creating one assembly as well?

On that page it seems that "app create" is the same as "plan create".

The only reason I can see for seperating the plan from the assembly is
when you have "git-push".
Then you need to have something create the git repo for you.

1 plan create (with a reference to a git-push requirement) would create
   the remote git repo for you.
2 you clone and populate the repo with your app code
3 you push, and that causes the assembly create/update.

Adrian might want to correct my here tho'

-Angus

>
>Thanks,
>Shaunak

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


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

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

[openstack-dev] [QA] Service dependency decorators in tests

[Frittoli, Andrea (Cloud Services)]

Hi all,

 

Scenario tests feature service dependency decorators in tests – so that a test 
will run only if all required components are available.

I think we should extend them to all tests, including the API ones. For 
instance Nova image tests depend on Glance, cinder attach/detach tests depend 
on Nova.

 

If there is agreement on that I’d happy to start a bp to track the test tagging 
effort.

 

andrea

 

-- 

Andrea Frittoli

IaaS Systems Engineering Team 

HP Cloud ☁

PC Phone: +445601090317

 



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Network] Allocate MAC and IP address for a VM instance

[Jay Lau]

Greetings,

Not sure if it is suitable to ask this question in openstack-dev list. Here
come a question related to network and want to get some input or comments
from you experts.

My case is as this: For some security issue, I want to put both MAC and
internal IP address to a pool and when create VM, I can get MAC and its
mapped IP address and assign the MAC and IP address to the VM.

For example, suppose I have following MAC and IP pool:
1) 78:2b:cb:af:78:b0, 192.168.0.10
2) 78:2b:cb:af:78:b1, 192.168.0.11
3) 78:2b:cb:af:78:b2, 192.168.0.12
4) 78:2b:cb:af:78:b3, 192.168.0.13

Then I can create four VMs using above MAC and IP address, each row in
above can be mapped to a VM.

Does any of you have any idea for the solution of this?

-- 
Thanks,

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

Re: [openstack-dev] [QA] Service dependency decorators in tests

[Sean Dague]

I'm +1 on that. Mostly it's just a lot of time, so hasn't been dealt
with yet. Unless there is a completely pressing need, I'd rather see
that happen right after icehouse release, because I'm concerned it will
be a lot of changes coming in when people are trying to get other more
critical things landed.

-Sean

On 02/18/2014 09:33 AM, Frittoli, Andrea (Cloud Services) wrote:
> Hi all,
> 
>  
> 
> Scenario tests feature service dependency decorators in tests – so that
> a test will run only if all required components are available.
> 
> I think we should extend them to all tests, including the API ones. For
> instance Nova image tests depend on Glance, cinder attach/detach tests
> depend on Nova.
> 
>  
> 
> If there is agreement on that I’d happy to start a bp to track the test
> tagging effort.
> 
>  
> 
> andrea
> 
>  
> 
> -- 
> 
> Andrea Frittoli
> 
> IaaS Systems Engineering Team
> 
> HP Cloud ☁
> 
> PC Phone: +445601090317
> 
>  
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] Service dependency decorators in tests

[Jay Pipes]

On Tue, 2014-02-18 at 14:33 +, Frittoli, Andrea (Cloud Services)
wrote:
> Hi all,
> 
> Scenario tests feature service dependency decorators in tests – so
> that a test will run only if all required components are available.
> 
> I think we should extend them to all tests, including the API ones.
> For instance Nova image tests depend on Glance, cinder attach/detach
> tests depend on Nova.
> 
> If there is agreement on that I’d happy to start a bp to track the
> test tagging effort.

++

Best,
-jay



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

[openstack-dev] [Heat] lazy translation is breaking Heat

[Christopher Armstrong]

This change was recently merged:

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

Unfortunately it didn't enable lazy translations for the unit tests, so it
didn't catch the many places in Heat that won't work when lazy translations
are enabled. Notably there are a lot of cases where the code adds the
result of a call to _() with another string, and Message objects (which are
returned from _ when lazy translations are enabled) can't be added,
resulting in an exception being raised.

I think the best course of action would be to revert this change, and then
reintroduce it along with patches to fix all the problems, while enabling
it for the unit tests so bugs won't be reintroduced in the future.

Interestingly it also didn't fail any of the tempest tests, I'm not sure
why.

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

Re: [openstack-dev] [Murano] Repositoris re-organization

[Alexander Tivelkov]

Hi Ruslan,

Thanks for your feedback. I completely agree with these arguments:
actually, these were the reasons why I've initiated this discussion.

Team, let's discuss this on the IRC meeting today.

--
Regards,
Alexander Tivelkov


On Tue, Feb 18, 2014 at 5:55 PM, Ruslan Kamaldinov  wrote:

> I'd suggest to reduce number of Murano repositories for several reasons:
>
> * All other OpenStack projects have a single repo per project. While this
> point might look like something not worth mentioning, it's really
> important:
> - unified project structure simplifies life for new developers. once they
> get familiar with one project, they can expect something similar from
> another project
> - unified project structure simplifies life for deployers. similar project
> structure simplifies packaging and deployment automation
>
> * Another important reason is to simplify gated testing. Just take a look
> at
> Solum layout [1], they have everything needed (contrib, functionaltests) to
> run dvsm job in a single repo. One simple job definition [2] allows to
> install Solum in DevStack and run Tempest tests for Solum.
>
> * As a side-effect, this approach will improve integrity of project
> components. Having murano-common in the same repo with other components
> will
> help to catch integration issues earlier.
>
>
> In an ideal world there will be only the following repos:
> - murano (api, common, conductor, docs, repository, tests)
> - python-muranoclient
> - murano-dashboard
> - murano-agent
> - puppet-murano (optional, but nice to have)
>
>
> [1] https://github.com/stackforge/solum
> [2]
> https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/solum.yaml
>
>
> Thanks,
> Ruslan
>
>
> On Thu, Feb 6, 2014 at 3:14 PM, Serg Melikyan wrote:
>
>> Hi, Alexander,
>>
>> In general I am completely agree with Clint and Robert, and as one of
>> contributors of Murano I don't see any practical reasons for repositories
>> reorganization. And regarding of your proposal I have a few thoughts that I
>> would like to share below:
>>
>> >This enourmous amount of repositories adds too much infrustructural
>> complexity
>> Creating a new repository is a quick, easy and completely automated
>> procedure that requires only simple commit to Zuul configuration. All
>> infrastructure related to repositories is handled by Openstack CI and
>> supported by Openstack Infra Team, and actually don't require anything from
>> project development team. About what infrastructure complexity you are
>> talking about?
>>
>> >I actually think keeping them separate is a great way to make sure you
>> have ongoing API stability. (c) Clint
>> I would like to share a little statistic gathered by Stan Lagun
>> a little time ago regarding repositories count in different PaaS solution.
>> If you are concerned about large number of repositories used by Murano, you
>> will be quite amused:
>>
>>- https://github.com/heroku - 275
>>- https://github.com/cloudfoundry - 132
>> - https://github.com/openshift - 49
>>- https://github.com/CloudifySource - 46
>>
>> >First of all, I would suggest to have a single reposository for all the
>> three main components of Murano: main murano API (the contents of the
>> present), workflow execution engine (currently murano-conductor; also it
>> was suggested to rename the component itself to murano-engine for more
>> consistent naming) and metadata repository (currently murano-repository).
>>
>> *murano-api* and *murano-repository* have many things in common, they
>> are both present HTTP API to the user, and I hope would be rewritten to
>> common framework (Pecan?). But *murano-conductor* have only one thing in
>> common with other two components: code shared under *murano-common*.
>> That repository may be eventually eliminated by moving to Oslo (as it
>> should be done).
>>
>> >Also, it has been suggested to move our agents (both windows and
>> unified python) into the main repository as well - just to put them into a
>> separate subfolder. I don't see any reasons why they should be separated
>> from core Murano: I don't believe we are going to have any third-party
>> implementations of our "Unified agent" proposals, while this possibility
>> was the main reason for separatinng them.
>>
>> Main reason for murano-agent to have separate repository was not a
>> possibility to have another implementation, but that all sources that
>> should be able to be built as package, have tests and can be uploaded to
>> PyPI (or any other gate job) should be placed in different repository.
>> OpenStack CI have several rules regarding how repositories should be
>> organized to support running different gate jobs. For example, to run tests
>> *tox.ini* is need to be present in root directory, to build package
>> *setup.py* should be present in root directory. So we could not simply
>> move them to separate directories in main repository and have same
>> capabilities as in s

Re: [openstack-dev] [QA] Service dependency decorators in tests

[Matthew Treinish]

On Tue, Feb 18, 2014 at 09:42:43AM -0500, Sean Dague wrote:
> I'm +1 on that. Mostly it's just a lot of time, so hasn't been dealt
> with yet. Unless there is a completely pressing need, I'd rather see
> that happen right after icehouse release, because I'm concerned it will
> be a lot of changes coming in when people are trying to get other more
> critical things landed.

Yeah I agree with this too, however we said the same thing after havana
regarding service tags.

> 
>   -Sean
> 
> On 02/18/2014 09:33 AM, Frittoli, Andrea (Cloud Services) wrote:
> > Hi all,
> > 
> >  
> > 
> > Scenario tests feature service dependency decorators in tests – so that
> > a test will run only if all required components are available.
> > 
> > I think we should extend them to all tests, including the API ones. For
> > instance Nova image tests depend on Glance, cinder attach/detach tests
> > depend on Nova.

So originally the service tag decorator just added an attr and the intent was
to just make it easy to filter by service. So, we only were adding the decorator
to tests that touched the service that weren't in the namespace.
For example:

tests in: api.compute.image would not get an image tag

but if a test in: api.compute.volume touched glance then it should have the
decorator.

But, it was only recently that I added the skip function to the decorator
because it made sense to. I still think we should follow the same convention
for using the services decorators, even with skips as part of the decorator. 
For the tests in directories that contain a service name we should raise skips
for that service in the explicity. Since the directory calls out the service it
should be implied that it's required so we don't need to bother tagging all the
tests.

> > 
> >  
> > 
> > If there is agreement on that I’d happy to start a bp to track the test
> > tagging effort.

There has been one open since havana :)
https://blueprints.launchpad.net/tempest/+spec/add-service-tags

-Matt Treinish


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

Re: [openstack-dev] [infra] reverify/recheck

[James E. Blair]

Sean Dague  writes:

> We're still working through kinks in the new system, which is why it's
> not fully documented yet.

We did not intend to change the general operation of 'recheck' and
'reverify', however, we did have some bugs in the early stages where we
missed a possible state-change.  I believe they have been worked out now
and at this point you should be able to leave 'reverify bug #' on a
change that has failed the gate and it will have its check jobs re-run
and then automatically re-enqueued in the gate pipeline if it gets a +1.

-Jim

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

Re: [openstack-dev] [Heat] lazy translation is breaking Heat

[Thomas Herve]

> This change was recently merged:
> 
> https://review.openstack.org/#/c/69133/
> 
> Unfortunately it didn't enable lazy translations for the unit tests, so it
> didn't catch the many places in Heat that won't work when lazy translations
> are enabled. Notably there are a lot of cases where the code adds the result
> of a call to _() with another string, and Message objects (which are
> returned from _ when lazy translations are enabled) can't be added,
> resulting in an exception being raised.
> 
> I think the best course of action would be to revert this change, and then
> reintroduce it along with patches to fix all the problems, while enabling it
> for the unit tests so bugs won't be reintroduced in the future.

+1 for me to revert it. It broke Heat before, and it did it again because we 
didn't have any tests. Let's have a proper test environment for not making that 
mistake again and again.

-- 
Thomas

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

Re: [openstack-dev] [Openstack-dev] [neutron] [ml2] Neutron and ML2 - adding new network type

[Kyle Mestery]

[Moving to -dev list]

On Feb 18, 2014, at 9:12 AM, Sławek Kapłoński  wrote:

> Hello,
> 
> I'm trying to make something with neutron and ML2 plugin. Now I need to add 
> my own external network type (as there are "Flat", "VLAN", "GRE" and so on). 
> I searched for manuals for that but I can't found anything. Can someone of 
> You explain me how I should do that? Is it enough to add own type_driver and 
> mechanism_driver to ML2? Or I should do something else also?
> 
Hi Sławek:

Can you explain more about what you’re looking to achieve here? I’m just
curious how the existing TypeDrivers won’t cover your use case. ML2 was
designed to remove segmentation management from the MechanismDrivers
so they could all share segment types. Perhaps understanding what you’re
trying to achieve would help better understand the approach to take here.

Thanks,
Kyle

> Thanks in advance
> --
> Sławek Kapłoński
> sla...@kaplonski.pl
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


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

Re: [openstack-dev] [Heat] lazy translation is breaking Heat

[Christopher Armstrong]

I've filed a bug about this, https://bugs.launchpad.net/heat/+bug/1281644


On Tue, Feb 18, 2014 at 9:15 AM, Christopher Armstrong <
chris.armstr...@rackspace.com> wrote:

> This change was recently merged:
>
> https://review.openstack.org/#/c/69133/
>
> Unfortunately it didn't enable lazy translations for the unit tests, so it
> didn't catch the many places in Heat that won't work when lazy translations
> are enabled. Notably there are a lot of cases where the code adds the
> result of a call to _() with another string, and Message objects (which are
> returned from _ when lazy translations are enabled) can't be added,
> resulting in an exception being raised.
>
> I think the best course of action would be to revert this change, and then
> reintroduce it along with patches to fix all the problems, while enabling
> it for the unit tests so bugs won't be reintroduced in the future.
>
> Interestingly it also didn't fail any of the tempest tests, I'm not sure
> why.
>
> --
> IRC: radix
> Christopher Armstrong
>



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

[openstack-dev] Hyper-V meeting minutes

[Peter Pouliot]

Hi everyone,

Here is the log from today's Hyper-v Meeting.

Meeting ended Tue Feb 18 16:17:57 2014 UTC.  Information about MeetBot at 
http://wiki.debian.org/MeetBot . (v 0.1.4)
Minutes:
http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-02-18-16.00.html
Minutes (text): 
http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-02-18-16.00.txt
Log:
http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-02-18-16.00.log.html


Peter J. Pouliot CISSP
Sr. SDET OpenStack
Microsoft
New England Research & Development Center
1 Memorial Drive
Cambridge, MA 02142
P: 1.(857).4536436
E: ppoul...@microsoft.com

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

Re: [openstack-dev] [keystone][all] Keystone V2 and V3 support in icehouse

[Frittoli, Andrea (HP Cloud)]

Hi, 

 

thanks for the update

 

Link to the tempest bp I’m working on: 
https://blueprints.launchpad.net/tempest/+spec/multi-keystone-api-version-tests 

 

The update of the python binding to use the keystone binding is targeted for 
icehouse or juno? 

 

andrea

 

 

From: Dolph Mathews [mailto:dolph.math...@gmail.com] 
Sent: 18 February 2014 13:54
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jamie Lennox
Subject: Re: [openstack-dev] [keystone][all] Keystone V2 and V3 support in 
icehouse

 

 

On Mon, Feb 10, 2014 at 5:23 PM, Frittoli, Andrea (Cloud Services) 
mailto:fritt...@hp.com> > wrote:

Hi,

 

I’m working on a tempest blueprint to make tempest able to run 100% on keystone 
v3 (or later versions) – the auth version to be used will be available via a 
configuration switch.

 

The rationale is that Keystone V2 is deprecated in icehouse, V3 being the 
primary version. Thus it would be good to have (at least) one of the  gate jobs 
running entirely with keystone v3.

 

Much appreciated! Have a link to that bp?

 

 

There are other components beyond tempest that would need some changes to make 
this happen.

 

Nova and cinder python bindings work only with keystone v2 [0], and as far as I 
know all core services work with keystone v2 (at least by default). 

Is there a plan to support identity v3 there until the end of icehouse?

 

Yes (but maybe not by the end of icehouse)- we'd like to make all other client 
libraries depend on keystoneclient's library for authentication in the long 
run. Jamie Lennox has done a ton of great work to prepare keystoneclient for 
that responsibility during Icehouse.

 

If not I think we may have to consider still supporting v2 in icehouse.

 

v2 should certainly be supported in icehouse; which version other projects 
default to is up to them, but I'd like to see *all* projects at least 
defaulting to v3 by the end of Juno.

 

 

Andrea

 

[0] https://bugs.launchpad.net/python-novaclient/+bug/1262843 

 

-- 

Andrea Frittoli

IaaS Systems Engineering Team 

HP Cloud ☁


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

 



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Tripleo] How much local storage device preparation should tripleo do?

[Charles Crouch]

This question is focused on Tripleo overcloud nodes meant to handle block 
storage or object storage rather than the regular control and compute nodes.

Basically I want to get peoples thoughts on how much manipulation of the 
underlying storage devices we should be expecting to do if we want standalone 
overcloud nodes to provide block and object storage via their local disks, i.e. 
not via NFS/gluster/ceph etc

Consider an overcloud node which will be used for providing object storage 
(swift) from its local disks:
IIUC swift really just cares that for each disk you want to use for storage:
a) it has a partition
b) that the partition has a filesystem on it
c) that the partition is mounted under /srv/node

Given tripleo is taking ownership of installing the operating system on these 
nodes, how much responsibility should tripleo take for getting the above steps 
done? In the case that this machine just came in off the truck, all of those 
steps would need to be done prior to the system being a usable part of the 
overcloud.
If we don't want tripleo dealing with this stuff right now, e.g. its eventually 
going to be done by ironic e.g. 
https://blueprints.launchpad.net/ironic/+spec/utility-ramdisk, then what is the 
best process today? Is it that someone does a bunch of work on these machines 
before we start the tripleo deployment process? Presumably we would at least 
need to be able to feed Heat a list of partitions which we then mount under 
/srv/node and update fstab accordingly so the changes stick?

[Right now we skip all of a)-c) above and just have swift using a folder, 
/srv/node/d1 (doesn't this want to be under /mnt/state?), to store all its 
content.]


Now consider an overcloud node which will be used for providing block storage 
(cinder) from its local disks:
IIUC the cinder LVM driver is the preferred option when accessing local 
storage. In this case cinder really just cares that for each disk you want to 
use for storage it is added to a specific volume group. [Assuming we're not 
going to allow people to create disk partitions and then select particular 
ones]. We would then presumably need to include the appropriate filter options 
in lvm.conf so the selected devices get correctly scanned by lvm at startup?

[Right now we do all this for a dummy loopback device which gets created under 
/mnt/state/var/lib/cinder/ and whose size you can set via the Heat template: 
https://github.com/openstack/tripleo-image-elements/blob/master/elements/cinder-volume/os-refresh-config/post-configure.d/72-cinder-resize-volume-groups
 ]

Thanks
Charles

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

Re: [openstack-dev] [Heat] lazy translation is breaking Heat

[Ben Nemec]

 

On 2014-02-18 09:15, Christopher Armstrong wrote: 

> This change was recently merged: 
> 
> https://review.openstack.org/#/c/69133/ [1] 
> 
> Unfortunately it didn't enable lazy translations for the unit tests, so it 
> didn't catch the many places in Heat that won't work when lazy translations 
> are enabled. Notably there are a lot of cases where the code adds the result 
> of a call to _() with another string, and Message objects (which are returned 
> from _ when lazy translations are enabled) can't be added, resulting in an 
> exception being raised. 
> 
> I think the best course of action would be to revert this change, and then 
> reintroduce it along with patches to fix all the problems, while enabling it 
> for the unit tests so bugs won't be reintroduced in the future.

Agreed. That behavior was intentional because we shouldn't be adding
translated strings that way, but obviously it needs to be fixed before
lazy translation is enabled. :-) 

> Interestingly it also didn't fail any of the tempest tests, I'm not sure why.

That is kind of concerning. I see that the error does show up in the
logs a couple of times though:
http://logs.openstack.org/33/69133/5/gate/gate-tempest-dsvm-full/d6aa1bd/logs/screen-h-api.txt.gz#_2014-02-17_17_38_25_521


Maybe this is something that would need the new error message test
enabled to be caught? 

> -- 
> 
> IRC: radix Christopher Armstrong 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  [2]

 

Links:
--
[1] https://review.openstack.org/#/c/69133/
[2] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Regarding language pack database schema

[Paul Czarkowski]

I'm also a +1 for #2.However as discussed on IRC,  we should clearly
spell out that the JSON blob should never be treated in a SQL-like manner.
  The moment somebody says 'I want to make that item in the json
searchable' is the time to discuss adding it as part of the SQL schema.

On 2/13/14 4:39 PM, "Clayton Coleman"  wrote:

>I like option #2, simply because we should force ourselves to justify
>every attribute that is extracted as a queryable parameter, rather than
>making them queryable at the start.
>
>- Original Message -
>> Hi Arati,
>> 
>> 
>> I would vote for Option #2 as a short term solution. Probably later we
>>can
>> consider using NoSQL DB or MariaDB which has Column_JSON type to store
>> complex types.
>> 
>> Thanks
>> Georgy
>> 
>> 
>> On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane <
>> arati.mahim...@rackspace.com > wrote:
>> 
>> 
>> 
>> Hi All,
>> 
>> I have been working on defining the Language pack database schema. Here
>>is a
>> link to my review which is still a WIP -
>> https://review.openstack.org/#/c/71132/3 .
>> There are a couple of different opinions on how we should be designing
>>the
>> schema.
>> 
>> Language pack has several complex attributes which are listed here -
>> https://etherpad.openstack.org/p/Solum-Language-pack-json-format
>> We need to support search queries on language packs based on various
>> criteria. One example could be 'find a language pack where type='java'
>>and
>> version>1.4'
>> 
>> Following are the two options that are currently being discussed for
>>the DB
>> schema:
>> 
>> Option 1: Having a separate table for each complex attribute, in order
>>to
>> achieve normalization. The current schema follows this approach.
>> However, this design has certain drawbacks. It will result in a lot of
>> complex DB queries and each new attribute will require a code change.
>> Option 2: We could have a predefined subset of attributes on which we
>>would
>> support search queries.
>> In this case, we would define columns (separate tables in case of
>>complex
>> attributes) only for this subset of attributes and all other attributes
>>will
>> be a part of a json blob.
>> With this option, we will have to go through a schema change in case we
>> decide to support search queries on other attributes at a later stage.
>> 
>> I would like to know everyone's thoughts on these two approaches so
>>that we
>> can take a final decision and go ahead with one approach.
>> Suggestions regarding any other approaches are welcome too!
>> 
>> Thanks,
>> Arati
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> 
>> --
>> Georgy Okrokvertskhov
>> Architect,
>> OpenStack Platform Products,
>> Mirantis
>> http://www.mirantis.com
>> Tel. +1 650 963 9828
>> Mob. +1 650 996 3284
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Heat] lazy translation is breaking Heat

[Jay S Bryant]

All,

Myself and Jim Carey have been working on getting the right solution for 
making lazy_translation work through Nova and Cinder. 

The patch should have also had changes to remove the use of str() in any 
LOG or exception messages as well as the removal of any places where 
strings were being '+' ed together.  In the case of Cinder we are doing it 
as two separate patches that are dependent.  I am surprised that this 
change got past Jenkins.  In the case of Cinder and Nova unit test caught 
a number of problems.

We will make sure to work with Liang Chen to avoid this happening again.

Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   Ben Nemec 
To: openstack-dev@lists.openstack.org, 
Date:   02/18/2014 10:37 AM
Subject:Re: [openstack-dev] [Heat] lazy translation is breaking 
Heat



On 2014-02-18 09:15, Christopher Armstrong wrote:
This change was recently merged: 
 
https://review.openstack.org/#/c/69133/
 
Unfortunately it didn't enable lazy translations for the unit tests, so it 
didn't catch the many places in Heat that won't work when lazy 
translations are enabled. Notably there are a lot of cases where the code 
adds the result of a call to _() with another string, and Message objects 
(which are returned from _ when lazy translations are enabled) can't be 
added, resulting in an exception being raised.
 
I think the best course of action would be to revert this change, and then 
reintroduce it along with patches to fix all the problems, while enabling 
it for the unit tests so bugs won't be reintroduced in the future.
 
Agreed.  That behavior was intentional because we shouldn't be adding 
translated strings that way, but obviously it needs to be fixed before 
lazy translation is enabled. :-)
 
Interestingly it also didn't fail any of the tempest tests, I'm not sure 
why.
 
That is kind of concerning.  I see that the error does show up in the logs 
a couple of times though: 
http://logs.openstack.org/33/69133/5/gate/gate-tempest-dsvm-full/d6aa1bd/logs/screen-h-api.txt.gz#_2014-02-17_17_38_25_521
 
Maybe this is something that would need the new error message test enabled 
to be caught?
 
-- 
IRC: radix
Christopher Armstrong

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

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

Re: [openstack-dev] [Network] Allocate MAC and IP address for a VM instance

[Dong Liu]

Hi Jay,

In neutron API, you could create port with specified mac_address and fix_ip, 
and then create vm with this port.
But the mapping of them need to manage by yourself.


在 2014年2月18日，22:41，Jay Lau  写道：

> Greetings,
> 
> Not sure if it is suitable to ask this question in openstack-dev list. Here 
> come a question related to network and want to get some input or comments 
> from you experts.
> 
> My case is as this: For some security issue, I want to put both MAC and 
> internal IP address to a pool and when create VM, I can get MAC and its 
> mapped IP address and assign the MAC and IP address to the VM.
> 
> For example, suppose I have following MAC and IP pool:
> 1) 78:2b:cb:af:78:b0, 192.168.0.10
> 2) 78:2b:cb:af:78:b1, 192.168.0.11
> 3) 78:2b:cb:af:78:b2, 192.168.0.12
> 4) 78:2b:cb:af:78:b3, 192.168.0.13
> 
> Then I can create four VMs using above MAC and IP address, each row in above 
> can be mapped to a VM.
> 
> Does any of you have any idea for the solution of this?
> 
> -- 
> Thanks,
> 
> Jay
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [QA] Service dependency decorators in tests

[Boris Pavlovic]

Hi,


I will be glad to help with this part! It shouldn't be too much work to
handle this.

Who will lead this thing?)


Best regards,
Boris Pavlovic



On Tue, Feb 18, 2014 at 7:51 PM, Matthew Treinish wrote:

> On Tue, Feb 18, 2014 at 09:42:43AM -0500, Sean Dague wrote:
> > I'm +1 on that. Mostly it's just a lot of time, so hasn't been dealt
> > with yet. Unless there is a completely pressing need, I'd rather see
> > that happen right after icehouse release, because I'm concerned it will
> > be a lot of changes coming in when people are trying to get other more
> > critical things landed.
>
> Yeah I agree with this too, however we said the same thing after havana
> regarding service tags.
>
> >
> >   -Sean
> >
> > On 02/18/2014 09:33 AM, Frittoli, Andrea (Cloud Services) wrote:
> > > Hi all,
> > >
> > >
> > >
> > > Scenario tests feature service dependency decorators in tests - so that
> > > a test will run only if all required components are available.
> > >
> > > I think we should extend them to all tests, including the API ones. For
> > > instance Nova image tests depend on Glance, cinder attach/detach tests
> > > depend on Nova.
>
> So originally the service tag decorator just added an attr and the intent
> was
> to just make it easy to filter by service. So, we only were adding the
> decorator
> to tests that touched the service that weren't in the namespace.
> For example:
>
> tests in: api.compute.image would not get an image tag
>
> but if a test in: api.compute.volume touched glance then it should have the
> decorator.
>
> But, it was only recently that I added the skip function to the decorator
> because it made sense to. I still think we should follow the same
> convention
> for using the services decorators, even with skips as part of the
> decorator.
> For the tests in directories that contain a service name we should raise
> skips
> for that service in the explicity. Since the directory calls out the
> service it
> should be implied that it's required so we don't need to bother tagging
> all the
> tests.
>
> > >
> > >
> > >
> > > If there is agreement on that I'd happy to start a bp to track the test
> > > tagging effort.
>
> There has been one open since havana :)
> https://blueprints.launchpad.net/tempest/+spec/add-service-tags
>
> -Matt Treinish
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Network] Allocate MAC and IP address for a VM instance

[Tim Bell]

Jay,

We've got a similar requirement at CERN where we would like to have pools of 
ip/mac combinations for each subnet and have it so that the user is just 
allocated one (and for the same subnet that the hypervisor is on).

We've not found a good solution so far.

Tim

> -Original Message-
> From: Dong Liu [mailto:willowd...@gmail.com]
> Sent: 18 February 2014 18:12
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Network] Allocate MAC and IP address for a VM 
> instance
> 
> Hi Jay,
> 
> In neutron API, you could create port with specified mac_address and fix_ip, 
> and then create vm with this port.
> But the mapping of them need to manage by yourself.
> 
> 
> 在 2014年2月18日，22:41，Jay Lau  写道：
> 
> > Greetings,
> >
> > Not sure if it is suitable to ask this question in openstack-dev list. Here 
> > come a question related to network and want to get some
> input or comments from you experts.
> >
> > My case is as this: For some security issue, I want to put both MAC and 
> > internal IP address to a pool and when create VM, I can get
> MAC and its mapped IP address and assign the MAC and IP address to the VM.
> >
> > For example, suppose I have following MAC and IP pool:
> > 1) 78:2b:cb:af:78:b0, 192.168.0.10
> > 2) 78:2b:cb:af:78:b1, 192.168.0.11
> > 3) 78:2b:cb:af:78:b2, 192.168.0.12
> > 4) 78:2b:cb:af:78:b3, 192.168.0.13
> >
> > Then I can create four VMs using above MAC and IP address, each row in 
> > above can be mapped to a VM.
> >
> > Does any of you have any idea for the solution of this?
> >
> > --
> > Thanks,
> >
> > Jay
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [keystone][all] Keystone V2 and V3 support in icehouse

[Dolph Mathews]

On Tue, Feb 18, 2014 at 10:21 AM, Frittoli, Andrea (HP Cloud) <
fritt...@hp.com> wrote:

> Hi,
>
>
>
> thanks for the update
>
>
>
> Link to the tempest bp I’m working on:
> https://blueprints.launchpad.net/tempest/+spec/multi-keystone-api-version-tests
>
>
>
> The update of the python binding to use the keystone binding is targeted
> for icehouse or juno?
>

Clients are tracked against the same release milestones of the services, so
the integration can happen whenever someone wants to tackle it and we can
release them when they're ready.


>
>
> andrea
>
>
>
>
>
> *From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
> *Sent:* 18 February 2014 13:54
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* Jamie Lennox
> *Subject:* Re: [openstack-dev] [keystone][all] Keystone V2 and V3 support
> in icehouse
>
>
>
>
>
> On Mon, Feb 10, 2014 at 5:23 PM, Frittoli, Andrea (Cloud Services) <
> fritt...@hp.com> wrote:
>
> Hi,
>
>
>
> I’m working on a tempest blueprint to make tempest able to run 100% on
> keystone v3 (or later versions) – the auth version to be used will be
> available via a configuration switch.
>
>
>
> The rationale is that Keystone V2 is deprecated in icehouse, V3 being the
> primary version. Thus it would be good to have (at least) one of the  gate
> jobs running entirely with keystone v3.
>
>
>
> Much appreciated! Have a link to that bp?
>
>
>
>
>
> There are other components beyond tempest that would need some changes to
> make this happen.
>
>
>
> Nova and cinder python bindings work only with keystone v2 [0], and as far
> as I know all core services work with keystone v2 (at least by default).
>
> Is there a plan to support identity v3 there until the end of icehouse?
>
>
>
> Yes (but maybe not by the end of icehouse)- we'd like to make all other
> client libraries depend on keystoneclient's library for authentication in
> the long run. Jamie Lennox has done a ton of great work to prepare
> keystoneclient for that responsibility during Icehouse.
>
>
>
> If not I think we may have to consider still supporting v2 in icehouse.
>
>
>
> v2 should certainly be supported in icehouse; which version other projects
> default to is up to them, but I'd like to see *all* projects at least
> defaulting to v3 by the end of Juno.
>
>
>
>
>
> Andrea
>
>
>
> [0] https://bugs.launchpad.net/python-novaclient/+bug/1262843
>
>
>
> --
>
> Andrea Frittoli
>
> IaaS Systems Engineering Team
>
> HP Cloud ☁
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Meetup Summary

[Matt Riedemann]

On 2/17/2014 4:41 PM, Russell Bryant wrote:

Greetings,

Last week we had an in-person Nova meetup.  Bluehost was a wonderful and
generous host.  Many thanks to them.  :-)

Here's some observations and a summary of some of the things that we
discussed:

1) Mark McClain (Neutron PTL) and and Mark Washenberger (Glance PTL)
both attended.  Having some cross-project discussion time was
*incredibly* useful, so I'm thankful they attended.  This makes me very
optimistic about our plans to have a cross-project day at the Atlanta
design summit.  We need to try to get as many opportunities as possible
for this sort of collaboration.

2) Gantt  - We discussed the progress of the Gantt effort.  After
discussing the problems encountered so far and the other scheduler work
going on, the consensus was that we really need to focus on decoupling
the scheduler from the rest of Nova while it's still in the Nova tree.

Don was still interested in working on the existing gantt tree to learn
what he can about the coupling of the scheduler to the rest of Nova.
Nobody had a problem with that, but it doesn't sound like we'll be ready
to regenerate the gantt tree to be the "real" gantt tree soon.  We
probably need another cycle of development before it will be ready.

As a follow-up to this, I wonder if we should rename the current gantt
repository from openstack/gantt to stackforge/gantt to avoid any
possible confusion.  We should make it clear that we don't expect the
current repo to be used yet.

3) v3 API - We discussed the current status of this effort, including
the tasks API, and all other v3 work.  There are some notes here:

https://etherpad.openstack.org/p/NovaV3APIDoneCriteria

I actually think we need to talk about this some more before we mark v3
as stable.  I'll get notes together and start another thread soon.

4) We talked about Nova's integration with Neutron and made some good
progress.  We came up with a blueprint (ideally for Icehouse) to improve
Nova-Neutron interaction.

There are two cases we need to improve that have been particularly
painful.  The first is the network info cache.  Neutron can issue an API
callback to Nova to let us know that we need to refresh the cache.  The
second is knowing that VIF setup is complete.  Right now we have cases
where we issue a request to Neutron and it is processed asynchronously.
  We have no way to know when it has finished.  For example, we really
need to know that VIF plumbing is set up before we boot an instance and
it tries its DHCP request.  We can do this with nova-network, but with
Neutron it's just a giant race.  I'm actually surprised we've made it
this long without fixing this.


One or both of these issues (thinking VIF readiness) is also causing a 
gate failure in master and stable/havana:


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

I'd like to propose skipping that test if Tempest is configured with 
Neutron until we get the bug fixed/blueprint resolved.


By the way, can I get a link to the blueprint to reference in the bug 
(or vice-versa)?




5) Driver CI - We talked about the ongoing effort to set up CI for all
of the compute drivers.  The discussion was mostly a status review.  At
this point, the Xenserver and Docker drivers are both at risk of being
removed from Nova for the Icehouse release if CI is not up and running
in time.

6) Upgrades - we discussed the state of upgrading Nova.  It was mostly a
review of the excellent progress being made this cycle.  Dan Smith has
been doing a lot of work to get us closer to where we can upgrade the
control services at once with downtime, but roll through upgrading the
computes later after service is back up.  Joe Gordon has been working on
automating the testing of this to make sure we don't break it, so that
should be running soon.


Lastly, everyone in attendance seemed to really enjoy it, and the
overwhelming vote in the room was for doing the same thing again during
the Juno cycle.  Dates and location TBD.


+1



Thanks,



--

Thanks,

Matt Riedemann


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

[openstack-dev] Unit Testing Nova

[Mike Spreitzer]

I am trying to figure out how I should be doing unit testing, and 
documenting it in https://wiki.openstack.org/wiki/Gerrit_Workflow

Oddly, the situation for Nova seems reversed: run_tests.sh works and tox 
does not.  See http://paste.openstack.org/show/66969/ for my experiences 
with each.  Am I doing something wrong, or is tox really not working for 
Nova?  In the latter case, is this a bug or just to be expected?

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

Re: [openstack-dev] Unit Testing Nova

[Boris Pavlovic]

Mike,

What version of tox do you use?

Best regards,
Boris Pavlovic


On Tue, Feb 18, 2014 at 9:46 PM, Mike Spreitzer  wrote:

> I am trying to figure out how I should be doing unit testing, and
> documenting it in https://wiki.openstack.org/wiki/Gerrit_Workflow
>
> Oddly, the situation for Nova seems reversed: run_tests.sh works and tox
> does not.  See http://paste.openstack.org/show/66969/ for my experiences
> with each.  Am I doing something wrong, or is tox really not working for
> Nova?  In the latter case, is this a bug or just to be expected?
>
> Thanks,
> Mike
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][IPv6] Testing functionality of IPv6 modes using Horizon

[Abishek Subramanian (absubram)]

Hi shshang, all,

I have some preliminary Horizon diffs available and if anyone
would be kind enough to patch them and try to test the
functionality, I'd really appreciate it.
I know I'm able to create subnets successfully with
the two modes but if there's anything else you'd like
to test or have any other user experience comments,
please feel free to let me know.

The diffs are at -  https://review.openstack.org/74453

Thanks!!


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

Re: [openstack-dev] VPC Proposal

[Martin, JC]

There was a lot of emails on that thread, but I am not seeing the discussion 
converging. I would like to reiterate my concerns:

   - We are trying to implement an API on a feature that is not supported by 
openstack 
   - As a result, the implementation is overloading existing construct without 
implementing full AWS capabilities and semantic (e.g. Shared network isolation 
from VPC, or Floating IP scoping to VPC).
   - Dependent blueprints are not implemented and have been deferred, resulting 
in the broken implementation (e.g. 
https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron)
   - this "feature" is only available through EC2 API, which is likely going to 
result in another implementation for general use.
   - users adopting the VPC model proposed through EC2 API will be stuck in an 
upgrade mess when the proper implementation comes along.
   - There are new constructs in work that are better suited for implementing 
this concept properly (Multi tenant hierarchy and domains).

As you can guess, I'm not really a fan, but it seems that only few individuals 
are concerned. I would think that this topic would create more interest, 
specially on the network side. Maybe because of the subject tags. I will 
therefore copy this email with the Neutron tag.

JC

On Feb 17, 2014, at 10:10 PM, Rudra Rugge  wrote:

> I am not sure on how to dig out the archives. There were a couple of
> emails exchanged with Salvatore on the thread pertaining to the extensions
> we were referring to as part of this blueprint.
> 
> There are a few notes on the whiteboard of the blueprint as well.
> 
> Regards,
> Rudra
> 
> 
> On 2/17/14, 1:28 PM, "jc Martin"  wrote:
> 
>> Thanks,
>> 
>> Do you have the links for the discussions ?
>> 
>> Thanks,
>> 
>> JC
>> 
>> Sent from my iPhone
>> 
>>> On Feb 17, 2014, at 11:29 AM, Rudra Rugge  wrote:
>>> 
>>> JC,
>>> 
>>> BP has been updated with the correct links. I have removed the abandoned
>>> review #3.
>>> Please review #1 and #2.
>>> 
>>> 1. https://review.openstack.org/#/c/40071/
>>> 
>>>  This is the active review.
>>>  There is one comment by Sean regarding
>>>  adding a knob when Neutron is not used.
>>>  That will be addressed with the next path.
>>> 2. https://review.openstack.org/#/c/53171
>>>  This is the active review for tempest
>>>  test cases as requested by Joe Gordon.
>>>  Currently abandoned until #1 goes through.
>>> 3. https://review.openstack.org/#/c/53171
>>>  This review is not active. It was accidentally submitted with a new
>>> change-id. 
>>> 
>>> Regards,
>>> Rudra
>>> 
 On 2/16/14, 9:25 AM, "Martin, JC"  wrote:
 
 Harshad,
 
 I tried to find some discussion around this blueprint.
 Could you provide us with some notes or threads  ?
 
 Also, about the code review you mention. which one are you talking
 about :
 https://review.openstack.org/#/c/40071/
 https://review.openstack.org/#/c/49470/
 https://review.openstack.org/#/c/53171
 
 because they are all abandoned.
 
 Could you point me to the code, and update the BP because it seems that
 the links are not correct.
 
 Thanks,
 
 JC
> On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu" 
> wrote:
> 
> Harshad,
> 
> Thanks for clarifying.
> 
>> We started looking at this as some our customers/partners were
>> interested in get AWS API compatibility. We have this blueprint and
>> code review pending for long time now. We will know based on this
>> thread wether the community is interested. But I assumed that
>> community
>> was interested as the blueprint was approved and code review has no
>> -1(s) for long time now.
> 
> Makes sense. I would leave it to others on this list to chime in if
> there is sufficient interest or not.
> 
>> To clarify, a clear incremental path from an AWS compatible API to an
>> OpenStack model is not clear.
>> 
>> In my mind AWS compatible API does not need new openstack model. As
>> more discussion happen on JC's proposal and implementation becomes
>> clear we will know how incremental is the path. But at high level
>> there
>> two major differences
>> 1. New first class object will be introduced which effect all
>> components
>> 2. more than one project can be supported within VPC.
>> But it does not change AWS API(s). So even in JC(s) model if you want
>> AWS API then we will have to keep VPC to project mapping 1:1, since
>> the
>> API will not take both VPC ID and project ID.
>> 
>> As more users want to migrate from AWS or IaaS providers who want
>> compete with AWS should be interested in this compatibility.
> 
> IMHO that's a tough sell. Though an AWS compatible API does not need
> an
> OpenStack abstraction, we would end up with two independent ways of
> doing similar things. That would OpenStack repeating itself!
>>

Re: [openstack-dev] [Solum] Regarding language pack database schema

[Adrian Otto]

I agree. Let's proceed with option #2, and submit a wishlist bug to track this 
as tech debt. We would like to come back to this later and add an option to use 
a blob store for the JSON blob content, as Georgy mentioned. These could be 
stored in swift, or a K/V store. It might be nice to have a thin get/set 
abstraction there to allow alternates to be implemented as needed.

I'm not sure exactly where we can track Paul Czarkowski's suggested 
restriction. We may need to just rely on reviewers to prevent this, because if 
we ever start introspecting the JSON blob, we will be using an SQL 
anti-pattern. I'm generally opposed to putting arbitrary sized text and blob 
entries into a SQL database, because eventually you may run into the maximum 
allowable size (ie: max-allowed-packet) and cause unexpected error conditions.

Thanks,

Adrian

On Feb 18, 2014, at 8:48 AM, Paul Czarkowski 
 wrote:

> I'm also a +1 for #2.However as discussed on IRC,  we should clearly
> spell out that the JSON blob should never be treated in a SQL-like manner.
>  The moment somebody says 'I want to make that item in the json
> searchable' is the time to discuss adding it as part of the SQL schema.
> 
> On 2/13/14 4:39 PM, "Clayton Coleman"  wrote:
> 
>> I like option #2, simply because we should force ourselves to justify
>> every attribute that is extracted as a queryable parameter, rather than
>> making them queryable at the start.
>> 
>> - Original Message -
>>> Hi Arati,
>>> 
>>> 
>>> I would vote for Option #2 as a short term solution. Probably later we
>>> can
>>> consider using NoSQL DB or MariaDB which has Column_JSON type to store
>>> complex types.
>>> 
>>> Thanks
>>> Georgy
>>> 
>>> 
>>> On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane <
>>> arati.mahim...@rackspace.com > wrote:
>>> 
>>> 
>>> 
>>> Hi All,
>>> 
>>> I have been working on defining the Language pack database schema. Here
>>> is a
>>> link to my review which is still a WIP -
>>> https://review.openstack.org/#/c/71132/3 .
>>> There are a couple of different opinions on how we should be designing
>>> the
>>> schema.
>>> 
>>> Language pack has several complex attributes which are listed here -
>>> https://etherpad.openstack.org/p/Solum-Language-pack-json-format
>>> We need to support search queries on language packs based on various
>>> criteria. One example could be 'find a language pack where type='java'
>>> and
>>> version>1.4'
>>> 
>>> Following are the two options that are currently being discussed for
>>> the DB
>>> schema:
>>> 
>>> Option 1: Having a separate table for each complex attribute, in order
>>> to
>>> achieve normalization. The current schema follows this approach.
>>> However, this design has certain drawbacks. It will result in a lot of
>>> complex DB queries and each new attribute will require a code change.
>>> Option 2: We could have a predefined subset of attributes on which we
>>> would
>>> support search queries.
>>> In this case, we would define columns (separate tables in case of
>>> complex
>>> attributes) only for this subset of attributes and all other attributes
>>> will
>>> be a part of a json blob.
>>> With this option, we will have to go through a schema change in case we
>>> decide to support search queries on other attributes at a later stage.
>>> 
>>> I would like to know everyone's thoughts on these two approaches so
>>> that we
>>> can take a final decision and go ahead with one approach.
>>> Suggestions regarding any other approaches are welcome too!
>>> 
>>> Thanks,
>>> Arati
>>> 
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Georgy Okrokvertskhov
>>> Architect,
>>> OpenStack Platform Products,
>>> Mirantis
>>> http://www.mirantis.com
>>> Tel. +1 650 963 9828
>>> Mob. +1 650 996 3284
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Murano] Repositoris re-organization

[Sergey Lukjanov]

Ruslan,

I'm absolutely agree with you, only one correction, I think
murano-guestagent will better fit the repo content.

Thanks.


On Tue, Feb 18, 2014 at 7:23 PM, Alexander Tivelkov
wrote:

> Hi Ruslan,
>
> Thanks for your feedback. I completely agree with these arguments:
> actually, these were the reasons why I've initiated this discussion.
>
> Team, let's discuss this on the IRC meeting today.
>
> --
> Regards,
> Alexander Tivelkov
>
>
> On Tue, Feb 18, 2014 at 5:55 PM, Ruslan Kamaldinov <
> rkamaldi...@mirantis.com> wrote:
>
>> I'd suggest to reduce number of Murano repositories for several reasons:
>>
>> * All other OpenStack projects have a single repo per project. While this
>> point might look like something not worth mentioning, it's really
>> important:
>> - unified project structure simplifies life for new developers. once they
>> get familiar with one project, they can expect something similar from
>> another project
>> - unified project structure simplifies life for deployers. similar project
>> structure simplifies packaging and deployment automation
>>
>> * Another important reason is to simplify gated testing. Just take a look
>> at
>> Solum layout [1], they have everything needed (contrib, functionaltests)
>> to
>> run dvsm job in a single repo. One simple job definition [2] allows to
>> install Solum in DevStack and run Tempest tests for Solum.
>>
>> * As a side-effect, this approach will improve integrity of project
>> components. Having murano-common in the same repo with other components
>> will
>> help to catch integration issues earlier.
>>
>>
>> In an ideal world there will be only the following repos:
>> - murano (api, common, conductor, docs, repository, tests)
>> - python-muranoclient
>> - murano-dashboard
>> - murano-agent
>> - puppet-murano (optional, but nice to have)
>>
>>
>> [1] https://github.com/stackforge/solum
>> [2]
>> https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/solum.yaml
>>
>>
>> Thanks,
>> Ruslan
>>
>>
>> On Thu, Feb 6, 2014 at 3:14 PM, Serg Melikyan wrote:
>>
>>> Hi, Alexander,
>>>
>>> In general I am completely agree with Clint and Robert, and as one of
>>> contributors of Murano I don't see any practical reasons for repositories
>>> reorganization. And regarding of your proposal I have a few thoughts that I
>>> would like to share below:
>>>
>>> >This enourmous amount of repositories adds too much infrustructural
>>> complexity
>>> Creating a new repository is a quick, easy and completely automated
>>> procedure that requires only simple commit to Zuul configuration. All
>>> infrastructure related to repositories is handled by Openstack CI and
>>> supported by Openstack Infra Team, and actually don't require anything from
>>> project development team. About what infrastructure complexity you are
>>> talking about?
>>>
>>> >I actually think keeping them separate is a great way to make sure you
>>> have ongoing API stability. (c) Clint
>>> I would like to share a little statistic gathered by Stan Lagun
>>> a little time ago regarding repositories count in different PaaS solution.
>>> If you are concerned about large number of repositories used by Murano, you
>>> will be quite amused:
>>>
>>>- https://github.com/heroku - 275
>>>- https://github.com/cloudfoundry - 132
>>> - https://github.com/openshift - 49
>>>- https://github.com/CloudifySource - 46
>>>
>>> >First of all, I would suggest to have a single reposository for all
>>> the three main components of Murano: main murano API (the contents of the
>>> present), workflow execution engine (currently murano-conductor; also it
>>> was suggested to rename the component itself to murano-engine for more
>>> consistent naming) and metadata repository (currently murano-repository).
>>>
>>> *murano-api* and *murano-repository* have many things in common, they
>>> are both present HTTP API to the user, and I hope would be rewritten to
>>> common framework (Pecan?). But *murano-conductor* have only one thing
>>> in common with other two components: code shared under *murano-common*.
>>> That repository may be eventually eliminated by moving to Oslo (as it
>>> should be done).
>>>
>>> >Also, it has been suggested to move our agents (both windows and
>>> unified python) into the main repository as well - just to put them into a
>>> separate subfolder. I don't see any reasons why they should be separated
>>> from core Murano: I don't believe we are going to have any third-party
>>> implementations of our "Unified agent" proposals, while this possibility
>>> was the main reason for separatinng them.
>>>
>>> Main reason for murano-agent to have separate repository was not a
>>> possibility to have another implementation, but that all sources that
>>> should be able to be built as package, have tests and can be uploaded to
>>> PyPI (or any other gate job) should be placed in different repository.
>>> OpenStack CI have several rules regarding how

Re: [openstack-dev] DVR blueprint document locked / private

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Assaf,
Thanks for letting me know.
This document was completely open and accessible by everyone till last week.
Someone might have changed the settings on this document.

I don't remember that I changed any settings on this document.
The Powerpoint slides link that I forwarded yesterday also captures the same 
details and still that is accessible.

I have opened it again for the public.

If it would have caused any trouble for you to participate in the upstream 
discussions for the last two days, I feel sorry for it.

Feel free to send an email to me, if you have any other issues or concerns.

Thanks
Swami

-Original Message-
From: Assaf Muller [mailto:amul...@redhat.com] 
Sent: Tuesday, February 18, 2014 2:33 AM
To: openstack-dev@lists.openstack.org
Cc: Vasudevan, Swaminathan (PNB Roseville); Baldwin, Carl (HPCS Neutron); 
mmccl...@yahoo-inc.com; Livnat Peer; Sylvain Afchain
Subject: [Neutron] DVR blueprint document locked / private

Regarding the DVR blueprint [1], I noticed that its corresponding Google Doc 
[2] has been private / blocked for nearly a week now. It's very difficult to 
participate in upstream design discussions when the document is literally 
locked.

I would appreciate the re-opening of the document, especially considering the 
recent face to face meeting and the contested discussion points that were 
raised.

[1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
[2] 
https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit


Thank you,
Assaf Muller, Cloud Networking Engineer Red Hat 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] VPC Proposal

[Martin, JC]

We have started a discussion on the proper model to implement a Virtual Private 
Cloud (VPC) feature in openstack.

I feel that there was not a lot of discussion on this topic in the past, and 
this may be because of the ML tags used.
I am pointing out this discussion to this group with the Neutron tag as I think 
that networking is a big aspect of VPC.

Please, jump in the discussion and share your comments.

See http://lists.openstack.org/pipermail/openstack-dev/2014-February/026892.html

and 

http://lists.openstack.org/pipermail/openstack-dev/2014-February/027171.html

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

Re: [openstack-dev] Unit Testing Nova

[Mike Spreitzer]

Boris Pavlovic  wrote on 02/18/2014 12:55:26 PM:
> What version of tox do you use? 

That was using version 1.6.1 (as a workaround to 
https://bugs.launchpad.net/openstack-ci/+bug/1274135).

Also, this was a fresh DevStack install (done about an hour or two before 
I posted to the list), with a pretty plain local.conf; it added only Heat 
to the default stuff.

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

[openstack-dev] Db interaction: conductor vs objects vs apis

[Pitucha, Stanislaw Izaak]

Hi all,
I'm writing some new code which uses objects sent around by rpc. I got to
implementing some new conductor methods and started wondering... what's the
current recommended way of interacting with the database? Many seem to be
around:
- "fat model" approach - put the db interaction in objects
- put the db interactions in the conductor itself
- completely separate it (quotas style)

Since the new code isn't that big or generalized in any way, I'm dropping
the third option completely. But conductor -vs- object stays.
What should do the db calls? If it's objects, should I also do that even for
things that would take only one line in conductor/manager?

Regards,
Stanisław Pitucha
Cloud Services 
Hewlett Packard



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][policy] Using network services with network policies

[Mohammad Banikazemi]

Thanks Sumit and Stephen for information provided.

It appears to me that we can (and should) use the notion of
services/service chains within the group policy extension (and that has
been always one of our options). If this is a reasonable approach, then we
need to see how we can bring in these services to our group policy and if
there are changes we may require.

The first thing that comes to mind is to have a new service insertion
context, namely policy (or should it be policy_rule?). If that is in place,
then a service chain (we can start with a chain of one single service) gets
created with it's context set to a particular policy. While the service
plugin is responsible for standing up the service, the connectivity is
established through the implementation of the group policy extension, in
particular the "redirect" action. Is this a reasonable approach? This
approach requires some kind of coordination wrt how these operations are
done by the service plugin and the group policy extension. May be a policy
simply provides the insertion context for creation of the service chain (in
isolation and by the appropriate service plugin) and policy rules are then
used to make the service operational. This is different from how services
are expected to be instantiated right now. Right? Thinking aloud here.
Please comment.

A lot of interesting things to work on. May be Juno is where all these
efforts come to fruition together :)

Mohammad



From:   Sumit Naiksatam 
To: Mohammad Banikazemi/Watson/IBM@IBMUS,
Cc: "OpenStack Development Mailing List (not for usage questions)"

Date:   02/17/2014 02:12 AM
Subject:Re: [openstack-dev] [neutron][policy] Using network services
with network policies



Thanks Mohammad for bringing this up. I responded in another thread:
http://lists.openstack.org/pipermail/openstack-dev/2014-February/027306.html


~Sumit.

On Sun, Feb 16, 2014 at 7:27 AM, Mohammad Banikazemi  wrote:
> During the last IRC call we started talking about network services and
how
> they can be integrated into the group Policy framework.
>
> In particular, with the "redirect" action we need to think how we can
> specify the network services we want to redirect the traffic to/from.
There
> has been a substantial work in the area of service chaining and service
> insertion and in the last summit "advanced service" in VMs were
discussed.
> I think the first step for us is to find out the status of those efforts
and
> then see how we can use them. Here are a few questions that come to mind.
> 1- What is the status of service chaining, service insertion and advanced
> services work?
> 2- How could we use a service chain? Would simply referring to it in the
> action be enough? Are there considerations wrt creating a service chain
> and/or a service VM for use with the Group Policy framework that need to
be
> taken into account?
>
> Let's start the discussion on the ML before taking it to the next call.
>
> Thanks,
>
> Mohammad

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

Re: [openstack-dev] [Heat] lazy translation is breaking Heat

[Christopher Armstrong]

On Tue, Feb 18, 2014 at 11:14 AM, Jay S Bryant  wrote:

> All,
>
> Myself and Jim Carey have been working on getting the right solution for
> making lazy_translation work through Nova and Cinder.
>
> The patch should have also had changes to remove the use of str() in any
> LOG or exception messages as well as the removal of any places where
> strings were being '+' ed together.  In the case of Cinder we are doing it
> as two separate patches that are dependent.  I am surprised that this
> change got past Jenkins.  In the case of Cinder and Nova unit test caught a
> number of problems.
>
> We will make sure to work with Liang Chen to avoid this happening 
> again.
>


fwiw Thomas Hervé has posted a patch to revert the introduction of lazy
translation:

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


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

Re: [openstack-dev] [Openstack-stable-maint] Stable gate status?

[Alan Pevec]

2014-02-11 16:14 GMT+01:00 Anita Kuno:
> On 02/11/2014 04:57 AM, Alan Pevec wrote:
>> Hi Mark and Anita,
>>
>> could we declare stable/havana neutron gate jobs good enough at this point?
>> There are still random failures as this no-op change shows
>> https://review.openstack.org/72576
>> but I don't think they're stable/havana specific.
...

> I will reaffirm here what I had stated in IRC.
>
> If Mark McClain gives his assent for stable/havana patches to be
> approved, I will not remove Neutron stable/havana patches from the gate
> queue before they start running tests. If after they start running
> tests, they demonstrate that they are failing, I will remove them from
> the gate as a means to keep the gate flowing. If the stable/havana gate
> jobs are indeed stable, I will not be removing any patches that should
> be merged.

As discussed on #openstack-infra last week, stable-maint team should
start looking more closely at Tempest stable/havana branch and Matthew
Treinish from Tempest core joined the stable-maint team to help us
there.

In the meantime, we need to do something more urgently, there are
remaining failures showing up frequently in stable/havana jobs which
seem to have been fixed or at least improved on master:

* bug 1254890 - "Timed out waiting for thing ... to become ACTIVE"
causes tempest-dsvm-* failures
  resolution unclear?

* bug 1253896 - "Attempts to verify guests are running via SSH fails.
SSH connection to guest does not work."
  based on Salvatore's comment 56, I've marked it as Won't Fix in
neutron/havana and opened tempest/havana to propose what Tempest test
or jobs should skip for Havana. Please chime-in in the bug if you have
suggestions.


Cheers,
Alan

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

Re: [openstack-dev] [Neutron] VPC Proposal

[Ravi Chunduru]

Hi JC,
  I suggest we have a VPC meetup to get those who are interested on the
same page and present the resulted draft proposal in the summit design
discussions.

Thanks,
-Ravi.


On Tue, Feb 18, 2014 at 10:12 AM, Martin, JC  wrote:

> We have started a discussion on the proper model to implement a Virtual
> Private Cloud (VPC) feature in openstack.
>
> I feel that there was not a lot of discussion on this topic in the past,
> and this may be because of the ML tags used.
> I am pointing out this discussion to this group with the Neutron tag as I
> think that networking is a big aspect of VPC.
>
> Please, jump in the discussion and share your comments.
>
> See
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/026892.html
>
> and
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/027171.html
>
> JC
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [nova][neutron] SRIOV Meeting on Wednesday Feb.19th

[Robert Li (baoli)]

Hi Folks,

Irena suggested to have another sync-up meeting on Wednesday. So let's meet at 
8:00am at #openstack-meeting-alt.

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

Re: [openstack-dev] [Neutron] Urgent questions on Service Type Framework for VPNaaS

[Nachi Ueno]

Hi Paul

Sorry, I have missed this mail.
The reason for putting -1 was the gating issue, so it is OK now.

PS
Thank you for your rebasing this one

2014-02-16 16:43 GMT-08:00 Sumit Naiksatam :
> Hi Paul,
>
> Our plan with FWaaS was to get it to parity with LBaaS as far as STF
> is concerned. That way any changes to STF can be explored in the
> context of all services, and the migration can also be performed for
> all services. Accordingly, Gary Duan has been actively working on the
> patch:
> https://review.openstack.org/#/c/60699/
>
> and we hope to get it approved and merged soon.
>
> Thanks,
> ~Sumit.
>
> On Sat, Feb 15, 2014 at 5:09 PM, Paul Michali  wrote:
>> Hi Nachi and other cores!
>>
>> I'm very close to publishing my vendor based VPNaaS driver (service driver
>> is ready, device driver is a day or two out), but have a bit of an issue.
>> This code uses the Service Type Framework, which, as you know, is still out
>> for review (and has been idle for a long time).  I updated the STF client
>> code and it is updated in Gerrit.
>>
>> I saw you put a -1 on your STF server code. Is the feature being abandoned
>> or was that for some other reason?
>>
>> If going forward with it, can you update the server STF code, or should I do
>> it (I have a branch with the STF based on master of about 2 weeks ago, so it
>> should update OK)?
>>
>> Also, I'm wondering (worried) about the logistics of my reviews. I wanted to
>> do my service driver and device driver separately (I guess making the latter
>> dependent on the former in Gerrit). However, because of the STF, I'd need to
>> make my service driver dependent on the STF server code too (my current
>> branch has both code pieces). Really worried about the complexity there and
>> about it getting hung up, if there is more delay on the STF review.
>>
>> I've been working on another branch without the STF dependency, however that
>> has to hack in part of the STF to be able to select the service driver based
>> on config vs hardwired to the reference driver.
>>
>> Should I proceed with the STF review chaining or push out my code w/o the
>> STF?
>>
>> Thanks!
>>
>> PCM (Paul Michali)
>>
>> MAIL  p...@cisco.com
>> IRCpcm_  (irc.freenode.net)
>> TW@pmichali
>> GPG key4525ECC253E31A83
>> Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>

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

Re: [openstack-dev] Unit Testing Nova

[Mike Spreitzer]

Mike Spreitzer/Watson/IBM@IBMUS wrote on 02/18/2014 01:22:33 PM:
> That was using version 1.6.1 (as a workaround to https://
> bugs.launchpad.net/openstack-ci/+bug/1274135). 
> 
> Also, this was a fresh DevStack install (done about an hour or two 
> before I posted to the list), with a pretty plain local.conf; it 
> added only Heat to the default stuff. 

As long as I am providing missing details, following are two more.  This 
DevStack install was done with https://review.openstack.org/#/c/74430/ 
applied to fix https://bugs.launchpad.net/devstack/+bug/1281415 .  And I 
manually did `sudo apt-get install libmysqlclient-dev` to work around 
https://bugs.launchpad.net/devstack/+bug/1203723 .

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

Re: [openstack-dev] [Nova] Meetup Summary

[Russell Bryant]

On 02/18/2014 12:36 PM, Matt Riedemann wrote:
>> 4) We talked about Nova's integration with Neutron and made some good
>> progress.  We came up with a blueprint (ideally for Icehouse) to improve
>> Nova-Neutron interaction.
>>
>> There are two cases we need to improve that have been particularly
>> painful.  The first is the network info cache.  Neutron can issue an API
>> callback to Nova to let us know that we need to refresh the cache.  The
>> second is knowing that VIF setup is complete.  Right now we have cases
>> where we issue a request to Neutron and it is processed asynchronously.
>>   We have no way to know when it has finished.  For example, we really
>> need to know that VIF plumbing is set up before we boot an instance and
>> it tries its DHCP request.  We can do this with nova-network, but with
>> Neutron it's just a giant race.  I'm actually surprised we've made it
>> this long without fixing this.
> 
> One or both of these issues (thinking VIF readiness) is also causing a
> gate failure in master and stable/havana:
> 
> https://bugs.launchpad.net/nova/+bug/1210483
> 
> I'd like to propose skipping that test if Tempest is configured with
> Neutron until we get the bug fixed/blueprint resolved.
> 
> By the way, can I get a link to the blueprint to reference in the bug
> (or vice-versa)?

I haven't seen a blueprint for this yet.

Mark, is that something you were planning on driving?

-- 
Russell Bryant

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

[openstack-dev] [Keystone] IRC Channel Venue Change for Keystone Development topics

[Morgan Fainberg]

So that the rest of the community is aware, the majority of keystone specific 
topics are moving from the #openstack-dev channel to the #openstack-keystone 
channel on Freenode. This is has been done to help free up #openstack-dev for 
more cross-project discussion.  Expect that the Keystone Core team will still 
be in #openstack-dev so that we can catch Keystone and Identity related 
questions (just as before).

Cheers,
Morgan Fainberg

—
Morgan Fainberg
Principal Software Engineer
Core Developer, Keystone
m...@metacloud.com___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Fixed recent gate issues

[Alan Pevec]

Hi John,

thanks for the summary.
I've noticed one more fall out from swiftclient update in Grenade jobs
running on stable/havana changes e.g.
http://logs.openstack.org/02/73402/1/check/check-grenade-dsvm/a5650ac/console.html
...
2014-02-18 13:00:02.103 | Test Swift
2014-02-18 13:00:02.103 | + swift --os-tenant-name=demo
--os-username=demo --os-password=secret
--os-auth-url=http://127.0.0.1:5000/v2.0 stat
2014-02-18 13:00:02.284 | Traceback (most recent call last):
2014-02-18 13:00:02.284 |   File "/usr/local/bin/swift", line 35, in 
2014-02-18 13:00:02.284 | from swiftclient import Connection, HTTPException
2014-02-18 13:00:02.285 | ImportError: cannot import name HTTPException
2014-02-18 13:00:02.295 | + STATUS_SWIFT=Failed
...

Grenade job installs swiftclient from git master but then later due to
python-swiftclient>=1.2,<2 requirement in Grizzly, older version 1.9.0
is pulled from pypi and then half-installed or something, producing
above conflict between swift CLI binary and libs.
Solution could be to remove swiftclient cap in Grizzly, any other suggestions?

Cheers,
Alan

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

[openstack-dev] [keystone][nova]Hierarchical Multitenancy Meeting

[Vishvananda Ishaya]

Hi Everyone,

I will be on a plane during the Multitenancy Meeting on Friday. You are welcome 
to have the meeting without me. Otherwise, we can just continue the excellent 
discussion we have been having on the Mailing list.

Thanks,
Vish


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] Object Model discussion

[Eugene Nikanorov]

Hi folks,

Recently we were discussing LBaaS object model with Mark McClain in order
to address several problems that we faced while approaching L7 rules and
multiple vips per pool.

To cut long story short: with existing workflow and model it's impossible
to use L7 rules, because
each pool being created is 'instance' object in itself, it defines another
logical configuration and can't be attached to other existing configuration.
To address this problem, plus create a base for multiple vips per pool, the
'loadbalancer' object was introduced (see
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance ).
However this approach raised a concern of whether we want to let user to
care about 'instance' object.

My personal opinion is that letting user to work with 'loadbalancer' entity
is no big deal (and might be even useful for terminological clarity; Libra
and AWS APIs have that) especially if existing simple workflow is
preserved, so the 'loadbalancer' entity is only required when working with
L7 or multiple vips per pool.

The alternative solution proposed by Mark is described here under #3:
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion
In (3) the root object of the configuration is VIP, where all kinds of
bindings are made (such as provider, agent, device, router). To address
'multiple vips' case another entity 'Listener' is introduced, which
receives most attributes of former 'VIP' (attribute sets are not finalized
on those pictures, so don't pay much attention)
If you take closer look at #2 and #3 proposals, you'll see that they are
essentially similar, where in #3 the VIP object takes instance/loadbalancer
role from #2.
Both #2 and #3 proposals make sense to me because they address both
problems with L7 and multiple vips (or listeners)
My concern about #3 is that it redefines lots of workflow and API aspects
and even if we manage to make transition to #3 in backward-compatible way,
it will be more complex in terms of code/testing, then #2 (which is on
review already and works).

The whole thing is important design decision, so please share your thoughts
everyone.

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

[openstack-dev] Hierarchical Multitenancy and resource ownership

[Martin, JC]

I see a lot of good things happening on the hierarchical multi tenancy proposal 
that Vish made a while back.

However, the focus so far is on roles and quota but could not find any 
discussion related to resource ownership.

Is the plan to allow the creation of resources within any level of the 
hierarchy or is the plan to allow the visibility of the resources up to a level 
in the hierarchy ? or both ?

For example, if I have :
  - orga.vpca.projecta
  - orga.vpca.projectb

and I want to share a resource like a network between projecta and projectb, 
should the network be owned by vpca or should it be owned by projecta or 
projectb, or a vpca.admin project and then shared to all children of vpca ?

I think either would work, and both maybe required.

Opinions ?

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

Re: [openstack-dev] call for help with nova bug management

[Tracy Jones]

So i have been rather underwhelmed in the enthusiastic response to help out :-)



So far only wendar and johnthetubaguy have signed up.   I was hoping for at 
least 3-5 people to help with the initial triage.  Please sign up this week if 
you can help and i’ll schedule the meetings starting next week




On Feb 14, 2014, at 2:16 PM, Tracy Jones  wrote:

> Hi Folks - I’ve offered to help Russell out with managing nova’s bug queue.  
> The charter of this is as follows
> 
> Triage the 125 new bugs
> Ensure that the critical bugs are assigned properly and are making progress
> 
> Once this part is done we will shift our focus to things like
> Bugs in incomplete state with no update by the reporter - they should be set 
> to invalid if they requester does not update them in a timely manner.
> Bugs which say they are in progress but no progress is being made.   If a bug 
> is assigned and simply being ignored we should remove the assignment so 
> others can grab it and work on it
> 
> The bug triage policy is defined here 
> https://wiki.openstack.org/wiki/BugTriage
> 
> 
> What can you do???  First I need a group of folks to volunteer to help with 1 
> and 2.  I will start a weekly IRC meeting where we work on the triage and 
> check progress on critical (or even high) prio bugs.  If you can help out, 
> please sign up at the end of this etherpad and include your timezone.  Once I 
> have a few people to help i will schedule the meeting at a time that I hope 
> is convenient for all.
> 
> https://etherpad.openstack.org/p/nova-bug-management
> 
> Thanks in advance for your help.
> 
> Tracy

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

Re: [openstack-dev] [All] Fixed recent gate issues

[Matthew Treinish]

On Tue, Feb 18, 2014 at 08:27:16PM +0100, Alan Pevec wrote:
> Hi John,
> 
> thanks for the summary.
> I've noticed one more fall out from swiftclient update in Grenade jobs
> running on stable/havana changes e.g.
> http://logs.openstack.org/02/73402/1/check/check-grenade-dsvm/a5650ac/console.html
> ...
> 2014-02-18 13:00:02.103 | Test Swift
> 2014-02-18 13:00:02.103 | + swift --os-tenant-name=demo
> --os-username=demo --os-password=secret
> --os-auth-url=http://127.0.0.1:5000/v2.0 stat
> 2014-02-18 13:00:02.284 | Traceback (most recent call last):
> 2014-02-18 13:00:02.284 |   File "/usr/local/bin/swift", line 35, in 
> 2014-02-18 13:00:02.284 | from swiftclient import Connection, 
> HTTPException
> 2014-02-18 13:00:02.285 | ImportError: cannot import name HTTPException
> 2014-02-18 13:00:02.295 | + STATUS_SWIFT=Failed
> ...
> 
> Grenade job installs swiftclient from git master but then later due to
> python-swiftclient>=1.2,<2 requirement in Grizzly, older version 1.9.0
> is pulled from pypi and then half-installed or something, producing
> above conflict between swift CLI binary and libs.
> Solution could be to remove swiftclient cap in Grizzly, any other suggestions?

Yeah it's pip weirdness where things falls apart because of version cap. It's
basically installing bin/swift from 1.9 when it sees the version requirement
but it leaves everything in python-swiftclient namespace from master.

So I've actually been looking at this since late yesterday the conclusion we've
reached is to just skip the exercises on grizzly. Removing the version cap isn't
going to be simple on grizzly because there global requirements wasn't enforced
back in grizzly. We'd have to change the requirement for both glance, horizon,
and swift and being ~3 weeks away from eol for grizzly I don't think we should
mess with that. This failure is only an issue with cli swiftclient on grizzly
(and one swift functional test) which as it sits now is just the devstack
exercises on grenade. So if we just don't run those exercises on the grizzly
side of a grenade run there shouldn't be an issue. I've got 2 patches to do
this here:

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

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


-Matt Treinish

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

Re: [openstack-dev] [infra] Meeting Tuesday February 18th at 19:00 UTC

[Elizabeth Krumbach Joseph]

On Mon, Feb 17, 2014 at 2:39 PM, Elizabeth Krumbach Joseph
 wrote:
> The OpenStack Infrastructure (Infra) team is hosting our weekly
> meeting tomorrow, Tuesday February 18th, at 19:00 UTC in
> #openstack-meeting

Thanks to everyone who joined us, minutes and log available here:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-02-18-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-02-18-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-02-18-19.01.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

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

Re: [openstack-dev] Db interaction: conductor vs objects vs apis

[Russell Bryant]

On 02/18/2014 01:22 PM, Pitucha, Stanislaw Izaak wrote:
> Hi all,
> I'm writing some new code which uses objects sent around by rpc. I got to
> implementing some new conductor methods and started wondering... what's the
> current recommended way of interacting with the database? Many seem to be
> around:
> - "fat model" approach - put the db interaction in objects
> - put the db interactions in the conductor itself
> - completely separate it (quotas style)
> 
> Since the new code isn't that big or generalized in any way, I'm dropping
> the third option completely. But conductor -vs- object stays.
> What should do the db calls? If it's objects, should I also do that even for
> things that would take only one line in conductor/manager?

It may be easier to provide a better answer with more details on what
you're doing, but the general answer is use objects always.

-- 
Russell Bryant

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

Re: [openstack-dev] Db interaction: conductor vs objects vs apis

[Dan Smith]

> - "fat model" approach - put the db interaction in objects

If it's just DB interaction, then yes, in the object for sure.

> - put the db interactions in the conductor itself

There is a reasonable separation between using conductor for mechanics
(i.e. API deferring a long-running activity to conductor) and using it
for (new) DB proxying. At this point. the former is okay and the latter
is not, IMHO.

That said, any complex data structure going over RPC should be an object
as well, so that we have version tracking on the structure itself. We
recently had a case where we broke upgrades because the *format* of an
RPC method argument was changed, that argument was not an object, and we
ended up with some very ugly failures as a result :)

--Dan

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

Re: [openstack-dev] Hierarchical Multitenancy and resource ownership

[Vishvananda Ishaya]

On Feb 18, 2014, at 11:31 AM, Martin, JC  wrote:

> 
> I see a lot of good things happening on the hierarchical multi tenancy 
> proposal that Vish made a while back.
> 
> However, the focus so far is on roles and quota but could not find any 
> discussion related to resource ownership.
> 
> Is the plan to allow the creation of resources within any level of the 
> hierarchy or is the plan to allow the visibility of the resources up to a 
> level in the hierarchy ? or both ?
> 
> For example, if I have :
>  - orga.vpca.projecta
>  - orga.vpca.projectb
> 
> and I want to share a resource like a network between projecta and projectb, 
> should the network be owned by vpca or should it be owned by projecta or 
> projectb, or a vpca.admin project and then shared to all children of vpca ?
> 
> I think either would work, and both maybe required.
> 
> Opinions ?

We haven’t discussed inheriting ownership of objects but at first glance it 
seems confusing: how would one determine if an object in vcpa is “shared” and 
visible to projects below, and if it is how far down the hierarchy would it be 
visible? It is probably best to keep this explicit for the moment.

I’ve been thinking of sharing as objects that appear at multiple places in the 
hierarchy. This could be a list of “owners” or “shares”, but I think it would 
support either of your options. My initial thoughts would be to just put the 
network resource in orga.vcpa and then share it to the projects. This of course 
gets a little tedious when other projects are added later, but it avoids the 
complications i mentioned above.

Vish

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy

[Stephen Balukoff]

Hi!


On Tue, Feb 18, 2014 at 12:18 AM, Samuel Bercovici wrote:

>  Hi,
>
>
>
> It matters, as someone might need to “debug” the backend setup and the
> name, if exists, can add details.
>
> This obviously a vendor’s choice if they wish to push this back to backend
> but the API should not remove this as a choice.
>
+1


>
>
> -Sam.
>
>
>
-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] Unit test cases failing with error 'cannot import rpcapi'

[iKhan]

Hi All,

All cinder test cases are failing with error 'cannot import rpcapi', though
same files work fine in live cinder setup. I wonder what's going wrong when
unit testing is triggered. Can any one help me out here?

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

Re: [openstack-dev] [Murano] Need a new DSL for Murano

[Georgy Okrokvertskhov]

>My observation has been that Murano has changed from a Windows focused
Deployment Service >to a Metadata Application Catalog Workflow thing (I
fully admit this may be an invalid >observation).  It's unclear to me what
OpenStack pain/use-cases is to be solved by "complex >object composition,
description of data types, contracts..."

Murano is intended to provide high level definition of Applications which
will include description of specific application requirements (like input
parameters, external dependencies) as well as low level scripts, heat
snippets and workflows which will be required to manage application.

Object composition is required to address application diversity. We expect
to be an integration layer for numerous different application from
different OS and areas like WebServices, BigData, SAP, Enterprise specific
apps. In order to decrease amount of work for Application author we will
provide a way to reuse existing applications by extending them via object
composition. Inside Murano we provide a library of workflows and
requirements for general application classes. This library has workflows
for instance creation, networking and app deployments. This will help
application author to write only application specific stuff. For example if
I need to publish my web service based on Tomcat I will create a new
application class which has tomcat as a parent and then I will add my
application specific parameters like App URL and will add deployment script
which will download App war file and put it to Tomcat app directory. All
other stuff will be done automatically by existing workflows for tomcat
application.

You can imagine this as a nested Heat template inclusion but with ability
to override and\or extend it. The ability to add a workflow actually looks
like a dynamic Heat resource type generation as you can specify actions and
associated workflows. These actions can be triggered by external events to
provide an ability of application life cycle management.

Thanks
Georgy


On Mon, Feb 17, 2014 at 4:41 PM, Keith Bray wrote:

>
>  Can someone elaborate further on the things that Murano is intended to
> solve within the OpenStack ecosystem?   My observation has been that Murano
> has changed from a Windows focused Deployment Service to a Metadata
> Application Catalog Workflow thing (I fully admit this may be an invalid
> observation).  It's unclear to me what OpenStack pain/use-cases is to be
> solved by "complex object composition, description of data types,
> contracts..."
>
>  Your thoughts would be much appreciated.
>
>  Thanks,
> -Keith
>
>   From: Renat Akhmerov 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Monday, February 17, 2014 1:33 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Murano] Need a new DSL for Murano
>
>   Clint,
>
>  We're collaborating with Murano. We may need to do it in a way that
> others could see it though. There are several things here:
>
>- Murano doesn't really have a "workflow engine" similar to Mistral's.
>People get confused with that but it's just a legacy terminology, I think
>Murano folks were going to rename this component to be more precise about
>it.
>- Mistral DSL doesn't seem to be a good option for solving tasks that
>Murano is intended to solve. Specifically I mean things like complex object
>composition, description of data types, contracts and so on. Like Alex and
>Stan mentioned Murano DSL tends to grow into a full programming language
>.
>- Most likely Mistral will be used in Murano for implementation, at
>least we see where it would be valuable. But Mistral is not so matured yet,
>we need to keep working hard and be patient :)
>
>
>  Anyway, we keep thinking on how to make both languages look similar or
> at least the possibility to use them seamlessly, if needed (call Mistral
> workflows from Murano DSL or vice versa).
>
>   Renat Akhmerov
> @ Mirantis Inc.
>
>  On 16 Feb 2014, at 05:48, Clint Byrum  wrote:
>
> Excerpts from Alexander Tivelkov's message of 2014-02-14 18:17:10 -0800:
>
> Hi folks,
>
> Murano matures, and we are getting more and more feedback from our early
> adopters. The overall reception is very positive, but at the same time
> there are some complaints as well. By now the most significant complaint is
> is hard to write workflows for application deployment and maintenance.
>
> Current version of workflow definition markup really have some design
> drawbacks which limit its potential adoption. They are caused by the fact
> that it was never intended for use for Application Catalog use-cases.
>
>
> Just curious, is there any reason you're not collaborating on Mistral
> for this rather than both having a workflow engine?
>
> ___
> OpenStack-dev mailing list
> OpenStack-d

Re: [openstack-dev] VPC Proposal

[Joe Gordon]

On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC  wrote:
> There was a lot of emails on that thread, but I am not seeing the discussion 
> converging. I would like to reiterate my concerns:
>
>- We are trying to implement an API on a feature that is not supported by 
> openstack

I don't see it that way. I see this BP as converting neutron calls
into AWS VPC calls with a little glue (which can be seen here
https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support). But I am
no networking expert, so take that with a large grain of salt.

>- As a result, the implementation is overloading existing construct 
> without implementing full AWS capabilities and semantic (e.g. Shared network 
> isolation from VPC, or Floating IP scoping to VPC).

A partial implementation is better then no implementation, that being
said if we want to overhaul OpenStack's VPC capabilities I think the
partial implementation would have to be thrown out.

>- Dependent blueprints are not implemented and have been deferred, 
> resulting in the broken implementation (e.g. 
> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron)

That is a requirement for phase 3, and shouldn't matter for phase 1
and 2. And only phase 1 is up for review.

>- this "feature" is only available through EC2 API, which is likely going 
> to result in another implementation for general use.
>- users adopting the VPC model proposed through EC2 API will be stuck in 
> an upgrade mess when the proper implementation comes along.

This point concerns me the most, can you elaborate.

>- There are new constructs in work that are better suited for implementing 
> this concept properly (Multi tenant hierarchy and domains).


All that being said, it sounds like there are two separate efforts to
get VPC into OpenStack, one by supporting AWS specs, and a second
native OpenStack version.  It sounds like further discussion is needed
between these two efforts, so I am unapproving
https://blueprints.launchpad.net/nova/+spec/aws-vpc-support as it
needs further discussion.  The last thing we want is to merge a
controversial blueprint before all the questions can be resolved.

>
> As you can guess, I'm not really a fan, but it seems that only few 
> individuals are concerned. I would think that this topic would create more 
> interest, specially on the network side. Maybe because of the subject tags. I 
> will therefore copy this email with the Neutron tag.
>
> JC
>
> On Feb 17, 2014, at 10:10 PM, Rudra Rugge  wrote:
>
>> I am not sure on how to dig out the archives. There were a couple of
>> emails exchanged with Salvatore on the thread pertaining to the extensions
>> we were referring to as part of this blueprint.
>>
>> There are a few notes on the whiteboard of the blueprint as well.
>>
>> Regards,
>> Rudra
>>
>>
>> On 2/17/14, 1:28 PM, "jc Martin"  wrote:
>>
>>> Thanks,
>>>
>>> Do you have the links for the discussions ?
>>>
>>> Thanks,
>>>
>>> JC
>>>
>>> Sent from my iPhone
>>>
 On Feb 17, 2014, at 11:29 AM, Rudra Rugge  wrote:

 JC,

 BP has been updated with the correct links. I have removed the abandoned
 review #3.
 Please review #1 and #2.

 1. https://review.openstack.org/#/c/40071/

  This is the active review.
  There is one comment by Sean regarding
  adding a knob when Neutron is not used.
  That will be addressed with the next path.
 2. https://review.openstack.org/#/c/53171
  This is the active review for tempest
  test cases as requested by Joe Gordon.
  Currently abandoned until #1 goes through.
 3. https://review.openstack.org/#/c/53171
  This review is not active. It was accidentally submitted with a new
 change-id.

 Regards,
 Rudra

> On 2/16/14, 9:25 AM, "Martin, JC"  wrote:
>
> Harshad,
>
> I tried to find some discussion around this blueprint.
> Could you provide us with some notes or threads  ?
>
> Also, about the code review you mention. which one are you talking
> about :
> https://review.openstack.org/#/c/40071/
> https://review.openstack.org/#/c/49470/
> https://review.openstack.org/#/c/53171
>
> because they are all abandoned.
>
> Could you point me to the code, and update the BP because it seems that
> the links are not correct.
>
> Thanks,
>
> JC
>> On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu" 
>> wrote:
>>
>> Harshad,
>>
>> Thanks for clarifying.
>>
>>> We started looking at this as some our customers/partners were
>>> interested in get AWS API compatibility. We have this blueprint and
>>> code review pending for long time now. We will know based on this
>>> thread wether the community is interested. But I assumed that
>>> community
>>> was interested as the blueprint was approved and code review has no
>>> -1(s) for long time now.
>>
>> Makes sense. I woul

Re: [openstack-dev] [savanna] renaming: initial voting

[Sergey Lukjanov]

The voting is ended, you can ding results here -
http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=10&id=E_5dd4f18fde38ce8e&algorithm=beatpath

So, the new name options for more detailed discussion are:

1. Gravity  (Condorcet winner: wins contests with all other choices)
2. Sahara  loses to Gravity by 10-8
3. Quazar  loses to Gravity by 13-3, loses to Sahara by 12-6
4. Stellar  loses to Gravity by 13-4, loses to Quazar by 9-7
5. Caravan  loses to Gravity by 12-5, loses to Stellar by 9-7
6. Tied:
Fusor  loses to Gravity by 13-2, loses to Caravan by 9-4
Maestro  loses to Gravity by 15-3, loses to Quazar by 9-5
Magellanic  loses to Gravity by 15-0, loses to Caravan by 9-5
9. Magellan  loses to Gravity by 16-1, loses to Maestro by 7-4
10. Stackadoop  loses to Gravity by 14-6, loses to Magellan by 8-6

Thanks for voting.


On Tue, Feb 18, 2014 at 10:52 AM, Sergey Lukjanov wrote:

> Currently, we have only 19/47 votes, so, I'm adding one more day.
>
>
> On Fri, Feb 14, 2014 at 3:04 PM, Sergey Lukjanov 
> wrote:
>
>> Hi folks,
>>
>> I've created a poll to select 10 candidates for new Savanna name. It's a
>> first round of selecting new name for our lovely project. This poll will be
>> ended in Monday, Feb 17.
>>
>> You should receive an email from "Sergey Lukjanov (CIVS poll supervisor)
>> slukja...@mirantis.com"  via cs.cornell.edu with topic "Poll: Savanna
>> new name candidates".
>>
>> Thank you!
>>
>> P.S. I've bcced all ATCs, don't panic.
>>
>> --
>> Sincerely yours,
>> Sergey Lukjanov
>> Savanna Technical Lead
>> Mirantis Inc.
>>
>
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
>



-- 
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Meetup Summary

[Dugger, Donald D]

Sylvain-

As you can tell from the meeting today the scheduler sub-group is really not 
the gantt group meeting, I try to make sure that messages for things like the 
agenda and what not include both `gantt' and `scheduler' in the subject so it's 
clear we're talking about the same thing.

Note that our ultimate goal is to create a scheduler that is usable by other 
projects, not just nova, but that is a second task.  The first task is to 
create a separate scheduler that will be usable by nova at a minimum.  (World 
domination will follow later :)

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

From: Sylvain Bauza [mailto:sylvain.ba...@gmail.com]
Sent: Monday, February 17, 2014 4:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Meetup Summary

Hi Russell and Don,

2014-02-17 23:41 GMT+01:00 Russell Bryant 
mailto:rbry...@redhat.com>>:
Greetings,


2) Gantt  - We discussed the progress of the Gantt effort.  After
discussing the problems encountered so far and the other scheduler work
going on, the consensus was that we really need to focus on decoupling
the scheduler from the rest of Nova while it's still in the Nova tree.

Don was still interested in working on the existing gantt tree to learn
what he can about the coupling of the scheduler to the rest of Nova.
Nobody had a problem with that, but it doesn't sound like we'll be ready
to regenerate the gantt tree to be the "real" gantt tree soon.  We
probably need another cycle of development before it will be ready.

As a follow-up to this, I wonder if we should rename the current gantt
repository from openstack/gantt to stackforge/gantt to avoid any
possible confusion.  We should make it clear that we don't expect the
current repo to be used yet.

There is currently no precise meeting timeslot for Gantt but the one with Nova 
scheduler subteam. Would it be possible to have a status on the current path 
for Gantt so that people interested in joining the effort would be able to get 
in ?

There is currently a discussion on how Gantt and Nova should interact, in 
particular regarding HostState and how Nova Computes could update their status 
so as Gantt would be able to filter on them. There are also other discussions 
about testing, API, etc. so I'm just wondering how to help and where.

On a side note, if Gantt is becoming a Stackforge project planning to have Nova 
scheduling first, could we also assume that we could also implement this 
service for being used by other projects (such as Climate) in parallel with 
Nova ?
The current utilization-aware-scheduling blueprint is nearly done so that it 
can be used for other queries than just Nova scheduling, but unfortunately as 
the scheduler is still part of Nova and without a REST API, it can't be 
leveraged on third-party projects.


Thanks,
-Sylvain

[1] : https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling

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

Re: [openstack-dev] [Solum] Regarding language pack database schema

[Paul Montgomery]

Maybe a crazy idea butŠ

What if we simply don't store the JSON blob data for M1 instead of putting
storing it in a way we don't like long term?  This way, there is no need
to remember to change something later even though a bug could be created
anyways.  I believe the fields that would be missing/not stored in the
blob are:

* Compiler version
* Language platform
* OS platform

Can we live with that for M1?


On 2/18/14 12:07 PM, "Adrian Otto"  wrote:

>I agree. Let's proceed with option #2, and submit a wishlist bug to track
>this as tech debt. We would like to come back to this later and add an
>option to use a blob store for the JSON blob content, as Georgy
>mentioned. These could be stored in swift, or a K/V store. It might be
>nice to have a thin get/set abstraction there to allow alternates to be
>implemented as needed.
>
>I'm not sure exactly where we can track Paul Czarkowski's suggested
>restriction. We may need to just rely on reviewers to prevent this,
>because if we ever start introspecting the JSON blob, we will be using an
>SQL anti-pattern. I'm generally opposed to putting arbitrary sized text
>and blob entries into a SQL database, because eventually you may run into
>the maximum allowable size (ie: max-allowed-packet) and cause unexpected
>error conditions.
>
>Thanks,
>
>Adrian
>
>On Feb 18, 2014, at 8:48 AM, Paul Czarkowski
>
> wrote:
>
>> I'm also a +1 for #2.However as discussed on IRC,  we should clearly
>> spell out that the JSON blob should never be treated in a SQL-like
>>manner.
>>  The moment somebody says 'I want to make that item in the json
>> searchable' is the time to discuss adding it as part of the SQL schema.
>> 
>> On 2/13/14 4:39 PM, "Clayton Coleman"  wrote:
>> 
>>> I like option #2, simply because we should force ourselves to justify
>>> every attribute that is extracted as a queryable parameter, rather than
>>> making them queryable at the start.
>>> 
>>> - Original Message -
 Hi Arati,
 
 
 I would vote for Option #2 as a short term solution. Probably later we
 can
 consider using NoSQL DB or MariaDB which has Column_JSON type to store
 complex types.
 
 Thanks
 Georgy
 
 
 On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane <
 arati.mahim...@rackspace.com > wrote:
 
 
 
 Hi All,
 
 I have been working on defining the Language pack database schema.
Here
 is a
 link to my review which is still a WIP -
 https://review.openstack.org/#/c/71132/3 .
 There are a couple of different opinions on how we should be designing
 the
 schema.
 
 Language pack has several complex attributes which are listed here -
 https://etherpad.openstack.org/p/Solum-Language-pack-json-format
 We need to support search queries on language packs based on various
 criteria. One example could be 'find a language pack where type='java'
 and
 version>1.4'
 
 Following are the two options that are currently being discussed for
 the DB
 schema:
 
 Option 1: Having a separate table for each complex attribute, in order
 to
 achieve normalization. The current schema follows this approach.
 However, this design has certain drawbacks. It will result in a lot of
 complex DB queries and each new attribute will require a code change.
 Option 2: We could have a predefined subset of attributes on which we
 would
 support search queries.
 In this case, we would define columns (separate tables in case of
 complex
 attributes) only for this subset of attributes and all other
attributes
 will
 be a part of a json blob.
 With this option, we will have to go through a schema change in case
we
 decide to support search queries on other attributes at a later stage.
 
 I would like to know everyone's thoughts on these two approaches so
 that we
 can take a final decision and go ahead with one approach.
 Suggestions regarding any other approaches are welcome too!
 
 Thanks,
 Arati
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 --
 Georgy Okrokvertskhov
 Architect,
 OpenStack Platform Products,
 Mirantis
 http://www.mirantis.com
 Tel. +1 650 963 9828
 Mob. +1 650 996 3284
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> ___
>> OpenStack-dev mailing li

Re: [openstack-dev] [cinder] Unit test cases failing with error 'cannot import rpcapi'

[John Griffith]

On Tue, Feb 18, 2014 at 1:21 PM, iKhan  wrote:
> Hi All,
>
> All cinder test cases are failing with error 'cannot import rpcapi', though
> same files work fine in live cinder setup. I wonder what's going wrong when
> unit testing is triggered. Can any one help me out here?
>
> --
> Thanks,
> IK
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
I just pulled a fresh clone and am not seeing any issues on my side.
Could it be a problem with your env?  Are you running venv?

John

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

Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy

[Eugene Nikanorov]

Hi folks,

I see little value in being able to debug such things because it is for
developers only. However given that such choice doesn't affect workflow and
public API, we can add corresponding calls to the driver API.

Thanks,
Eugene.



On Wed, Feb 19, 2014 at 12:20 AM, Stephen Balukoff wrote:

> Hi!
>
>
> On Tue, Feb 18, 2014 at 12:18 AM, Samuel Bercovici wrote:
>
>>  Hi,
>>
>>
>>
>> It matters, as someone might need to "debug" the backend setup and the
>> name, if exists, can add details.
>>
>> This obviously a vendor's choice if they wish to push this back to
>> backend but the API should not remove this as a choice.
>>
> +1
>
>
>>
>>
>> -Sam.
>>
>>
>>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Meetup Summary

[Matt Riedemann]

On 2/18/2014 1:12 PM, Russell Bryant wrote:

On 02/18/2014 12:36 PM, Matt Riedemann wrote:

4) We talked about Nova's integration with Neutron and made some good
progress.  We came up with a blueprint (ideally for Icehouse) to improve
Nova-Neutron interaction.

There are two cases we need to improve that have been particularly
painful.  The first is the network info cache.  Neutron can issue an API
callback to Nova to let us know that we need to refresh the cache.  The
second is knowing that VIF setup is complete.  Right now we have cases
where we issue a request to Neutron and it is processed asynchronously.
   We have no way to know when it has finished.  For example, we really
need to know that VIF plumbing is set up before we boot an instance and
it tries its DHCP request.  We can do this with nova-network, but with
Neutron it's just a giant race.  I'm actually surprised we've made it
this long without fixing this.


One or both of these issues (thinking VIF readiness) is also causing a
gate failure in master and stable/havana:

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

I'd like to propose skipping that test if Tempest is configured with
Neutron until we get the bug fixed/blueprint resolved.

By the way, can I get a link to the blueprint to reference in the bug
(or vice-versa)?


I haven't seen a blueprint for this yet.

Mark, is that something you were planning on driving?



Here we go:

https://blueprints.launchpad.net/nova/+spec/check-neutron-port-status

There are two patches up for it now from Aaron, still needs (exception) 
approval for Icehouse.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [cinder] Unit test cases failing with error 'cannot import rpcapi'

[iKhan]

Yes I do run in venv, I'm checking for missing libraries.


On Wed, Feb 19, 2014 at 2:03 AM, John Griffith
wrote:

> On Tue, Feb 18, 2014 at 1:21 PM, iKhan  wrote:
> > Hi All,
> >
> > All cinder test cases are failing with error 'cannot import rpcapi',
> though
> > same files work fine in live cinder setup. I wonder what's going wrong
> when
> > unit testing is triggered. Can any one help me out here?
> >
> > --
> > Thanks,
> > IK
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> I just pulled a fresh clone and am not seeing any issues on my side.
> Could it be a problem with your env?  Are you running venv?
>
> John
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [Neutron][LBaaS] L7 data types

[Stephen Balukoff]

A couple quick suggestions (additions):

 Entity: L7Rule

o   Attribute: type

§  Possible values:


   - HTTP_METHOD

o   Attribute: compare_type

§  Possible values:


   - GT (greater than)
   - LT (less than)
   - GE (greater than or equal to)
   - LE (less than or equal to)

Will we be doing syntax checking based on the L7Rule type being presented?
 (eg. if w'ere going to check that HEADER X has a value that is greater
than Y, are we going to make sure that "Y" is an integer? Or if we're going
to check that the PATH STARTS_WITH Z, are we going to make sure that Z is a
non-zero-length string? )

Thanks,
Stephen

On Tue, Feb 18, 2014 at 3:58 AM, Avishay Balderman wrote:

>  Here are the suggested values for the attributes below:
>
> · Entity: L7Rule
>
> o   Attribute: type
>
> §  Possible values:
>
> · HOST_NAME
>
> · PATH
>
> · FILE_NAME
>
> · FILE_TYPE
>
> · HEADER
>
> · COOKIE
>
> o   Attribute: compare_type
>
> §  Possible values:
>
> · EQUAL
>
> · CONTAINS
>
> · REGEX
>
> · STARTS_WITH
>
> · ENDS_WITH
>
> · Entity:L7VipPolicyAssociation
>
> o   Attribute:action
>
> §  Possible values:
>
> · POOL (must have pool id)
>
> · REDIRECT(must have a url to be used as redirect destination)
>
> · REJECT
>
>
>
>
>
> *From:* Oleg Bondarev [mailto:obonda...@mirantis.com]
> *Sent:* Monday, February 17, 2014 9:17 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] L7 data types
>
>
>
> Hi,
>
>
>
> I would add another candidate for being a closed set:
> L7VipPolicyAssociation.action (use_backend, block, etc.)
>
>
>
> Thanks,
>
> Oleg
>
>
>
> On Sun, Feb 16, 2014 at 3:53 PM, Avishay Balderman 
> wrote:
>
> (removing extra space from the subject – let email clients apply their
> filters)
>
>
>
> *From:* Avishay Balderman
> *Sent:* Sunday, February 16, 2014 9:56 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [Neutron][LBaaS] L7 data types
>
>
>
> Hi
>
> There are 2 fields in the L7 model that are candidates for being a closed
> set (Enum).
>
> I would like to hear your opinion.
>
>
>
> Entity:  L7Rule
>
> Field : type
>
> Description:  this field holds the part of the request where we should
> look for a value
>
> Possible values: URL,HEADER,BODY,(?)
>
>
>
> Entity:  L7Rule
>
> Field : compare_type
>
> Description: The way we compare the value against a given value
>
> Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?)
>
> *Note*: With REG_EXP we can cover the rest of the values.
>
>
>
> In general In the L7rule one can express the following (Example):
>
> “check if in the value of header named ‘Jack’  starts with X” – if this is
> true – this rule “returns” true
>
>
>
>
>
> Thanks
>
>
>
> Avishay
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Regarding language pack database schema

[Georgy Okrokvertskhov]

That is exactly option #2 which propose to store attributes in columns. So
there will be a limited set of attributes and each of them will have its
own column in a table.

Thanks
Georgy


On Tue, Feb 18, 2014 at 10:55 AM, Paul Montgomery <
paul.montgom...@rackspace.com> wrote:

> Maybe a crazy idea butŠ
>
> What if we simply don't store the JSON blob data for M1 instead of putting
> storing it in a way we don't like long term?  This way, there is no need
> to remember to change something later even though a bug could be created
> anyways.  I believe the fields that would be missing/not stored in the
> blob are:
>
> * Compiler version
> * Language platform
> * OS platform
>
> Can we live with that for M1?
>
>
> On 2/18/14 12:07 PM, "Adrian Otto"  wrote:
>
> >I agree. Let's proceed with option #2, and submit a wishlist bug to track
> >this as tech debt. We would like to come back to this later and add an
> >option to use a blob store for the JSON blob content, as Georgy
> >mentioned. These could be stored in swift, or a K/V store. It might be
> >nice to have a thin get/set abstraction there to allow alternates to be
> >implemented as needed.
> >
> >I'm not sure exactly where we can track Paul Czarkowski's suggested
> >restriction. We may need to just rely on reviewers to prevent this,
> >because if we ever start introspecting the JSON blob, we will be using an
> >SQL anti-pattern. I'm generally opposed to putting arbitrary sized text
> >and blob entries into a SQL database, because eventually you may run into
> >the maximum allowable size (ie: max-allowed-packet) and cause unexpected
> >error conditions.
> >
> >Thanks,
> >
> >Adrian
> >
> >On Feb 18, 2014, at 8:48 AM, Paul Czarkowski
> >
> > wrote:
> >
> >> I'm also a +1 for #2.However as discussed on IRC,  we should clearly
> >> spell out that the JSON blob should never be treated in a SQL-like
> >>manner.
> >>  The moment somebody says 'I want to make that item in the json
> >> searchable' is the time to discuss adding it as part of the SQL schema.
> >>
> >> On 2/13/14 4:39 PM, "Clayton Coleman"  wrote:
> >>
> >>> I like option #2, simply because we should force ourselves to justify
> >>> every attribute that is extracted as a queryable parameter, rather than
> >>> making them queryable at the start.
> >>>
> >>> - Original Message -
>  Hi Arati,
> 
> 
>  I would vote for Option #2 as a short term solution. Probably later we
>  can
>  consider using NoSQL DB or MariaDB which has Column_JSON type to store
>  complex types.
> 
>  Thanks
>  Georgy
> 
> 
>  On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane <
>  arati.mahim...@rackspace.com > wrote:
> 
> 
> 
>  Hi All,
> 
>  I have been working on defining the Language pack database schema.
> Here
>  is a
>  link to my review which is still a WIP -
>  https://review.openstack.org/#/c/71132/3 .
>  There are a couple of different opinions on how we should be designing
>  the
>  schema.
> 
>  Language pack has several complex attributes which are listed here -
>  https://etherpad.openstack.org/p/Solum-Language-pack-json-format
>  We need to support search queries on language packs based on various
>  criteria. One example could be 'find a language pack where type='java'
>  and
>  version>1.4'
> 
>  Following are the two options that are currently being discussed for
>  the DB
>  schema:
> 
>  Option 1: Having a separate table for each complex attribute, in order
>  to
>  achieve normalization. The current schema follows this approach.
>  However, this design has certain drawbacks. It will result in a lot of
>  complex DB queries and each new attribute will require a code change.
>  Option 2: We could have a predefined subset of attributes on which we
>  would
>  support search queries.
>  In this case, we would define columns (separate tables in case of
>  complex
>  attributes) only for this subset of attributes and all other
> attributes
>  will
>  be a part of a json blob.
>  With this option, we will have to go through a schema change in case
> we
>  decide to support search queries on other attributes at a later stage.
> 
>  I would like to know everyone's thoughts on these two approaches so
>  that we
>  can take a final decision and go ahead with one approach.
>  Suggestions regarding any other approaches are welcome too!
> 
>  Thanks,
>  Arati
> 
> 
>  ___
>  OpenStack-dev mailing list
>  OpenStack-dev@lists.openstack.org
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
>  --
>  Georgy Okrokvertskhov
>  Architect,
>  OpenStack Platform Products,
>  Mirantis
>  http://www.mirantis.com
>  Tel. +1 650 963 98

Re: [openstack-dev] VPC Proposal

[Martin, JC]

Joe,

See my comments in line.

On Feb 18, 2014, at 12:26 PM, Joe Gordon  wrote:

> On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC  wrote:
>> There was a lot of emails on that thread, but I am not seeing the discussion 
>> converging. I would like to reiterate my concerns:
>> 
>>   - We are trying to implement an API on a feature that is not supported by 
>> openstack
> 
> I don't see it that way. I see this BP as converting neutron calls
> into AWS VPC calls with a little glue (which can be seen here
> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support). But I am
> no networking expert, so take that with a large grain of salt.

If we had the supporting constructs, I would be in favor of implementing the 
AWS VPC features.

> 
>>   - As a result, the implementation is overloading existing construct 
>> without implementing full AWS capabilities and semantic (e.g. Shared network 
>> isolation from VPC, or Floating IP scoping to VPC).
> 
> A partial implementation is better then no implementation, that being
> said if we want to overhaul OpenStack's VPC capabilities I think the
> partial implementation would have to be thrown out.
I agree too. However, given the choice, I would have preferred that we first 
augment the neutron network access and sharing model before the building the 
API. It stills qualify as partial implementation, but at least in the right 
order.

> 
>>   - Dependent blueprints are not implemented and have been deferred, 
>> resulting in the broken implementation (e.g. 
>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron)
> 
> That is a requirement for phase 3, and shouldn't matter for phase 1
> and 2. And only phase 1 is up for review.
My point is that it does matter a it gives users the feeling that they get 
parity in term of isolation but they are not because of the missing isolation 
and sharing constructs.

> 
>>   - this "feature" is only available through EC2 API, which is likely going 
>> to result in another implementation for general use.
>>   - users adopting the VPC model proposed through EC2 API will be stuck in 
>> an upgrade mess when the proper implementation comes along.
> 
> This point concerns me the most, can you elaborate.

First, while AWS does not support projects they do support, trough IAM, very 
flexible policies for VPC resources access, see 
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html
If we wanted to reproduce this in openstack, we could map this to levels in the 
multi tenant hierarchy that Vish is proposing.
However, because this project put all the resources in the same VPC project, 
it's not possible anymore to implement the access policies without moving 
resources between projects or recreating the VPC.


> 
>>   - There are new constructs in work that are better suited for implementing 
>> this concept properly (Multi tenant hierarchy and domains).
> 
> 
> All that being said, it sounds like there are two separate efforts to
> get VPC into OpenStack, one by supporting AWS specs, and a second
> native OpenStack version.  It sounds like further discussion is needed
> between these two efforts, so I am unapproving
> https://blueprints.launchpad.net/nova/+spec/aws-vpc-support as it
> needs further discussion.  The last thing we want is to merge a
> controversial blueprint before all the questions can be resolved.

We should keep the discussion going as I'm sure that we can get to a better 
proposal.

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

Re: [openstack-dev] [Neutron][LBaaS] L7 data types

[Stephen Balukoff]

Oh!  One thing I forgot to mention below:


On Sat, Feb 15, 2014 at 11:55 PM, Avishay Balderman wrote:

>
> Entity:  L7Rule
>
> Field : compare_type
>
> Description: The way we compare the value against a given value
>
> Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?)
>
> *Note*: With REG_EXP we can cover the rest of the values.
>
>
>
I seem to recall reading in the haproxy manual that regex matches are
generally a lot slower than other kinds of matches. So, if you can do a
'path_beg' match, for example, that's a better performing choice over a
'path_reg' match which would accomplish the same thing. Given you have
mentioned that 'STARTS_WITH' and 'ENDS_WITH' are listed as compare_types
we're enumerating, I guess this has already been taken into account?



Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev