Re: [openstack-dev] [Fuel-dev] [Fuel][RabbitMQ] nova-compute stuck for a while (AMQP)

[Andrew Woodward]

Roman,

the current stable/4.1 has some fixes that make this less likely to
occur and is the most likely to recover.

That said, I've done some tracing and there are some issues with
nova-conductor processing those messages. Some of the times I've seen
the compute-node be the issue, other times I've seen nova-conductor be
the issue. As of stable/4.1 I've been able to track it down to
nova-conductor. AFAICT it receives the message from nova-compute,
takes it from the queue, acks the queue, and selects the object from
the DB. However after moving nova-compute and nova-conductor log trace
level in amqp and sqlalchemey, the issue appears to stop. I've yet to
confirm if the cluster state of rabbit changed, or if the change in
logging level changed it or something else.



On Tue, May 6, 2014 at 12:42 PM, Roman Sokolkov  wrote:
> Hello, fuelers.
>
> I'm using Fuel 4.1A + Havana in HA mode.
>
> I permanently observe (on other deployments also) issue with stuck
> "nova-compute" service. But i think problem is more fundamental and relates
> to HA RabbitMQ and OpenStack AMQP driver implementation.
>
> Symptoms:
>
> Random nova-compute from time to time marked as "XXX" for a while.
> I see that service itself works properly. In logs i see that it sends status
> updates to conductor. But actually nothing is sent.
> "netstat" shows that all connections to/from rabbit "ESTABLISHED"
> rabbitmqctl shows that "compute.node-x" queue synced to all slaves.
> nothing has been broken before, i mean rabbitmq cluster, etc.
>
> Axe style solution:
>
> /etc/init.d/openstack-nova-compute restart
>
> So here i've found a lot of interesting stuff (and solutions):
>
> https://bugs.launchpad.net/oslo.messaging/+bug/856764
>
>
> My questions are:
>
> Are there any thoughts particular for Fuel to solve/workaround this issue?
> Any fast solution for this in 4.1? Like adjust TCP keep-alive  timeouts?
>
>
> --
> Roman Sokolkov,
> Deployment Engineer,
> Mirantis, Inc.
> Skype rsokolkov,
> rsokol...@mirantis.com
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to : fuel-...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Andrew
Mirantis
Ceph community

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

Re: [openstack-dev] [DriverLog][nova][neutron][cinder] Call for vendor participation please

[Akihiro Motoki]

Hi,

Thanks for the effort.
While I am looking the website and the driver database,
I have a couple of questions and suggestions.

- Is it better to include "trunk" (= Juno) in "releases" in each driver
   if it is a part of the trunk or to wait it until Juno is released?
   We need some guidelines on this.
- Which is better as maintainer email, an individual mail address or CI 
account contact address?
   IMO an individual mail address looks better because CI account 
contact address receives
   all review comments and mails to the address can be missed or not 
noticed soon from my experience.
   It is better to have some guideline on the maintainer email.

- How is the status of "CI tested" determined?
   I am not sure how it is handled in Wiki informaiton.
- (Related to the above) How does DriverLog handle a case
   where multiple drivers are tested under once CI account?
   AFAIK some CI acounts run third party testing for multiple drivers.

- "releases" in "drivers" section is a list of release names now.
   It means we need to update "releases" in every release.
   I wonder we can support ["from_release", "to_release"] style.
If "to_release" is omitted, it means "trunk".

Thanks,
Akihiro

(2014/04/29 2:05), Jay Pipes wrote:
> Hi Stackers,
>
> Mirantis has been collaborating with a number of OpenStack 
> contributors and PTLs for the last couple months on something called 
> DriverLog. It is an effort to consolidate and display information 
> about the verification of vendor drivers in OpenStack.
>
> Current implementation is here:
>
> http://staging.stackalytics.com/driverlog/
>
> Public wiki here: https://wiki.openstack.org/wiki/DriverLog
>
> Code is here: https://github.com/stackforge/driverlog
>
> There is currently a plan by the foundation to publicly announce this 
> in the coming weeks.
>
> At this point Evgeniya Shumakher, in cc, is manually maintaining the 
> records, but we aspire for this to become a community driven process 
> over time with vendors submitting updates as described in the wiki and 
> PTLs and cores of the respective projects participating in update 
> reviews.
>
> A REQUEST: If you are vendor that has built an OpenStack driver, 
> please check that it is listed on the dashboard and update the record 
> (following the process in the wiki) to make sure the information is 
> accurately reflected. We want to make sure that the data is accurate 
> prior to announcing it to general public.
>
> Also, if anybody has a suggestion on what should be improved / changed 
> etc. == please don’t hesitate to share your ideas!
>
> Thanks!
> Jay and Evgeniya
>
> ___
> 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] Add VMware dvSwitch/vSphere API support for Neutron ML2

[Jussi Sorjonen]

Hi,

Just to give this some context, the original idea for the driver came from
the fact that there was no readily available method for using VLAN-backed
port groups in dvSwitches with neutron. We tried using nova-network with
regular vSwitches and VlanManager to evaluate the VMware driver in
nova-compute but it was decided that neutron is a an absolute requirement
for production use.

The current code of the driver is tested with nova-compute controlling a
vSphere 5.1 cluster. Multiple instances were successfully created,
attached to the correct port group and network connectivity was achieved.

We are not using VXLANs at the moment and are not actively looking into
deploying them, so implementing a VXLAN support in the driver is not
currently in our interest. Considering that VXLANs are configured as port
groups in dvSwitches on the VMware side there isn¹t much difference in
that part. However, configuring the VXLANs in the vShield app is something
I think is out of the scope of this driver.

We¹re interested in going through the blueprint process. Due to a rather
tight schedule on our end we had to get a limited-functionality version of
the driver ready before we had time to look into the process of submitting
a blueprint and the required specs. The current version of the driver
implements the only required feature in our environment - attaching
virtual machines on the VMware side to correct dvSwitch port groups.
Adding features like creating the port groups based on networks defined in
neutron etc. are in consideration.

I hope this answers some of the questions and I¹m happy to provide more
details, if needed.

Regards

--
Jussi Sorjonen, Systems Specialist, Data Center
+358 (0)50 594 7848, jussi.sorjo...@cybercom.com
Cybercom Finland Oy, Urho Kekkosen katu 3 B, 00100 Helsinki, FINLAND
www.cybercom.fi | www.cybercom.com




On 06/05/14 11:17, "Mathieu Rohon"  wrote:

>Hi IIkka,
>
>this is a very interesting MD for ML2. Have you ever tried to use your
>ML2 driver with VMWare drivers on the nova side, so that you could
>manage your VM with nova, and its network with neutron.
>Do you think it would be difficult to extend your driver to support
>vxlan encapsulation?
>
>Neutron has a new process to validate BP. Please follow those
>instructions to submit your spec for review :
>https://wiki.openstack.org/wiki/Blueprints#Neutron
>
>regards
>
>On Mon, May 5, 2014 at 2:22 PM, Ilkka Tengvall
> wrote:
>> Hi,
>>
>> I would like to start a discussion about a ML2 driver for VMware
>>distributed
>> virtual switch (dvSwitch) for Neutron. There is a new blueprint made by
>>Sami
>> Mäkinen (sjm) in
>> 
>>https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mech-vmware-dv
>>switch.
>>
>> The driver is described and code is publicly available and hosted in
>>github:
>> 
>>https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mech-vmware-dv
>>switch
>>
>> We would like to get the driver through contribution process, what ever
>>that
>> exactly means :)
>>
>> The original problem this driver solves for is is the following:
>>
>> We've been running VMware virtualization platform in our data center
>>before
>> OpenStack, and we will keep doing it due existing services. We also have
>> been running OpenStack for a while also. Now we wanted to get the most
>>out
>> of both by combining the customers networks on the both plafroms by
>>using
>> provider networks. The problem is that the networks need two separate
>> managers, neutron and vmware. There was no OpenStack tools to attach the
>> guests on VMware side to OpenStack provider networks during instance
>> creation.
>>
>> Now we are putting our VMware under control of OpenStack. We want to
>>have
>> one master to control the networks, Neutron. We implemented the new ML2
>> driver to do just that. It is capable of joining the machines created in
>> vSphere to the same provider networks the OpenStack uses, using dvSwitch
>> port groups.
>>
>>
>> I just wanted to open the discussion, for the technical details please
>> contact our experts on the CC list:
>>
>> Sami J. Mäkinen
>> Jussi Sorjonen (freenode: mieleton)
>>
>>
>> BR,
>>
>> Ilkka Tengvall
>>  Advisory Consultant, Cloud Architecture
>>  email:  ilkka.tengv...@cybercom.com
>>  mobile: +358408443462
>>  freenode: ikke-t
>>  web:http://cybercom.com - http://cybercom.fi
>>
>> ___
>> 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] [Neutron][LBaaS]User Stories and sruvey

[Samuel Bercovici]

Jorge,

It's your call. I prefer to gather information for now, if multiple people from 
the same organization will have drastically different answers, than this should 
also be considered.

-Sam.


From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Tuesday, May 06, 2014 9:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Sam,

I'm assuming you want one person from each company to answer correct? I'm 
pretty sure people in each organization will vote the same...at least I'd hope!

Cheers,
--Jorge

From: Samuel Bercovici mailto:samu...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, May 6, 2014 2:56 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi Everyone,

The survey is now live via: http://eSurv.org?u=lbaas_project_user
The password is: lbaas

The survey includes all the tenant facing use cases from 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing
Please try and fill the survey this week so we can have enough information to 
base decisions next week.

Regards,
-Sam.



From: Samuel Bercovici
Sent: Monday, May 05, 2014 4:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi,

I will not freeze the document to allow people to work on requirements which 
are not tenant facing (ex: operator, etc.)
I think that we have enough use cases for tenant facing capabilities to reflect 
most common use cases.
I am in the process of creation a survey in surveymonkey for tenant facing use 
cases and hope to send it to ML ASAP.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Thursday, May 01, 2014 8:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
Subject: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi Everyone!

To assist in evaluating the use cases that matter and since we now have ~45 use 
cases, I would like to propose to conduct a survey using something like 
surveymonkey.
The idea is to have a non-anonymous survey listing the use cases and ask you 
identify and vote.
Then we will publish the results and can prioritize based on this.

To do so in a timely manner, I would like to freeze the document for editing 
and allow only comments by Monday May 5th 08:00AMUTC and publish the survey 
link to ML ASAP after that.

Please let me know if this is acceptable.

Regards,
-Sam.



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

Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

[Samuel Bercovici]

The survey is not anonymous and I plan to publish it with its raw data we can 
then discuss how to interpret.
Each use case has an accompanying text field so that you can add any comments 
you wish.
At least I did add comments to most use cases when I responded :-)


-Sam.


-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] 
Sent: Tuesday, May 06, 2014 10:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

I agree that everyone's thoughts should be in it. I don't see why a 
representative vote does not allow for that. Sam put a text box on each use 
case to capture extra thoughts.

I would hope that no organization would be so confused as to have widely 
varying viewpoints on *what their customers want*, since that is the supposed 
purpose of all of this, right? We're supposed to be deciding which use-cases 
matter *to our customers*, so there should be no real variance for what I would 
vote versus what my teammates would vote, since we have the same customersŠ


Also, if we are using this as a type of voting mechanism then interests of 
large/vocal organizations drown out smaller organizations. If this is being 
used as a voting mechanism then how do you suggest we weight votes for smaller 
companies so that we do not alienate them from further voting/discussions?

Cheers,
--Jorge




On 5/6/14 1:52 PM, "Jay Pipes"  wrote:

>On 05/06/2014 02:42 PM, Jorge Miramontes wrote:
>> Sam,
>>
>> I'm assuming you want one person from each company to answer correct?
>> I'm pretty sure people in each organization will vote the sameŠat 
>> least I'd hope!
>
>I'd hope not! :)
>
>Even within the same organization or company, we all have different 
>ideas on use cases, the appropriateness of certain things "in the 
>cloud", and the role of a load balancer service in the general mix of 
>things.
>
>I certainly would hope that lots of Mirantis engineers other than 
>myself fill out the use case survey and offer their own insights.
>
>Best,
>-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] Commit the cinder Driver

[Swapnil Kulkarni]

Hi Mardan,


Thanks!

For the Cloudbyte ElastiStor I can see couple of (duplicate) blueprints
filed [1] [2].  You should probably assign one of them to you and update
 with details till we get cinder-spec available for blueprint review
process.

For details about commit process please refer [3].

For any issues with commit process, feel free to ask questions at
#openstack-cinder @ freenode.net

Also, you should try to attend Cinder meetings [4] to update the team about
your progress on commits and for any updates you should be having related
to new driver submissions.


[1]
https://blueprints.launchpad.net/cinder/+spec/cloudbyte-elastistor-iscsi-driver
[2]
https://blueprints.launchpad.net/cinder/+spec/cloudbyte-elastistor-iscsi-driver-cinder
[3] https://wiki.openstack.org/wiki/Gerrit_Workflow
[4] https://wiki.openstack.org/wiki/CinderMeetings


Best Regards,
Swapnil Kulkarni
irc : coolsvap
cools...@gmail.com
+91-87960 10622(c)
http://in.linkedin.com/in/coolsvap
*"It's better to SHARE"*


On Wed, May 7, 2014 at 11:24 AM, Mardan Raghuwanshi <
mardan.si...@cloudbyte.com> wrote:

> Hi All,
>
> I developed Cinder driver for CloudByte's ElastiStor, now I want to check
> in this code into master.
> I don't have more idea about git and OpenStack commit process, can you
> guys please guide me to commit the code into master branch.
>
>
> Thanks,
> Mardan
>
> ___
> 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] Commit the cinder Driver

[Mardan Raghuwanshi]

Hi All,

I developed Cinder driver for CloudByte's ElastiStor, now I want to check
in this code into master.
I don't have more idea about git and OpenStack commit process, can you guys
please guide me to commit the code into master branch.


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

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Irena Berezovsky]

I would like to join this discussion.

Thanks,
Irena

-Original Message-
From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] 
Sent: Tuesday, May 06, 2014 7:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking 
pod at the design summit?

For those attending, to discuss the QoS API current status?

-- 
Sean M. Collins
___
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] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

[Tripp, Travis S]

A few days ago I entered a client blueprint on the same topic [1], but maybe it 
has a server side dependency as well?

When it comes to scheduling, as far as I have been able to tell from looking at 
Nova code, the scheduler is only getting volume_image_metadata and not the 
regular cinder_metadata.  So, if you want to add some volume_image_metadata for 
scheduler filtering or for passing compute driver options through after 
creating a volume, there doesn't seem to be a way to do this from the 
python-cinderclient.  If I'm wrong, please correct me.

[1] 
https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata
 

> -Original Message-
> From: Mike Perez [mailto:thin...@gmail.com]
> Sent: Tuesday, May 06, 2014 9:10 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Cinder] Confusion about the respective use cases
> for volume's admin_metadata, metadata and glance_image_metadata
> 
> On 06:31 Wed 07 May , Trump.Zhang wrote:
> > Thanks for your further instructions.
> >
> > I think the situations I mentioned are the reasonable use cases. They
> > are similar to the "bootable" volume use cases, user can create an
> > empty volume and install os in it from an image or create bootable
> > volume from instance ([1]).
> >
> > If volume metadata is not intended to be interpreted by cinder or nova
> > as meaning anything, maybe Cinder needs to add support for updating
> > some of glance_image_metadata of volume or introduce new property for
> > volume like "bootable" ? I don't think these two methods are good either.
> >
> > [1] https://blueprints.launchpad.net/cinder/+spec/add-bootable-option
> 
> Volume already has a bootable field:
> 
> https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/model
> s.py#L122
> 
> --
> Mike Perez
> 
> ___
> 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] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

[Mike Perez]

On 06:31 Wed 07 May , Trump.Zhang wrote:
> Thanks for your further instructions.
> 
> I think the situations I mentioned are the reasonable use cases. They are
> similar to the "bootable" volume use cases, user can create an empty volume
> and install os in it from an image or create bootable volume from instance
> ([1]).
> 
> If volume metadata is not intended to be interpreted by cinder or nova as
> meaning anything, maybe Cinder needs to add support for updating some of
> glance_image_metadata of volume or introduce new property for volume like
> "bootable" ? I don't think these two methods are good either.
> 
> [1] https://blueprints.launchpad.net/cinder/+spec/add-bootable-option

Volume already has a bootable field:

https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/models.py#L122

-- 
Mike Perez

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

Re: [openstack-dev] [Keystone] keystoneclient and project-less v3 tokens

[Dolph Mathews]

On Tue, May 6, 2014 at 3:17 AM, Roman Bodnarchuk <
roman.bodnarc...@indigitus.ch> wrote:

> Thanks for reply.  I think I got the justifications for such an approach.
>
> BTW, is there a resource, which can be used to track support of Keystone
> v3 (and domain-based policies) among OS services?  Are there some defined
> plans for moving whole OS to v3 and domains?
>
>
That's the goal of this blueprint, which will be discussing at the summit:


https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition


> --
> Roman
>
>
> On 4/28/2014 6:43 AM, Jamie Lennox wrote:
>
>> On Thu, 2014-04-17 at 19:58 +0300, Roman Bodnarchuk wrote:
>>
>>> Hello,
>>>
>>> I am trying to make sure that a user can't do anything useful with an
>>> unscoped token, and got to the following code in
>>> keystoneclient.middleware.auth_token:
>>>
>>>   if _token_is_v2(token_info) and not auth_ref.project_id:
>>>   raise InvalidUserToken('Unable to determine tenancy.')
>>>
>>> This check is performed on every request, and successfully forbids any
>>> request authenticated by a project-less token.  But only for v2 tokens!
>>>
>>> In case service is using v3 of Keystone api, the request successfully
>>> passes auth_token middleware filter, and it becomes the task of each
>>> specific service to handle unscopedness of passed token.
>>>
>>> While Nova seem to be handling this well (basing on several tests I
>>> made), I was able to fetch a list of available images from Glance using
>>> a token of projectless user.
>>>
>>> Is this a desired behavior of keystoneclient?
>>> Why do we check existence of project_id only for v2 tokens?
>>>
>>> Thanks,
>>> Roman
>>>
>> Hmm, that is fairly old code. Submitted before v3 tokens were even on
>> the scene it looks like.
>>
>> As an educated guess here i expect that it's because a v3 token can be
>> scoped to multiple things. It can be scoped to a project, a domain or a
>> service - or not at all (which would be the same thing as scoping it to
>> the keystone service).
>>
>> The more correct way to do this would be to enforce the need for a
>> project scope on the service that requires the project scope. Not all
>> services or all actions will need a project scope and there is no reason
>> to prevent them access to the service if a project scope is unneeded.
>>
>> On the other hand whilst that is a good justification for leaving things
>> as they are i'm guessing the _reason_ that it is enforced in v2 and some
>> scope is not enforced in v3 is mostly an accident.
>>
>>
>> Jamie
>>
>>> ___
>>> 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] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project

[Mohammad Banikazemi]

Hi Mike, Thanks for your interest in OpenStack and Neutron. Are there any
published papers you can point us to? It may be easier to understand your
work by reading/reviewing your papers.

Best,

Mohammad




From:   Mike Grima 
To: openstack-dev@lists.openstack.org,
Date:   05/06/2014 09:21 PM
Subject:[openstack-dev] [Neutron][FWaaS]Firewall Web Services Research
Thesis Applicability to the OpenStack Project



Hi Everyone,

I am an Information Security grad student, and I am wrapping up a thesis
on exposing host firewall capabilities via web services for KVM virtual
machines. The purpose of which is to:
A.  Make the firewall management of KVM virtual machines easier to
perform on the host (from the KVM administrator’s perspective)
B.  Provide the ability to enforce network security policies on
hosted virtual machines via the host’s firewall.
C.  Provide the ability for future security appliances and
vulnerability scanners to leverage the exposed web services to
close network security vulnerabilities on hosted virtual
machines (via modification of the host’s firewall rules). This
can allow security appliances to automatically respond to
security incidents as they occur.

I just recently stumbled upon the OpenStack project, and noticed the
Firewall as a Service (FWaaS) plugin and documentation that has been
developed this past year.  There are a lot of similarities to my thesis,
and I would like to know if some of the research I have performed could
be of value to the OpenStack project.  Perhaps they could be useful in
the development of use cases, or maybe inspire future ideas for
enhancements and features?  I am still in the process of wrapping up
the thesis, so I would like to avoid posting it for the time being.
However, once I have completed the write-up, I would be more than
happy to share it with the OpenStack community.

I have recorded screen videos showcasing the above three points in
action.  Perhaps the most relevant to recent events is the 4th video,
which showcases how FWaaS (in general, not the OpenStack plugin) could
be used by OpenVAS (in this case) to detect virtual machines that are
vulnerable to Heartbleed, and immediately issue a command to the web
service to close access to the HTTPS port.

The web-services are being exposed via a Java Jetty web server running
on the KVM host itself.  I made a Java client app for interfacing with
the web services.

Below are the videos:
1.) Demo 1: Adding new rules/policies and manipulating traffic
https://docs.google.com/file/d/0B7WyzOL96X9QU0dQa0xEekFxVlk/edit

2.) Demo 2: Same as Demo 1, but showcasing platform independence by
applying rules to a Windows Server 2008 R2 VM
https://docs.google.com/file/d/0B7WyzOL96X9QMnRaZXBhU1FFc28/edit

3.) Sample OpenVAS Scenario where a VM can --only-- operate a HTTP
server on port 80.  Any other server that is detected is a
violation of policy and would need to be blocked.
https://docs.google.com/file/d/0B7WyzOL96X9QYXdFdC1XbHp2R3M/edit

4.) OpenVAS Heartbleed Demo (as described above):
https://docs.google.com/file/d/0B7WyzOL96X9QMzRMR1UzX09vRDA/edit

5.) Earlier prototype of my thesis working with XEN instead of KVM:
https://docs.google.com/file/d/0B7WyzOL96X9QTVowem1ZYjJrRWM/edit

Please let me know if the above could prove useful for the OpenStack
project.  Concurrence from you guys would be helpful illustrating the
significance of my research.

Thank You,

Mike Grima, RHCE


___
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] [Neutron][ml2] Etherpad for the design session on Modular L2 Agents

[Mandeep Dhami]

Thanks Mohammad, this is sorely needed. I will update ether pad for our
"needs".

Regards,
Mandeep


On Tue, May 6, 2014 at 7:01 PM, Mohammad Banikazemi  wrote:

> Thanks for the suggestion. That's what I plan to do next (barring other
> possible suggestions). While the sharing is limited in some cases, it
> appears to be significant in other cases (e.g., the ovs and the mlnx
> agents).
>
> Best,
>
> Mohammad
>
> [image: Inactive hide details for yamamoto---05/06/2014 08:24:18 PM--->
> Please note that I have created an etherpad for the Modular 
> L2]yamamoto---05/06/2014
> 08:24:18 PM---> Please note that I have created an etherpad for the Modular
> L2 Agent > session at [1].
>
> From: yamam...@valinux.co.jp (YAMAMOTO Takashi)
> To: openstack-dev@lists.openstack.org,
> Date: 05/06/2014 08:24 PM
> Subject: Re: [openstack-dev] [Neutron][ml2] Etherpad for the design
> session on Modular L2 Agents
> --
>
>
>
> > Please note that I have created an etherpad for the Modular L2 Agent
> > session at [1].
> > It relates to one of the three topics that are to be discussed during the
> > "Modular Layer2 Agent" design session scheduled for Thursday
> > 11:50am-12:30pm [2].
> > Please update the etherpad and/or use the ML or contact me if you have
> any
> > comments/suggestions/criticism. (I have also asked several people who
> have
> > worked on the agents and/or expressed interest in this topic individually
> > for their input.)
>
> can you pick a few existing agents (eg. ovs and lb) and prototype
> a modular agent to demonstrate how much of the code can be shared
> by this effort?
>
> YAMAMOTO Takashi
>
> >
> > Thanks,
> >
> > -Mohammad
> >
> > [1] https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
> > [2]
> >
> http://junodesignsummit.sched.org/event/4205f2c4084e8a0c3bd8d420803ddf02#.U2k7RdyZpjI
>
> ___
> 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] [Neutron][ml2] Etherpad for the design session on Modular L2 Agents

[Mohammad Banikazemi]

Thanks for the suggestion. That's what I plan to do next (barring other
possible suggestions). While the sharing is limited in some cases, it
appears to be significant in other cases (e.g., the ovs and the mlnx
agents).

Best,

Mohammad



From:   yamam...@valinux.co.jp (YAMAMOTO Takashi)
To: openstack-dev@lists.openstack.org,
Date:   05/06/2014 08:24 PM
Subject:Re: [openstack-dev] [Neutron][ml2] Etherpad for the design
session on Modular L2 Agents



> Please note that I have created an etherpad for the Modular L2 Agent
> session at [1].
> It relates to one of the three topics that are to be discussed during the
> "Modular Layer2 Agent" design session scheduled for Thursday
> 11:50am-12:30pm [2].
> Please update the etherpad and/or use the ML or contact me if you have
any
> comments/suggestions/criticism. (I have also asked several people who
have
> worked on the agents and/or expressed interest in this topic individually
> for their input.)

can you pick a few existing agents (eg. ovs and lb) and prototype
a modular agent to demonstrate how much of the code can be shared
by this effort?

YAMAMOTO Takashi

>
> Thanks,
>
> -Mohammad
>
> [1] https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
> [2]
>
http://junodesignsummit.sched.org/event/4205f2c4084e8a0c3bd8d420803ddf02#.U2k7RdyZpjI


___
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][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project

[Mike Grima]

Hi Everyone,

I am an Information Security grad student, and I am wrapping up a thesis
on exposing host firewall capabilities via web services for KVM virtual
machines. The purpose of which is to:
A.  Make the firewall management of KVM virtual machines easier to
perform on the host (from the KVM administrator’s perspective)
B.  Provide the ability to enforce network security policies on
hosted virtual machines via the host’s firewall.
C.  Provide the ability for future security appliances and
vulnerability scanners to leverage the exposed web services to
close network security vulnerabilities on hosted virtual
machines (via modification of the host’s firewall rules). This
can allow security appliances to automatically respond to
security incidents as they occur.

I just recently stumbled upon the OpenStack project, and noticed the 
Firewall as a Service (FWaaS) plugin and documentation that has been 
developed this past year.  There are a lot of similarities to my thesis,
and I would like to know if some of the research I have performed could
be of value to the OpenStack project.  Perhaps they could be useful in
the development of use cases, or maybe inspire future ideas for 
enhancements and features?  I am still in the process of wrapping up
the thesis, so I would like to avoid posting it for the time being.
However, once I have completed the write-up, I would be more than
happy to share it with the OpenStack community.

I have recorded screen videos showcasing the above three points in 
action.  Perhaps the most relevant to recent events is the 4th video,
which showcases how FWaaS (in general, not the OpenStack plugin) could
be used by OpenVAS (in this case) to detect virtual machines that are
vulnerable to Heartbleed, and immediately issue a command to the web
service to close access to the HTTPS port.

The web-services are being exposed via a Java Jetty web server running
on the KVM host itself.  I made a Java client app for interfacing with
the web services.

Below are the videos:
1.) Demo 1: Adding new rules/policies and manipulating traffic
https://docs.google.com/file/d/0B7WyzOL96X9QU0dQa0xEekFxVlk/edit

2.) Demo 2: Same as Demo 1, but showcasing platform independence by
applying rules to a Windows Server 2008 R2 VM
https://docs.google.com/file/d/0B7WyzOL96X9QMnRaZXBhU1FFc28/edit

3.) Sample OpenVAS Scenario where a VM can --only-- operate a HTTP
server on port 80.  Any other server that is detected is a
violation of policy and would need to be blocked.
https://docs.google.com/file/d/0B7WyzOL96X9QYXdFdC1XbHp2R3M/edit

4.) OpenVAS Heartbleed Demo (as described above):
https://docs.google.com/file/d/0B7WyzOL96X9QMzRMR1UzX09vRDA/edit

5.) Earlier prototype of my thesis working with XEN instead of KVM:
https://docs.google.com/file/d/0B7WyzOL96X9QTVowem1ZYjJrRWM/edit

Please let me know if the above could prove useful for the OpenStack
project.  Concurrence from you guys would be helpful illustrating the
significance of my research.

Thank You,

Mike Grima, RHCE


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

Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)

[Zane Bitter]

On 05/05/14 13:40, Solly Ross wrote:

One thing that I was discussing with @jaypipes and @dansmith over
on IRC was the possibility of breaking flavors down into separate
components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor.
This way, you still get the control of the size of your building blocks
(e.g. you could restrict RAM to only 2GB, 4GB, or 16GB), but you avoid
exponential flavor explosion by separating out the axes.


Dimitry and I have discussed this on IRC already (no-one changed their 
mind about anything as a result), but I just wanted to note here that I 
think even this idea is crazy.


VMs are not allocated out of a vast global pool of resources. They're 
allocated on actual machines that have physical hardware costing real 
money in fixed ratios.


Here's a (very contrived) example. Say your standard compute node can 
support 16 VCPUs and 64GB of RAM. You can sell a bunch of flavours: 
maybe 1 VCPU + 4GB, 2 VCPU + 8GB, 4 VCPU + 16GB... &c. But if (as an 
extreme example) you sell a server with 1 VCPU and 64GB of RAM you have 
a big problem: 15 VCPUs that nobody has paid for and you can't sell. 
(Disks add a new dimension of wrongness to the problem.)


The insight of flavours, which is fundamental to the whole concept of 
IaaS, is that users must pay the *opportunity cost* of their resource 
usage. If you allow users to opt, at their own convenience, to pay only 
the actual cost of the resources they use regardless of the opportunity 
cost to you, then your incentives are no longer aligned with your 
customers. You'll initially be very popular with the kind of customers 
who are taking advantage of you, but you'll have to hike prices across 
the board to make up the cost leading to a sort of dead-sea effect. A 
Gresham's Law of the cloud, if you will, where bad customers drive out 
good customers.


Simply put, a cloud allowing users to define their own flavours *loses* 
to one with predefined flavours 10 times out of 10.


In the above example, you just tell the customer: bad luck, you want 
64GB of RAM, you buy 16 VCPUs whether you want them or not. It can't 
actually hurt to get _more_ than you wanted, even though you'd rather 
not pay for it (provided, of course, that everyone else *is* paying for 
it, and cross-subsidising you... which they won't).


Now, it's not the OpenStack project's job to prevent operators from 
going bankrupt. But I think at the point where we are adding significant 
complexity to the project just to enable people to confirm the 
effectiveness of a very obviously infallible strategy for losing large 
amounts of money, it's time to draw a line.



By the way, the whole theory behind this idea seems to be that this:

  nova server-create --cpu-flavor=4 --ram-flavour=16G --disk-flavor=200G

minimises the cognitive load on the user, whereas this:

  nova server-create --flavor=4-64G-200G

will cause the user's brain to explode from its combinatorial 
complexity. I find this theory absurd.


In other words, if you really want to lose some money, it's perfectly 
feasible with the existing flavour implementation. The operator is only 
ever 3 for-loops away from setting up every combination of flavours 
possible from combining the CPU, RAM and disk options, and can even 
apply whatever constraints they desire.



All that said, Heat will expose any API that Nova implements. Choose wisely.

cheers,
Zane.

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

Re: [openstack-dev] Fuel

[Roman Sokolkov]

Tizy,

Selinux is disabled on all nodes under Fuel.

https://github.com/stackforge/fuel-library/blob/stable/4.0/deployment/puppet/cobbler/templates/kickstart/centos.ks.erb#L32


You could check it by "getenforce" command. It should report "Disabled".

So you could simply pass all steps related to Selinux.

Thank you.


On Tue, May 6, 2014 at 12:51 AM, Tizy Ninan  wrote:

> Hi
>
> We are trying to integrate the openstack setup with the Microsoft Active
> Directory(LDAP server).
>
> As per openstack documentation,
> http://docs.openstack.org/admin-guide-cloud/content/configuring-keystone-for-ldap-backend.html
>   in
> order to integrate with an LDAP server, an SELinux Boolean variable
> ‘authlogin_nsswitch_use_ldap’ needs to be set. We tried setting the
> variable using the following command.
> $ setsebool –P authlogin_nsswitch_use_ldap 1
> It returned a message stating SElinux is disabled. We changed the status
> of SElinux to permissive mode and tried setting the boolean variable, but
> it returned a message stating ‘record not found in the database’.
>
> We also tried retrieving all the boolean variables by using the following
> command
> $getsebool –a
> It listed out all the boolean variables, but there was no variable named
> ‘authlogin_nsswitch_use_ldap’ in the list.
> In order to add the variable we needed semanage. When executing the
> ‘semanage’ command it returned ‘command not found’. To install semanage we
> tried installing policycoreutils-python. It showed no package
> policycoreutils-python available.
>
> We are using Mirantis Fuel v4.0. We have an openstack Havana deployment on
> CentOS 6.4 and nova-network network service.
> Can you please help us on why the SELinux boolean variable
> (authlogin_nsswitch_use_ldap) is not available. Is it because the CentOS
> image provided by the Fuel master node  does not provide the SELinux
> settings?  Is there any alternative ways to set this boolean variable?
>
> Kindly help us to resolve this issue.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Roman Sokolkov,
Deployment Engineer,
Mirantis, Inc.
Skype rsokolkov,
rsokol...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

[Jeremy Stanley]

On 2014-04-29 18:31:37 + (+), Jeremy Stanley wrote:
> I've updated the wiki article to note that I'll lock it for further
> edits at the end of the (UTC) day on the 7th and generate the
> checksummed list from it, then link it there for everyone to
> download as quickly as I can do so. I'll also send a signed copy of
> the checksummed list in reply to this thread at the same time.

Just a friendly reminder that the deadline to sign up is a little
over 23 hours away! So far we've got 55 people on the list, by my
count.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron][ml2] Etherpad for the design session on Modular L2 Agents

[YAMAMOTO Takashi]

> Please note that I have created an etherpad for the Modular L2 Agent
> session at [1].
> It relates to one of the three topics that are to be discussed during the
> "Modular Layer2 Agent" design session scheduled for Thursday
> 11:50am-12:30pm [2].
> Please update the etherpad and/or use the ML or contact me if you have any
> comments/suggestions/criticism. (I have also asked several people who have
> worked on the agents and/or expressed interest in this topic individually
> for their input.)

can you pick a few existing agents (eg. ovs and lb) and prototype
a modular agent to demonstrate how much of the code can be shared
by this effort?

YAMAMOTO Takashi

> 
> Thanks,
> 
> -Mohammad
> 
> [1] https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
> [2]
> http://junodesignsummit.sched.org/event/4205f2c4084e8a0c3bd8d420803ddf02#.U2k7RdyZpjI

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

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Mohammad Banikazemi]

There are networking talks in the general session in the afternoon on
Thursday including the talk on Network Policies from 1:30 to 2:10pm.
Anything after that is ok with me.

Thanks,

Mohammad




From:   Kevin Benton 
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date:   05/06/2014 07:08 PM
Subject:Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the
Networking pod at the design summit?



+1


On Tue, May 6, 2014 at 3:50 PM, Collins, Sean <
sean_colli...@cable.comcast.com> wrote:
  On Tue, May 06, 2014 at 03:04:09PM EDT, Mohammad Banikazemi wrote:
  >
  > +1.
  >
  > Please announce a date/time here so we can perhaps avoid any conflicts
  with
  > others who plan to use the networking pod.
  >
  > Best,

  Agreed. So - Thursday seems to be a pretty light in the afternoon -
  there are only design summit sessions in the morning, perhaps that would
  be the best time?

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



--
Kevin Benton___
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] Hierarchicical Multitenancy Discussion

[Vishvananda Ishaya]

This is a bit different from how I would have expected it to work. It appears 
that you are adding the role assignment when the project is created. IMO the 
role should be added to the list when the roles are checked. In other words, 
when getting the list of roles for a user/project, it walks up the tree to find 
all parent projects and creates a list of roles that includes all of the parent 
roles for that user that are marked inheritable. The implementation you made 
seems very fragile if parent projects are changed etc.

Vish

On Apr 14, 2014, at 12:17 PM, Raildo Mascena  wrote:

> Hi all,
> 
> As I had promised, here is the repository of Telles Nobrega 
> (https://github.com/tellesnobrega/keystone/tree/multitenancy) updated now 
> with inherited roles working with hierarchical projects.
> 
> How ​does ​it work​​?
> 
> ​I​nherited roles operate in the following way:
> - It should be added​ a role ​to​ be inherited to a domain using the api "PUT 
> localhost:35357/v3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects".
> - It should be create​d​ a hierarchical project as described above for Telles.
> - List the assignments roles "GET localhost: 35357/v3/role_assignments"  and 
> check that the role inherited is already associated with this new project. 
> 
> What was implemented? 
> The implementation consists of filter​ing​ roles which are associated with 
> the parent project to be inherited (this is done by checking the assigment 
> table) for them to be added to the child project. Also a filter has been 
> created to ensure that a role inherited from another domain does not 
> interfere in the inheritance of this project.
> 
> What remains to implement?
> 
> Role inherit​ance​ has been implemented to work with domains, so the role 
> will be inherited to all projects contained this domain, ie, a role that is 
> marked to be inherited, even if it is not associated with the parent project, 
> will be inherited to the child project. In my opinion, should ​be ​create​d​ 
> a "project" column in the "assignment" that would indicate where to start 
> inheritance projects, it would be possible to finish this feature. (This is 
> just a suggestion, I believe ​there are other ways to make it work).
> 
> 
> 2014-03-17 8:04 GMT-03:00 Telles Nobrega :
> That is good news, I can have both information sent to nova really easy. I 
> just need to add a field into the token, or more than one if needed. RIght 
> now I send Ids, it could names just as easily and we can add a new field so 
> we can have both information sent. I'm not sure which is the best option for 
> us but i would think that sending both for now would keep the compatibility 
> and we could still use the names for display porpuse 
> 
> 
> On Sun, Mar 16, 2014 at 9:18 AM, Jay Pipes  wrote:
> On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote:
> > Awesome, this is exactly what I was thinking. I think this is really
> > close to being usable on the nova side. First of all the
> > dot.sperated.form looks better imo, and I think my code should still
> > work that way as well. The other piece that is needed is mapping ids
> > to names for display purposes. I did something like this for a
> > prototype of names in dns caching that should work nicely. The
> > question simply becomes how do we expose those names. I’m thinking we
> > have to add an output field to the display of objects in the system
> > showing the fully qualified name.  We can then switch the display in
> > novaclient to show names instead of ids.  That way an admin listing
> > all the projects in orga would see the owner as orga.projb instead of
> > the id string.
> >
> > The other option would be to pass names instead of ids from keystone
> > and store those instead. That seems simpler at first glance, it is not
> > backwards compatible with the current model so it will be painful for
> > providers to switch.
> 
> -1 for "instead of". "in addition to" would have been fine, IMO.
> 
> Best,
> -jay
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> --
> Telles Mota Vidal Nobrega
> Bsc in Computer Science at UFCG
> Software Engineer at PulsarOpenStack Project - HP/LSD-UFCG
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Raildo Mascena
> Bachelor of Computer Science. 
> Software Engineer at Laboratory of Distributed Systems - UFCG
> ___
> 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
_

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Kevin Benton]

+1


On Tue, May 6, 2014 at 3:50 PM, Collins, Sean <
sean_colli...@cable.comcast.com> wrote:

> On Tue, May 06, 2014 at 03:04:09PM EDT, Mohammad Banikazemi wrote:
> >
> > +1.
> >
> > Please announce a date/time here so we can perhaps avoid any conflicts
> with
> > others who plan to use the networking pod.
> >
> > Best,
>
> Agreed. So - Thursday seems to be a pretty light in the afternoon -
> there are only design summit sessions in the morning, perhaps that would
> be the best time?
>
> --
> Sean M. Collins
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [tripleo] Decreasing resource usage in tripleo CI

[Clint Byrum]

+1 to the plans.

We've recently freed up a few more boxes for the HP region, and we'll
be rolling those out as we migrate from saucy to trusty for the rest of
the cloud. But we should do all of the things below anyway.

Excerpts from Derek Higgins's message of 2014-05-06 15:34:41 -0700:
> Hi,
> 
>I mentioned this at the tripleo meeting today and to get opinions out
> there I'd like to bring it up here,
> 
> In tripleo we are currently very tight on resources to run our CI jobs
> and I'd like to scale back temporarily until we have either more
> capacity or reorganize things a bit, to more efficiently use what we
> have. Basically I'd like to see us do 3 things
> 
> 1. Get rid of check-tripleo-seed-precise job
>This is currently a subset of both check-tripleo-undercloud-precise
> and check-tripleo-overcloud-precise so is basically using up resources
> with no extra gain, if we put plans in place to deploy the
> undercloud/overcloud on a persistent seed we can add it back again.
> 
> 2. Move the check-tripleo-ironic-undercloud-precise into the
> experimental-tripleo queue, this test is non voting and currently
> doesn't work, when its fixed we can put it back into the check-tripleo
> queue and delete the check-tripleo-ironic-seed-precise job, as it should
> be a subset of the ironic undercloud job (similar to the seed job
> mentioned in point 1)
> 
> 3. Get back onto 8G nodepool instances, we moved to 16G instances a
> while back to work around a problem,
>  I've a patch up that should allow us to get back to 8G nodes
> https://review.openstack.org/#/c/91545/
> 
> Any objections or alternate ideas?
> 
> thanks,
> Derek.
> 

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

Re: [openstack-dev] [infra] Intermittent network problems allowed to sneak passed the gate?

[Jeremy Stanley]

On 2014-05-06 15:52:04 +0100 (+0100), Derek Higgins wrote:
[...]
> The job simply got restarted and this kept happening until the job passed.
> 
> A legitimately failed job :
>   https://jenkins05.openstack.org/job/check-nova-docker-dsvm-f20/2/
> 
> http://logs.openstack.org/14/91514/5/check/check-nova-docker-dsvm-f20/d5c1ebf/console.html
[...]

If the job fails in such a way that it impacts communication between
the slave and the Jenkins master, or tanks the slave so badly that
it ceases responding entirely, Jenkins often does not report a build
completion status. Because this happens rather unfortunately often
due to the nature of connectivity in service providers and due to
bugs in Jenkins, Zuul assumes it should automatically reattempt any
job which ceases running without explanation.

Perhaps one option would be to keep a retry counter and not
reattempt a job which fails in this manner more than once or
twice...?
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Collins, Sean]

On Tue, May 06, 2014 at 03:04:09PM EDT, Mohammad Banikazemi wrote:
> 
> +1.
> 
> Please announce a date/time here so we can perhaps avoid any conflicts with
> others who plan to use the networking pod.
> 
> Best,

Agreed. So - Thursday seems to be a pretty light in the afternoon -
there are only design summit sessions in the morning, perhaps that would
be the best time?

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

[openstack-dev] [Neutron][ml2] Etherpad for the design session on Modular L2 Agents

[Mohammad Banikazemi]

Please note that I have created an etherpad for the Modular L2 Agent
session at [1].
It relates to one of the three topics that are to be discussed during the
"Modular Layer2 Agent" design session scheduled for Thursday
11:50am-12:30pm [2].
Please update the etherpad and/or use the ML or contact me if you have any
comments/suggestions/criticism. (I have also asked several people who have
worked on the agents and/or expressed interest in this topic individually
for their input.)

Thanks,

-Mohammad

[1] https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
[2]
http://junodesignsummit.sched.org/event/4205f2c4084e8a0c3bd8d420803ddf02#.U2k7RdyZpjI___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Decreasing resource usage in tripleo CI

[Derek Higgins]

Hi,

   I mentioned this at the tripleo meeting today and to get opinions out
there I'd like to bring it up here,

In tripleo we are currently very tight on resources to run our CI jobs
and I'd like to scale back temporarily until we have either more
capacity or reorganize things a bit, to more efficiently use what we
have. Basically I'd like to see us do 3 things

1. Get rid of check-tripleo-seed-precise job
   This is currently a subset of both check-tripleo-undercloud-precise
and check-tripleo-overcloud-precise so is basically using up resources
with no extra gain, if we put plans in place to deploy the
undercloud/overcloud on a persistent seed we can add it back again.

2. Move the check-tripleo-ironic-undercloud-precise into the
experimental-tripleo queue, this test is non voting and currently
doesn't work, when its fixed we can put it back into the check-tripleo
queue and delete the check-tripleo-ironic-seed-precise job, as it should
be a subset of the ironic undercloud job (similar to the seed job
mentioned in point 1)

3. Get back onto 8G nodepool instances, we moved to 16G instances a
while back to work around a problem,
 I've a patch up that should allow us to get back to 8G nodes
https://review.openstack.org/#/c/91545/

Any objections or alternate ideas?

thanks,
Derek.

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

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

[Trump.Zhang]

Thanks for your further instructions.

I think the situations I mentioned are the reasonable use cases. They are
similar to the "bootable" volume use cases, user can create an empty volume
and install os in it from an image or create bootable volume from instance
([1]).

If volume metadata is not intended to be interpreted by cinder or nova as
meaning anything, maybe Cinder needs to add support for updating some of
glance_image_metadata of volume or introduce new property for volume like
"bootable" ? I don't think these two methods are good either.

[1] https://blueprints.launchpad.net/cinder/+spec/add-bootable-option


2014-05-07 1:00 GMT+08:00 Duncan Thomas :

> On 6 May 2014 14:46, Trump.Zhang  wrote:
>
> > Did you mean using volume metadata was not the right way for the first
> > situation I mentioned in ealier mail?
>
>
> Correct. Volume metadata is entirely for the tenant to use, it is not
> interpreted by cinder or nova as meaning anything.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
---
Best Regards

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

[openstack-dev] [Horizon] [UX] Better Dashboard Pages Summit Session

[Jacki Bauer]

Hi all,
Some Horizon people will be talking about improving overview/dashboard pages at 
the summit. We¹ll be showing some design concepts during the Dashboard 
Accessibility session on Friday at 9:50 am (this is a combined session). We’d 
like to find out if we are on the right track with some design concepts.

Here¹s a preview of the mockups -
Admin and User Concepts option 1 (PDF): http://bit.ly/1nmgVrC
Admin Concept option 2: 
http://people.redhat.com/~lsurette/OpenStack/Horizon%20Admin%20Overview%20Pages_2.0.pdf
User Concept option 2: 
http://people.redhat.com/~lsurette/OpenStack/Horizon%20Overview%20Pages_v1.0.pdf

And a link to the etherpad -
https://etherpad.openstack.org/p/juno-summit-overview-page-horizon

Best,
Jacki


.
Jacki Bauer
User Experience Designer
Rackspace Private Cloud
512.874.1226

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

[openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient

[Jamie Lennox]

All, 

TL;DR: novaclient should be able to use the common transport/auth layers of 
keystoneclient. If it does there are going to be functions like 
client.authenticate() that won't operate the same way when a session object is 
passed. For most users who just use the CRUD operations there will be no 
difference. 


I'm hoping that at least some of the nova community has heard of the push for 
using keystoneclient's Session object across all the clients. For those unaware 
keystoneclient.session.Session is a common transport and authentication layer 
to remove the need for each python-*client having there own authentication 
configuration and disparate transport options.

It offers:
 - a single place for updates to transport (eg fixing TLS or other transport 
issues in one place)
 - a way for all clients to immediately support the full range of keystone's 
authentication including v3 auth, SAML, kerberos etc
 - a common place to handle version discovery such that we support multiple 
version endpoints from the same service catalog endpoint.

For information of how to interact with a session you can see: 
http://www.jamielennox.net/blog/2014/02/24/client-session-objects/ This 
mentions the code is uncommitted however has since been committed with a few 
small details around parameter names being changed. The theory remains the 
same. 


To integrate this into novaclient means that if a session= object is passed 
then the standard HTTPClient code will be ignored in favour of using what was 
passed. This means that there are changes in the API of the client. In 
keystoneclient we have take the opinion that by passing a session object then 
you opt-in to the newer API and therefore accept that some functions are no 
longer available. For example client.authenticate() is no longer allowed 
because authentication is not the client's responsibility. It will have no 
impact on the standard novaclient CRUD operations and so be un-noticed by the 
vast majority of users.

The review showing these changes is here: https://review.openstack.org/#/c/85920

To enable this there are a series of test changes to mock client requests at 
the HTTP layer rather than in the client. This means that we can test that all 
client operations against the new and old client construction methods and 
ensure the same requests are being sent. The foundation of this to turn tests 
into fixtures can be found by following: 
https://blueprints.launchpad.net/python-novaclient/+spec/httpretty-testing

IMO making these tests into fixtures is a good idea anyway, however I am only 
pursuing it so that we can transition to using a common Session.

Regarding dependencies, novaclient will need a test-requirements.txt on 
keystoneclient so that it can construct Session objects to test with but it 
should not need a requirements.txt as the session object is constructed by the 
user of the client (eg openstackclient, horizon etc).


If there are concerns with this process please respond here and/or on the 
review.


Thanks, 

Jamie

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

Re: [openstack-dev] Monitoring as a Service

[Hochmuth, Roland M]

It sounds like there is some interest in this topic. With the Summit
just around the corner, I propose we get together while many
of us are there and explore this area further. I'm in the process of
researching the availability of a time and place, shooting for early
morning, prior to when the conference starts. I recognized a lot of names
on this thread, but not all, including the original poster, Alexandre. A
face-to-face I think would really help in this case and I'm assuming most
of the Ceilometer team will be at the Summit.

As a team, it would be good to understand and identify the primary
goals, areas of overlap and differences between where Ceilometer is
focused right now and monitoring as a service.

>From an HP perspective, I can share what we've done with Jahmon so far and
our plans. We've given this area and our direction considerable thought.
We see
Ceilometer as synergistic with our direction and have developed
a Ceilometer pipeline publisher to send samples to Jahmon. Jahmon
will be open-sourced and has a significant amount of code and the backing
of 
a strong team right now, but we would like to start working in earnest
with the open-source community.

--Roland


On 5/6/14, 10:25 AM, "Clint Byrum"  wrote:

>Excerpts from Sandy Walsh's message of 2014-05-06 07:02:05 -0700:
>> On 5/6/2014 10:04 AM, Thierry Carrez wrote:
>> > John Dickinson wrote:
>> >> One of the advantages of the program concept within OpenStack is
>>that separate code projects with complementary goals can be managed
>>under the same program without needing to be the same codebase. The most
>>obvious example across every program are the "server" and "client"
>>projects under most programs.
>> >>
>> >> This may be something that can be used here, if it doesn't make
>>sense to extend the ceilometer codebase itself.
>> > +1
>> >
>> > Being under the Telemetry umbrella lets you make the right technical
>> > decision between same or separate codebase, as both would be supported
>> > by the organizational structure.
>> >
>> > It also would likely give you an initial set of contributors
>>interested
>> > in the same end goals. So at this point I'd focus on engaging with the
>> > Telemetry program folks and see if they would be interested in that
>> > capability (inside or outside of the Ceilometer code base).
>> 
>> This is interesting.
>> 
>> I'd be curious to know more what "managed" means in this situation? Is
>> the core project expected to allocate time in the IRC meeting to the
>> concerns of these adjacent projects? What if the core project doesn't
>> agree with the direction or deems there's too much overlap? Does the
>> core team instantly have sway over the adjacent project?
>> 
>
>Yes, the core team instantly has sway. It is not to be taken lightly.
>
>We absorbed Tuskar into the Deployment program, and our PTL, Robert
>Collins, was able to get involved with the design of Tuskar early and
>convince them to stay more aligned with other OpenStack projects. So
>the benefit is now Tuskar can focus on the thing that they _do_ need
>to do that are unique.  Likewise, their core team was given core status
>in the deployment program, and was able to influence the pieces of the
>Deployment program that they needed to work better.
>
>This has created a nice cycle of contribution where many aspects of the
>Deployment program's projects have been improved as a result. Had Tuskar
>decided to just stay out of the Deployment program, they might have
>reimplemented many of the things we had already done, and thus would
>be less adoptable by users and they would receive less contribution as
>a whole.
>


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

[openstack-dev] [marconi] Python client library 0.0.1 released

[Kurt Griffiths]

Hi folks, I’m pleased to announce you can now  pip install python-marconiclient 
 and get support for the entire v1.0 API. Although the package will remain 
classified as “beta” while we polish off any rough edges, please take it for a 
spin and let us know what you think.

Kudos goes to Flavio Percoco for taking the lead on the client work, and to 
everyone who helped him get the project to this point. Thanks!

With this release, the juno-1 milestone is now open. Since we will be tracking 
the server releases going forward, I strongly encourage everyone who submits 
API changes from now on to contribute corresponding patches to the client, to 
help us synchronize functionality across both server and client releases. We 
would also love your help in contributing docs to the client project.

Project Home: https://launchpad.net/python-marconiclient
PyPI Package: 
https://pypi.python.org/pypi/python-marconiclient

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

Re: [openstack-dev] [Programs] Client Tools program discussion

[Dean Troyer]

On Tue, May 6, 2014 at 4:45 PM, Joe Gordon  wrote:

> 1. At first ClientTools consist of just the OpenStackClient
> 2. When the pythonSDK is ready to move off of stackforge, it will live in
> ClientTools
>

Yes to both of these


> 3. Specific python-*clients will be rewritten (from scratch?) to use the
> PythonSDK. But this time they won't have a built in CLI. These libraries
> will live along side the respective servers (so nova's python-novaclient
> will live in Compute)? All while moving OpenStackClient to the new libraries
>

I have no plans for the existing client libs.  If it makes sense to
consolidate them in Client Tools that is fine with me. Historically there
has been pushback on suggestions of that sort so I have not included them
here.

OSC will use the SDK when it becomes viable to do so. No matter where the
existing clients fit organizationally, I see their future use diminishing
over time.

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [solum] Agenda for design workshop at Atlanta

[Roshan Agrawal]

The solum team would be meeting at Atlanta on Wednesday for a design workshop 
session
Wednesday, May 14 1:50pm - 5:20pm: Open Source Comm Project Solum
 
I created an ether pad page for coming up with agenda for the session. Please 
enter in your inputs on the page -
https://etherpad.openstack.org/p/SolumSummitAgenda
 
Thanks & Regards,
Roshan Agrawal
Direct:    512.874.1278
Mobile:  512.354.5253
roshan.agra...@rackspace.com


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

Re: [openstack-dev] [heat] How to cross-reference resources within OS::Heat::ResourceGroup

[Randall Burt]

It would be a bit difficult if not impossible since you either address the 
aggregate values of all attributes in the group or the attribute of one 
specific member of the group. The ResourceGroup doesn't have a mechanism for 
applying sequential values to the members. That might be something you could 
raise a blueprint for.

On May 6, 2014, at 3:07 PM, "Janczuk, Tomasz" 
 wrote:

> Could this be accomplished with 3 resource groups instead of one? The
> first would create the ports, the second floating IPs, and the last the
> VMs? In that case, would there be a way to construct a reference to a
> particular instance of, say, a port, when creating an instance of a
> floating IP?
> 
> On 5/6/14, 12:41 PM, "Randall Burt"  wrote:
> 
>> A resource group's definition contains only one resource and you seem to
>> want groups of multiple resources. You would need to use a nested stack
>> or provider template to do what you're proposing.
>> 
>> On May 6, 2014, at 2:23 PM, "Janczuk, Tomasz" 
>> wrote:
>> 
>>> I am trying to create an OS::Heat::ResourceGroup of VMs and assign each
>>> VM a floating IP. As far as I know this requires cross-referencing the
>>> VM, port, and floating IP resources. How can I do that within a
>>> OS::Heat::ResourceGroup definition?
>>> 
>>> The `port: { get_resource: vm_cluster.vm_port.0 }` below is rejected by
>>> Heat.
>>> 
>>> Any help appreciated.
>>> 
>>> Thanks,
>>> Tomasz
>>> 
>>> vm_cluster:
>>>   type: OS::Heat::ResourceGroup
>>>   properties:
>>> count: { get_param: num_instances }
>>> resource_def:
>>>   vm:
>>> type: OS::Nova::Server
>>> properties:
>>>   key_name: { get_param: key_name }
>>>   flavor: { get_param: flavor }
>>>   image: { get_param: image }
>>>   networks:
>>> - port: { get_resource: vm_cluster.vm_port.0 }
>>>   vm_port:
>>> type: OS::Neutron::Port
>>> properties:
>>>   network_id: { get_param: private_net_id }
>>>   fixed_ips:
>>> - subnet_id: { get_param: private_subnet_id }
>>>   security_groups: [{ get_resource: rabbit_security_group }]
>>>   vm_floating_ip:
>>> type: OS::Neutron::FloatingIP
>>> properties:
>>>   floating_network_id: { get_param: public_net_id }
>>>   port_id: { get_resource: vm_cluster.vm_port.0 }
>>> 
>>> ___
>>> 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] [Programs] Client Tools program discussion

[Joe Gordon]

On Tue, May 6, 2014 at 6:54 AM, Dean Troyer  wrote:

> On Tue, May 6, 2014 at 7:02 AM, Thierry Carrez wrote:
>
>> Would you take over the Python client libraries as well ? On one hand
>> they need /some/ domain expertise, but on the other I see no reason to
>> special-case Python against other SDKs, and that may give the libraries
>> a bit more attention and convergence (they currently are the ugly
>> stepchild in some programs, and vary a lot).
>>
>
> The future of the existing client libs has not been settled, my working
> assumption is that they would remain with their home programs as they are
> now.  From the start OpenStackClient was meant to be a clean-slate for the
> CLI and the Python SDK is taking the same basic approach.
>


Very excited for the OpenStackClient, it is already way nicer then the
existing clients.


Just working this out in my head. So the work flow would be:

1. At first ClientTools consist of just the OpenStackClient
2. When the pythonSDK is ready to move off of stackforge, it will live in
ClientTools
3. Specific python-*clients will be rewritten (from scratch?) to use the
PythonSDK. But this time they won't have a built in CLI. These libraries
will live along side the respective servers (so nova's python-novaclient
will live in Compute)? All while moving OpenStackClient to the new libraries


Is that what you are proposing?



>
> In the case you'd absorb the Python client libraries, it might make
>> sense to ship the keystone middleware in a separate package that would
>> still live in the Identity program.
>
>
> This needs to happen anyway, it's time for my semi-annual request to
> dolphm...
>
> I think we need people caring for the end user and their experience of
>> interacting with an OpenStack-backed cloud. I understand that CLI/SDK
>> specialists and GUI-oriented specialists are different crowds, but they
>> share the same objective and would benefit IMHO from being in the same
>> program. There could be two subteams to care for specialists in both
>> areas (or even 3 if you separate the CLI and SDK folks). Overall from
>> the TC perspective it would make a much stronger proposal if you somehow
>> could present a united (and without overlap) proposal.
>
>
> To be honest, until the most recent ML thread I hadn't thought about the
> UX team or even if they were active.  We have three basic categories of
> projects delivering code: web UI (Horizon),  CLI (OpenStackClient) and SDK
> (at least three active language-based teams).  They all should consume the
> output from a UX R&D effort, I guess I am open on the program structure to
> make that work.  Horizon is already a part of a program, OSC needs to be
> and the SDKs will also need to be in the near future.
>
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> ___
> 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] [sahara] bug triage day after summit

[Michael McCune]

+1

- Original Message -
> Hey sahara folks,
> 
> let's make a Bug Triage Day after the summit.
> 
> I'm proposing the May, 26 for it.
> 
> Any thoughts/objections?
> 
> Thanks.
> 
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Mirantis Inc.
> 
> ___
> 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] [Neutron][LBaaS]User Stories and sruvey

[Jorge Miramontes]

Okay, makes sense to gather all data now and interpret this later. I'm too
jaded for these types of debates right now since the summit is around the
corner.

Cheers,
--Jorge




On 5/6/14 3:32 PM, "Jay Pipes"  wrote:

>On 05/06/2014 04:22 PM, Stephen Balukoff wrote:
>> I think the plan is to release all the raw results of this to the public
>> as well--  meaning that it should be possible to come up with a
>> "representative average" per organization, as well as several other ways
>> to interpret the data. Right now, the emphasis is just to gather the
>> data. We can decide how to interpret it later.
>
>I don't think a representative average for each organization is
>necessarily useful (compared to the average over some larger grouping),
>but sure, the focus should be on data collection now, not interpretation.
>
>> There's a reason this survey is not anonymous. :)
>
>++
>
>-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] [Juno-Summit] availability of the project "project pod" rooms on Monday May 12th?

[Susanne Balle]

Thierry

How do I reserve a pod for a specific time and day. I am getting ready to
setup a meeting.

Susanne


On Tue, May 6, 2014 at 3:53 PM, Thierry Carrez wrote:

> Carl Baldwin wrote:
> > Is there a map, a list, or some other official reference?  I may like
> > to use a pod for a cross-project discussion about DNS between Nova,
> > Neutron, and Designate.  Not a big deal but it might be nice to know
> > more about what we're looking for when we get there.
>
> There will be a designated pod for each of the official programs at:
> https://wiki.openstack.org/wiki/Programs
>
> Some programs share a pod. There will be a map at the center of the
> space, as well as signage up to help find the relevant pod.
>
> For a cross-project discussion you'd have to pick a pod where to have
> it. In your case I'd recommend the Neutron pod since Nova shares its pod
> with Glance and there is no Designate pod.
>
> Cheers,
>
> --
> Thierry Carrez (ttx)
>
> ___
> 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] [Neutron][LBaaS]User Stories and sruvey

[Adam Harwell]

Comments inline (and not in red this time!).

On 5/6/14 3:30 PM, "Jay Pipes"  wrote:

>On 05/06/2014 03:16 PM, Jorge Miramontes wrote:
>> I agree that everyone's thoughts should be in it. I don't see why a
>> representative vote does not allow for that. Sam put a text box on each
>> use case to capture extra thoughts.
>
>Because all of us have different experiences. Not all of us have worked
>for the specific company we work at now for the past 20 years. We all
>have different customer experiences and use cases based on a variety of
>job positions and past employers.
>
>> I would hope that no organization would be so confused as to have widely
>> varying viewpoints on *what their customers want*
>
>You have only one type of customer?

No, but our statistics cover 100% of all Rackspace customers' use cases
for LBaaS (based on current usage and feature requests) -- that's the
whole point of the stats gathering we did. We didn't just pick a couple of
customers and look at their loadbalancers to decide what use cases to
propose, which seems to be what you're implying?

>
>, since that is the
>> supposed purpose of all of this, right? We're supposed to be deciding
>> which use-cases matter *to our customers*,
>
>Yep, and there are many different types of customers even within a
>single company. I'm sure you don't assume that RAX Public Cloud
>customers have the same needs of RAX private cloud or enterprise hosting
>customers. At the same time, is there a single person at RAX that can
>adequately speak for all those segments? As a former Racker, I can
>remember meeting no such person.

We don't assume anything -- our team did extensive stats gathering for
*ALL* types of customers, and that is what our statistics (which are based
on hard data) reflect. So, at this point, I would say that we can in fact
speak definitively on this subject for our organization.

>
>  so there should be no real
>> variance for what I would vote versus what my teammates would vote,
>>since
>> we have the same customersŠ
>
>And there are multiple teams at Rackspace, no?

With regard to LBaaS, it is only our team (CLB) and the team that handles
hardware LBs (F5, etc), and this falls pretty cleanly in the CLB domain.

>
>> Also, if we are using this as a type of voting mechanism then interests
>>of
>> large/vocal organizations drown out smaller organizations. If this is
>> being used as a voting mechanism then how do you suggest we weight votes
>> for smaller companies so that we do not alienate them from further
>> voting/discussions?
>
>Through consensus and discussion, same as any other OpenStack project.
>
>Best,
>-jay
>
>> Cheers,
>> --Jorge
>>
>>
>>
>>
>> On 5/6/14 1:52 PM, "Jay Pipes"  wrote:
>>
>>> On 05/06/2014 02:42 PM, Jorge Miramontes wrote:
 Sam,

 I'm assuming you want one person from each company to answer correct?
 I'm pretty sure people in each organization will vote the sameŠat
least
 I'd hope!
>>>
>>> I'd hope not! :)
>>>
>>> Even within the same organization or company, we all have different
>>> ideas on use cases, the appropriateness of certain things "in the
>>> cloud", and the role of a load balancer service in the general mix of
>>> things.
>>>
>>> I certainly would hope that lots of Mirantis engineers other than
>>>myself
>>> fill out the use case survey and offer their own insights.
>>>
>>> Best,
>>> -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


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

Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)

[Steven Hardy]

On Mon, May 05, 2014 at 07:40:08PM +, Dimitri Mazmanov wrote:
> This is good! Is there a blueprint describing this idea? Or any plans
> describing it in a blueprint?
> Would happily share the work.
> 
> Should we mix it with flavors in horizon though? I¹m thinking of having a
> separate ³Resources² page,
> wherein the user can ³define² resources. I¹m not a UX expert though.
> 
> But let me come back to the project-scoped flavor creation issues.
> Why do you think it¹s such a bad idea to let tenants create flavors for
> their project specific needs?
> 
> I¹ll refer again to the Steve Hardy¹s proposal:
> - Normal user : Can create a private flavor in a tenant where they
>   have the Member role (invisible to any other users)
> - Tenant Admin user : Can create public flavors in the tenants where they
>   have the admin role (visible to all users in the tenant)
> - Domain admin user : Can create public flavors in the domains where they
>   have the admin role (visible to all users in all tenants in that domain)

To clarify, that wasn't a "proposal" as such, it was merely a suggested
specification of a Nova interface that could work, if we want to implement
a Nova flavor resource in Heat which will actually be useful to a
reasonable subset of our users.

Here's the thread reference:

http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.html

I was responding to a question asking if trusts would somehow fix this
problem, to which the answer is no, and describing challenges faced by
anyone trying to implement custom flavor creation through Heat, because
the Nova API creates global objects, not objects scoped to a project.

Essentially I find the discussion of how to do this via Heat kinda
backwards, we should first figure out how to solve this problem with Nova
directly, then exposing whatever Nova interface solves the problem via Heat
becomes trivial.

> > If you actually have 64 flavors, though, and it's overwhelming
> > your users, ...
> 
> The users won¹t see all 64 flavor, only those they have defined and public.

Well, that's the whole problem - private flavors aren't really private, and
if a user defines a flavor, all other users *will* see it (if they have the
admin role in any project)

See my link above, --is-public false doesn't do what you think it does.

Steve

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

Re: [openstack-dev] [sahara] bug triage day after summit

[Alexander Ignatov]

++ Let’s do it on Monday

Regards,
Alexander Ignatov



On 06 May 2014, at 12:13, Sergey Lukjanov  wrote:

> Hey sahara folks,
> 
> let's make a Bug Triage Day after the summit.
> 
> I'm proposing the May, 26 for it.
> 
> Any thoughts/objections?
> 
> Thanks.
> 
> -- 
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Mirantis Inc.
> 
> ___
> 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] [Trove] Proposal to add Craig Vyvial to trove-core

[Nikhil Manchanda]

Thanks everyone for the show of support.
Craig: welcome to trove-core!


On Tue, May 6, 2014 at 1:17 PM, Vipul Sabhaya  wrote:

> +1
>
>
> On Tue, May 6, 2014 at 10:09 AM, McReynolds, Auston 
> wrote:
>
>> +1
>>
>> On 5/6/14, 2:31 AM, "Nikhil Manchanda"  wrote:
>>
>> >
>> >Hello folks:
>> >
>> >I'm proposing to add Craig Vyvial (cp16net) to trove-core.
>> >
>> >Craig has been working with Trove for a while now. He has been a
>> >consistently active reviewer, and has provided insightful comments on
>> >numerous reviews. He has submitted quality code to multiple features in
>> >Trove, and most recently drove the implementation of configuration
>> >groups in Icehouse.
>> >
>> >https://review.openstack.org/#/q/reviewer:%22Craig+Vyvial%22,n,z
>> >https://review.openstack.org/#/q/owner:%22Craig+Vyvial%22,n,z
>> >
>> >Please respond with +1/-1, or any further comments.
>> >
>> >Thanks,
>> >Nikhil
>> >
>> >___
>> >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] [sahara] bug triage day after summit

[Chad Roberts]

May 26 works for me.
+1

- Original Message -
From: "Jay Pipes" 
To: openstack-dev@lists.openstack.org
Sent: Tuesday, May 6, 2014 4:24:22 PM
Subject: Re: [openstack-dev] [sahara] bug triage day after summit

++ You've got my axe.

On 05/06/2014 03:13 PM, Sergey Lukjanov wrote:
> Hey sahara folks,
>
> let's make a Bug Triage Day after the summit.
>
> I'm proposing the May, 26 for it.
>
> Any thoughts/objections?
>
> Thanks.
>

___
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] [Ironic] Node uuid and Nova Hypervisor ID

[François Rossigneux]

Devananda,

I get the Nova Hypervisor ID by typing "nova hypervisor-list".
I am developing a resource reservation service and the reservations are 
attached to a Nova Hypervisor ID.
I would use Ironic to put the nodes on standby mode when there is no 
running instances.

This is why I need to get the Ironic node UUID from a Nova Hypervisor ID...

"http://ironic:6385/v1/nodes?instance_uuid=blablabla"; is not a perfect 
solution : without running instances, you cannot retrieve the node UUID...


Thanks.


Le 06/05/2014 22:05, Devananda van der Veen a écrit :

François,

Can you clarify by way of a CLI example what exactly you mean by "nova
hypervisor id"? I'm not sure if you mean the instance uuid, compute
host id, service id, or something else.

I'll assume you mean the nova instance uuid, in which case, you can
get the Ironic node uuid from "nova show $instance" -- it is in the
hypervisor_hostname field.

-D

On Tue, May 6, 2014 at 2:23 AM, François Rossigneux
 wrote:

Hi all,
I need to retrieve the Ironic node uuid from a Nova Hypervisor ID. How can I
do that?
Thanks.

___
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


--
François Rossigneux
Ingénieur Inria Projet XLcloud
http://perso.ens-lyon.fr/francois.rossigneux


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

Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)

[Jiang, Yunhong]

> -Original Message-
> From: Solly Ross [mailto:sr...@redhat.com]
> Sent: Tuesday, May 06, 2014 10:16 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation
> through Heat (pt.2)
> 
> For your first question, I'll probably create a BP sometime today.
> 
> For your second question, allowing tenants to create flavors
> prevents one of the main parts of the flavor idea from working --
> having flavors that nicely fit together to prevent "wasted" host
> resources.  For instance suppose the normal system flavors used
> memory in powers of 2GB (2, 4, 8, 16, 32).  Now suppose someone
> came in, created a private flavor that used 3GB of RAM.  We now
> have 1GB of RAM that can never be used, unless someone decides
> to come along and create a 1GB flavor (actually, since RAM has
> even more granularity than that, you could have someone specify
> that they wanted 1.34GB of RAM, for instance, and then you have
> all sorts of weird stuff going on).

Hi, Solly, I don't think the 3G is really that important since it has no 
alignment requirement and will not cause fragmentation, at least not that much 
to against the previous suggestion. After all, 3G + 3G + 2G can sit in a 8G 
host quite well, maybe a multiplier of 64M is fair enough and should work in 
large scale system.. Of course, 1.34G is strange for an engineer :)

--jyh

> 
> Best Regards,
> Solly Ross
> 
> - Original Message -
> From: "Dimitri Mazmanov" 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Sent: Monday, May 5, 2014 3:40:08 PM
> Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation
> through Heat (pt.2)
> 
> This is good! Is there a blueprint describing this idea? Or any plans
> describing it in a blueprint?
> Would happily share the work.
> 
> Should we mix it with flavors in horizon though? I¹m thinking of having a
> separate ³Resources² page,
> wherein the user can ³define² resources. I¹m not a UX expert though.
> 
> But let me come back to the project-scoped flavor creation issues.
> Why do you think it¹s such a bad idea to let tenants create flavors for
> their project specific needs?
> 
> I¹ll refer again to the Steve Hardy¹s proposal:
> - Normal user : Can create a private flavor in a tenant where they
>   have the Member role (invisible to any other users)
> - Tenant Admin user : Can create public flavors in the tenants where they
>   have the admin role (visible to all users in the tenant)
> - Domain admin user : Can create public flavors in the domains where they
>   have the admin role (visible to all users in all tenants in that domain)
> 
> 
> > If you actually have 64 flavors, though, and it's overwhelming
> > your users, ...
> 
> The users won¹t see all 64 flavor, only those they have defined and public.
> 
> -
> 
> Dimitri
> 
> On 05/05/14 20:18, "Chris Friesen" 
> wrote:
> 
> >On 05/05/2014 11:40 AM, Solly Ross wrote:
> >> One thing that I was discussing with @jaypipes and @dansmith over
> >> on IRC was the possibility of breaking flavors down into separate
> >> components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor.
> >> This way, you still get the control of the size of your building blocks
> >> (e.g. you could restrict RAM to only 2GB, 4GB, or 16GB), but you avoid
> >> exponential flavor explosion by separating out the axes.
> >
> >I like this idea because it allows for greater flexibility, but I think
> >we'd need to think carefully about how to expose it via horizon--maybe
> >separate tabs within the overall "flavors" page?
> >
> >As a simplifying view you could keep the existing flavors which group
> >all of them, while still allowing instances to specify each one
> >separately if desired.
> >
> >Chris
> >
> >___
> >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] [Neutron][LBaaS]User Stories and sruvey

[Jay Pipes]

On 05/06/2014 04:22 PM, Stephen Balukoff wrote:

I think the plan is to release all the raw results of this to the public
as well--  meaning that it should be possible to come up with a
"representative average" per organization, as well as several other ways
to interpret the data. Right now, the emphasis is just to gather the
data. We can decide how to interpret it later.


I don't think a representative average for each organization is 
necessarily useful (compared to the average over some larger grouping), 
but sure, the focus should be on data collection now, not interpretation.



There's a reason this survey is not anonymous. :)


++

-jay

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

Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

[Jay Pipes]

On 05/06/2014 03:16 PM, Jorge Miramontes wrote:

I agree that everyone's thoughts should be in it. I don't see why a
representative vote does not allow for that. Sam put a text box on each
use case to capture extra thoughts.


Because all of us have different experiences. Not all of us have worked 
for the specific company we work at now for the past 20 years. We all 
have different customer experiences and use cases based on a variety of 
job positions and past employers.



I would hope that no organization would be so confused as to have widely
varying viewpoints on *what their customers want*


You have only one type of customer?

, since that is the

supposed purpose of all of this, right? We're supposed to be deciding
which use-cases matter *to our customers*,


Yep, and there are many different types of customers even within a 
single company. I'm sure you don't assume that RAX Public Cloud 
customers have the same needs of RAX private cloud or enterprise hosting 
customers. At the same time, is there a single person at RAX that can 
adequately speak for all those segments? As a former Racker, I can 
remember meeting no such person.


 so there should be no real

variance for what I would vote versus what my teammates would vote, since
we have the same customersŠ


And there are multiple teams at Rackspace, no?


Also, if we are using this as a type of voting mechanism then interests of
large/vocal organizations drown out smaller organizations. If this is
being used as a voting mechanism then how do you suggest we weight votes
for smaller companies so that we do not alienate them from further
voting/discussions?


Through consensus and discussion, same as any other OpenStack project.

Best,
-jay


Cheers,
--Jorge




On 5/6/14 1:52 PM, "Jay Pipes"  wrote:


On 05/06/2014 02:42 PM, Jorge Miramontes wrote:

Sam,

I'm assuming you want one person from each company to answer correct?
I'm pretty sure people in each organization will vote the sameŠat least
I'd hope!


I'd hope not! :)

Even within the same organization or company, we all have different
ideas on use cases, the appropriateness of certain things "in the
cloud", and the role of a load balancer service in the general mix of
things.

I certainly would hope that lots of Mirantis engineers other than myself
fill out the use case survey and offer their own insights.

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

[openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday, 05/08 14-00 UTC

[Eugene Nikanorov]

Hi folks,

This will be the last meeting before the summit, so I suggest we will focus
on the agenda for two
design track slots we have.

Per my experience design tracks are not very good for in-depth discussion,
so it only make sense to present a road map and some other items that might
need core team attention like interaction with Barbican and such.

Another item for the meeting will be comparison of API proposals which as
an action item from the last meeting.

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

Re: [openstack-dev] [sahara] bug triage day after summit

[Jay Pipes]

++ You've got my axe.

On 05/06/2014 03:13 PM, Sergey Lukjanov wrote:

Hey sahara folks,

let's make a Bug Triage Day after the summit.

I'm proposing the May, 26 for it.

Any thoughts/objections?

Thanks.



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

Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

[Stephen Balukoff]

I think the plan is to release all the raw results of this to the public as
well--  meaning that it should be possible to come up with a
"representative average" per organization, as well as several other ways to
interpret the data. Right now, the emphasis is just to gather the data. We
can decide how to interpret it later.

There's a reason this survey is not anonymous. :)

Thanks,
Stephen



On Tue, May 6, 2014 at 12:24 PM, Adam Harwell wrote:

> I'd like to add that size of the organization (or really, size of the
> development team) that is voting in this quiz does not directly correlate
> to size of customer base. If there were any weighting happening, I'd hope
> these answers would be weighted by size of user base, since really it is
> the users' interests we are all trying to represent, not our own!
>
> --Adam
>
> On 5/6/14 2:16 PM, "Jorge Miramontes" 
> wrote:
>
> >I agree that everyone's thoughts should be in it. I don't see why a
> >representative vote does not allow for that. Sam put a text box on each
> >use case to capture extra thoughts.
> >
> >I would hope that no organization would be so confused as to have widely
> >varying viewpoints on *what their customers want*, since that is the
> >supposed purpose of all of this, right? We're supposed to be deciding
> >which use-cases matter *to our customers*, so there should be no real
> >variance for what I would vote versus what my teammates would vote, since
> >we have the same customersŠ
> >
> >
> >Also, if we are using this as a type of voting mechanism then interests of
> >large/vocal organizations drown out smaller organizations. If this is
> >being used as a voting mechanism then how do you suggest we weight votes
> >for smaller companies so that we do not alienate them from further
> >voting/discussions?
> >
> >Cheers,
> >--Jorge
> >
> >
> >
> >
> >On 5/6/14 1:52 PM, "Jay Pipes"  wrote:
> >
> >>On 05/06/2014 02:42 PM, Jorge Miramontes wrote:
> >>> Sam,
> >>>
> >>> I'm assuming you want one person from each company to answer correct?
> >>> I'm pretty sure people in each organization will vote the sameŠat least
> >>> I'd hope!
> >>
> >>I'd hope not! :)
> >>
> >>Even within the same organization or company, we all have different
> >>ideas on use cases, the appropriateness of certain things "in the
> >>cloud", and the role of a load balancer service in the general mix of
> >>things.
> >>
> >>I certainly would hope that lots of Mirantis engineers other than myself
> >>fill out the use case survey and offer their own insights.
> >>
> >>Best,
> >>-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
>



-- 
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] [Trove] Proposal to add Craig Vyvial to trove-core

[Vipul Sabhaya]

+1


On Tue, May 6, 2014 at 10:09 AM, McReynolds, Auston wrote:

> +1
>
> On 5/6/14, 2:31 AM, "Nikhil Manchanda"  wrote:
>
> >
> >Hello folks:
> >
> >I'm proposing to add Craig Vyvial (cp16net) to trove-core.
> >
> >Craig has been working with Trove for a while now. He has been a
> >consistently active reviewer, and has provided insightful comments on
> >numerous reviews. He has submitted quality code to multiple features in
> >Trove, and most recently drove the implementation of configuration
> >groups in Icehouse.
> >
> >https://review.openstack.org/#/q/reviewer:%22Craig+Vyvial%22,n,z
> >https://review.openstack.org/#/q/owner:%22Craig+Vyvial%22,n,z
> >
> >Please respond with +1/-1, or any further comments.
> >
> >Thanks,
> >Nikhil
> >
> >___
> >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] How to cross-reference resources within OS::Heat::ResourceGroup

[Janczuk, Tomasz]

Could this be accomplished with 3 resource groups instead of one? The
first would create the ports, the second floating IPs, and the last the
VMs? In that case, would there be a way to construct a reference to a
particular instance of, say, a port, when creating an instance of a
floating IP?

On 5/6/14, 12:41 PM, "Randall Burt"  wrote:

>A resource group's definition contains only one resource and you seem to
>want groups of multiple resources. You would need to use a nested stack
>or provider template to do what you're proposing.
>
>On May 6, 2014, at 2:23 PM, "Janczuk, Tomasz" 
> wrote:
>
>> I am trying to create an OS::Heat::ResourceGroup of VMs and assign each
>>VM a floating IP. As far as I know this requires cross-referencing the
>>VM, port, and floating IP resources. How can I do that within a
>>OS::Heat::ResourceGroup definition?
>> 
>> The `port: { get_resource: vm_cluster.vm_port.0 }` below is rejected by
>>Heat.
>> 
>> Any help appreciated.
>> 
>> Thanks,
>> Tomasz
>> 
>>  vm_cluster:
>>type: OS::Heat::ResourceGroup
>>properties:
>>  count: { get_param: num_instances }
>>  resource_def:
>>vm:
>>  type: OS::Nova::Server
>>  properties:
>>key_name: { get_param: key_name }
>>flavor: { get_param: flavor }
>>image: { get_param: image }
>>networks:
>>  - port: { get_resource: vm_cluster.vm_port.0 }
>>vm_port:
>>  type: OS::Neutron::Port
>>  properties:
>>network_id: { get_param: private_net_id }
>>fixed_ips:
>>  - subnet_id: { get_param: private_subnet_id }
>>security_groups: [{ get_resource: rabbit_security_group }]
>>vm_floating_ip:
>>  type: OS::Neutron::FloatingIP
>>  properties:
>>floating_network_id: { get_param: public_net_id }
>>port_id: { get_resource: vm_cluster.vm_port.0 }
>> 
>> ___
>> 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] current available resources extension

[Wei Du]

Hi OpenStack Devs,

This is Wei Du from Yahoo! OpenStack engineering team. Currently, we have some 
data about the actual resource usage seen by ‘proc’ on each compute node. 
However, the actual available resources cannot be derived from the actual 
usage. For example, we have a 10G RAM on a hypervisor, the current free RAM 
recorded in nova.compute_nodes is -3G. By running ‘proc’ on the compute node, 
we see the actual RAM usage is only 3G. With these data point, we cannot say 
the available RAM is 7G. Assume the ram_allocation_ratio is 1.5. while the 
correct state seen by scheduler is 2G RAM is available.

Physical RAM: 10G
Free RAM: -3G
Actual used RAM: 3G

ram_allocation_ratio: 1.5

Available RAM seen by scheduler: 10*1.5-(10-(-3)) = 2

We are planning to implement a nova api extension, which will check 
nova.compute_nodes for the current resource allocation state, and return the 
current available resources seen by nova-scheduler. We would like to get your 
experience/suggestions/thoughts if you happen to encounter similar situation.

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

[openstack-dev] [solum] Program and Project vision Wiki

[Roshan Agrawal]

Here is the wiki for the Program and Project mission statement. 
https://wiki.openstack.org/wiki/Solum/MissionStatement, please edit in place as 
needed on the wiki

Below is the ether pad for reference:
https://etherpad.openstack.org/p/solum-mission

Thanks & Regards,
Roshan Agrawal
Direct:512.874.1278
Mobile:  512.354.5253
roshan.agra...@rackspace.com

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

Re: [openstack-dev] [Ironic] Node uuid and Nova Hypervisor ID

[Devananda van der Veen]

François,

Can you clarify by way of a CLI example what exactly you mean by "nova
hypervisor id"? I'm not sure if you mean the instance uuid, compute
host id, service id, or something else.

I'll assume you mean the nova instance uuid, in which case, you can
get the Ironic node uuid from "nova show $instance" -- it is in the
hypervisor_hostname field.

-D

On Tue, May 6, 2014 at 2:23 AM, François Rossigneux
 wrote:
> Hi all,
> I need to retrieve the Ironic node uuid from a Nova Hypervisor ID. How can I
> do that?
> Thanks.
>
> ___
> 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] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Kevin Benton]

Yes, I am interested as well.


On Tue, May 6, 2014 at 9:19 AM, Collins, Sean <
sean_colli...@cable.comcast.com> wrote:

> For those attending, to discuss the QoS API current status?
>
> --
> Sean M. Collins
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [Ironic] Node uuid and Nova Hypervisor ID

[Devananda van der Veen]

François,

Can you clarify by way of a CLI example what exactly you mean by "nova
hypervisor id"? I'm not sure if you mean the instance uuid, compute
host id, service id, or something else.

I'll assume you mean the nova instance uuid, in which case, you can
get the Ironic node uuid from "nova show $instance" -- it is in the
hypervisor_hostname field.

-D

On Tue, May 6, 2014 at 2:23 AM, François Rossigneux
 wrote:
> Hi all,
> I need to retrieve the Ironic node uuid from a Nova Hypervisor ID. How can I
> do that?
> Thanks.
>
> ___
> 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] [Juno-Summit] availability of the project "project pod" rooms on Monday May 12th?

[Thierry Carrez]

Carl Baldwin wrote:
> Is there a map, a list, or some other official reference?  I may like
> to use a pod for a cross-project discussion about DNS between Nova,
> Neutron, and Designate.  Not a big deal but it might be nice to know
> more about what we're looking for when we get there.

There will be a designated pod for each of the official programs at:
https://wiki.openstack.org/wiki/Programs

Some programs share a pod. There will be a map at the center of the
space, as well as signage up to help find the relevant pod.

For a cross-project discussion you'd have to pick a pod where to have
it. In your case I'd recommend the Neutron pod since Nova shares its pod
with Glance and there is no Designate pod.

Cheers,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Fuel][RabbitMQ] nova-compute stuck for a while (AMQP)

[Roman Sokolkov]

Hello, fuelers.

I'm using Fuel 4.1A + Havana in HA mode.

I permanently observe (on other deployments also) issue with stuck
"nova-compute" service. But i think problem is more fundamental and relates
to HA RabbitMQ and OpenStack AMQP driver implementation.

Symptoms:

   - Random nova-compute from time to time marked as "XXX" for a while.
   - I see that service itself works properly. In logs i see that it sends
   status updates to conductor. But actually nothing is sent.
   - "netstat" shows that all connections to/from rabbit "ESTABLISHED"
   - rabbitmqctl shows that "compute.node-x" queue synced to all slaves.
   - nothing has been broken before, i mean rabbitmq cluster, etc.

Axe style solution:

   - /etc/init.d/openstack-nova-compute restart

So here i've found a lot of interesting stuff (and solutions):

https://bugs.launchpad.net/oslo.messaging/+bug/856764


My questions are:

   - Are there any thoughts particular for Fuel to solve/workaround this
   issue?
   - Any fast solution for this in 4.1? Like adjust TCP keep-alive
timeouts?


-- 
Roman Sokolkov,
Deployment Engineer,
Mirantis, Inc.
Skype rsokolkov,
rsokol...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] How to cross-reference resources within OS::Heat::ResourceGroup

[Randall Burt]

A resource group's definition contains only one resource and you seem to want 
groups of multiple resources. You would need to use a nested stack or provider 
template to do what you're proposing.

On May 6, 2014, at 2:23 PM, "Janczuk, Tomasz" 
 wrote:

> I am trying to create an OS::Heat::ResourceGroup of VMs and assign each VM a 
> floating IP. As far as I know this requires cross-referencing the VM, port, 
> and floating IP resources. How can I do that within a OS::Heat::ResourceGroup 
> definition?
> 
> The `port: { get_resource: vm_cluster.vm_port.0 }` below is rejected by Heat.
> 
> Any help appreciated.
> 
> Thanks,
> Tomasz
> 
>  vm_cluster:
>type: OS::Heat::ResourceGroup
>properties:
>  count: { get_param: num_instances }
>  resource_def:
>vm:
>  type: OS::Nova::Server
>  properties:
>key_name: { get_param: key_name }
>flavor: { get_param: flavor }
>image: { get_param: image }
>networks:
>  - port: { get_resource: vm_cluster.vm_port.0 }
>vm_port:
>  type: OS::Neutron::Port
>  properties:
>network_id: { get_param: private_net_id }
>fixed_ips:
>  - subnet_id: { get_param: private_subnet_id }
>security_groups: [{ get_resource: rabbit_security_group }]
>vm_floating_ip:
>  type: OS::Neutron::FloatingIP
>  properties:
>floating_network_id: { get_param: public_net_id }
>port_id: { get_resource: vm_cluster.vm_port.0 }
> 
> ___
> 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] Monitoring as a Service

[Sandy Walsh]

On 5/6/2014 1:48 PM, Thierry Carrez wrote:
> Sandy Walsh wrote:
>> I'd be curious to know more what "managed" means in this situation? Is
>> the core project expected to allocate time in the IRC meeting to the
>> concerns of these adjacent projects? What if the core project doesn't
>> agree with the direction or deems there's too much overlap? Does the
>> core team instantly have sway over the adjacent project?
> It has to be basically the same team of people working on the two
> projects. The goals and the direction of the project are shared. There
> is no way it can work if you consider some "core" and some "adjacent",
> that would quickly create a us vs. them mentality and not work out that
> well in reviews.
>
> Of course, there can be contributors that are not interested in one
> project or another. But if you end up with completely-separated
> subteams, then there is little value in living under the same umbrella
> and sharing a core team.

Ok, that's what I thought. Thanks for the clarification.

-S



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

[openstack-dev] [heat] How to cross-reference resources within OS::Heat::ResourceGroup

[Janczuk, Tomasz]

I am trying to create an OS::Heat::ResourceGroup of VMs and assign each VM a 
floating IP. As far as I know this requires cross-referencing the VM, port, and 
floating IP resources. How can I do that within a OS::Heat::ResourceGroup 
definition?

The `port: { get_resource: vm_cluster.vm_port.0 }` below is rejected by Heat.

Any help appreciated.

Thanks,
Tomasz

  vm_cluster:
type: OS::Heat::ResourceGroup
properties:
  count: { get_param: num_instances }
  resource_def:
vm:
  type: OS::Nova::Server
  properties:
key_name: { get_param: key_name }
flavor: { get_param: flavor }
image: { get_param: image }
networks:
  - port: { get_resource: vm_cluster.vm_port.0 }
vm_port:
  type: OS::Neutron::Port
  properties:
network_id: { get_param: private_net_id }
fixed_ips:
  - subnet_id: { get_param: private_subnet_id }
security_groups: [{ get_resource: rabbit_security_group }]
vm_floating_ip:
  type: OS::Neutron::FloatingIP
  properties:
floating_network_id: { get_param: public_net_id }
port_id: { get_resource: vm_cluster.vm_port.0 }

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

Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

[Adam Harwell]

I'd like to add that size of the organization (or really, size of the
development team) that is voting in this quiz does not directly correlate
to size of customer base. If there were any weighting happening, I'd hope
these answers would be weighted by size of user base, since really it is
the users' interests we are all trying to represent, not our own!

--Adam

On 5/6/14 2:16 PM, "Jorge Miramontes" 
wrote:

>I agree that everyone's thoughts should be in it. I don't see why a
>representative vote does not allow for that. Sam put a text box on each
>use case to capture extra thoughts.
>
>I would hope that no organization would be so confused as to have widely
>varying viewpoints on *what their customers want*, since that is the
>supposed purpose of all of this, right? We're supposed to be deciding
>which use-cases matter *to our customers*, so there should be no real
>variance for what I would vote versus what my teammates would vote, since
>we have the same customersŠ
>
>
>Also, if we are using this as a type of voting mechanism then interests of
>large/vocal organizations drown out smaller organizations. If this is
>being used as a voting mechanism then how do you suggest we weight votes
>for smaller companies so that we do not alienate them from further
>voting/discussions?
>
>Cheers,
>--Jorge
>
>
>
>
>On 5/6/14 1:52 PM, "Jay Pipes"  wrote:
>
>>On 05/06/2014 02:42 PM, Jorge Miramontes wrote:
>>> Sam,
>>>
>>> I'm assuming you want one person from each company to answer correct?
>>> I'm pretty sure people in each organization will vote the sameŠat least
>>> I'd hope!
>>
>>I'd hope not! :)
>>
>>Even within the same organization or company, we all have different
>>ideas on use cases, the appropriateness of certain things "in the
>>cloud", and the role of a load balancer service in the general mix of
>>things.
>>
>>I certainly would hope that lots of Mirantis engineers other than myself
>>fill out the use case survey and offer their own insights.
>>
>>Best,
>>-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] [Neutron][LBaaS]User Stories and sruvey

[Jorge Miramontes]

I agree that everyone's thoughts should be in it. I don't see why a
representative vote does not allow for that. Sam put a text box on each
use case to capture extra thoughts.

I would hope that no organization would be so confused as to have widely
varying viewpoints on *what their customers want*, since that is the
supposed purpose of all of this, right? We're supposed to be deciding
which use-cases matter *to our customers*, so there should be no real
variance for what I would vote versus what my teammates would vote, since
we have the same customersŠ


Also, if we are using this as a type of voting mechanism then interests of
large/vocal organizations drown out smaller organizations. If this is
being used as a voting mechanism then how do you suggest we weight votes
for smaller companies so that we do not alienate them from further
voting/discussions?

Cheers,
--Jorge




On 5/6/14 1:52 PM, "Jay Pipes"  wrote:

>On 05/06/2014 02:42 PM, Jorge Miramontes wrote:
>> Sam,
>>
>> I'm assuming you want one person from each company to answer correct?
>> I'm pretty sure people in each organization will vote the sameŠat least
>> I'd hope!
>
>I'd hope not! :)
>
>Even within the same organization or company, we all have different
>ideas on use cases, the appropriateness of certain things "in the
>cloud", and the role of a load balancer service in the general mix of
>things.
>
>I certainly would hope that lots of Mirantis engineers other than myself
>fill out the use case survey and offer their own insights.
>
>Best,
>-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] [sahara] bug triage day after summit

[Sergey Lukjanov]

Hey sahara folks,

let's make a Bug Triage Day after the summit.

I'm proposing the May, 26 for it.

Any thoughts/objections?

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.

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

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Mohammad Banikazemi]

+1.

Please announce a date/time here so we can perhaps avoid any conflicts with
others who plan to use the networking pod.

Best,

Mohammad



From:   Stephen Wong 
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date:   05/06/2014 12:39 PM
Subject:Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the
Networking pod at the design summit?



Hi Sean,

    Yes. Please count me in (we need to integrate QoS parameters as
possible actions for group-policy).

Thanks,
- Stephen


On Tue, May 6, 2014 at 9:19 AM, Collins, Sean <
sean_colli...@cable.comcast.com> wrote:
  For those attending, to discuss the QoS API current status?

  --
  Sean M. Collins
  ___
  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] about pci device filter

[Jiang, Yunhong]

Hi, Ricky, can you please provide any specific requirement on your mind?

--jyh

> -Original Message-
> From: Bohai (ricky) [mailto:bo...@huawei.com]
> Sent: Monday, May 05, 2014 11:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] about pci device filter
> 
> Hi jiang,
> 
> Maybe what I said in last mail has mistaken you.
> 
> It's not to provide a instance scheduler filter such as
> "PciPassthroughFilter" to filter which host
> to boot the instance.
> 
> I hope to add our special filter like "nova/pci/PciHostDevicesWhiteList.py".
> So we hope to add a mechanism to specify which filter to use for getting
> the
> pci devices from host.
> 
> Best regards to you.
> Ricky
> 
> > -Original Message-
> > From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com]
> > Sent: Tuesday, May 06, 2014 1:54 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [nova] about pci device filter
> >
> > Hi, Bohai, are you talking about the scheduler filter for PCI, right?
> >
> > I think the scheduler filters can be changed by nova options already, so I
> don't
> > think we need another mechanism and just create another filter to
> replace the
> > default pci filter?
> >
> > --jyh
> >
> > > -Original Message-
> > > From: Bohai (ricky) [mailto:bo...@huawei.com]
> > > Sent: Monday, May 05, 2014 1:32 AM
> > > To: OpenStack-dev@lists.openstack.org
> > > Subject: [openstack-dev] [nova] about pci device filter
> > >
> > > Hi, stackers:
> > >
> > > Now there is an default while list filter for PCI device.
> > > But maybe it's not enough in some scenario.
> > >
> > > Maybe it's better if we provide a mechanism to specify a customize
> filter.
> > >
> > > For example:
> > > So user can make a special filter , then specify which filter to use
> > > in configure files.
> > >
> > > Any advices?
> > >
> > > Best regards to you.
> > > Ricky
> > >
> > >
> > > ___
> > > 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] [Neutron][LBaaS]User Stories and sruvey

[Jay Pipes]

On 05/06/2014 02:42 PM, Jorge Miramontes wrote:

Sam,

I'm assuming you want one person from each company to answer correct?
I'm pretty sure people in each organization will vote the same…at least
I'd hope!


I'd hope not! :)

Even within the same organization or company, we all have different 
ideas on use cases, the appropriateness of certain things "in the 
cloud", and the role of a load balancer service in the general mix of 
things.


I certainly would hope that lots of Mirantis engineers other than myself 
fill out the use case survey and offer their own insights.


Best,
-jay

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

Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

[Jorge Miramontes]

Sam,

I'm assuming you want one person from each company to answer correct? I'm 
pretty sure people in each organization will vote the same…at least I'd hope!

Cheers,
--Jorge

From: Samuel Bercovici mailto:samu...@radware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, May 6, 2014 2:56 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi Everyone,

The survey is now live via: http://eSurv.org?u=lbaas_project_user
The password is: lbaas

The survey includes all the tenant facing use cases from 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing
Please try and fill the survey this week so we can have enough information to 
base decisions next week.

Regards,
-Sam.



From: Samuel Bercovici
Sent: Monday, May 05, 2014 4:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi,

I will not freeze the document to allow people to work on requirements which 
are not tenant facing (ex: operator, etc.)
I think that we have enough use cases for tenant facing capabilities to reflect 
most common use cases.
I am in the process of creation a survey in surveymonkey for tenant facing use 
cases and hope to send it to ML ASAP.

Regards,
-Sam.


From: Samuel Bercovici
Sent: Thursday, May 01, 2014 8:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Samuel Bercovici
Subject: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

Hi Everyone!

To assist in evaluating the use cases that matter and since we now have ~45 use 
cases, I would like to propose to conduct a survey using something like 
surveymonkey.
The idea is to have a non-anonymous survey listing the use cases and ask you 
identify and vote.
Then we will publish the results and can prioritize based on this.

To do so in a timely manner, I would like to freeze the document for editing 
and allow only comments by Monday May 5th 08:00AMUTC and publish the survey 
link to ML ASAP after that.

Please let me know if this is acceptable.

Regards,
-Sam.



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

Re: [openstack-dev] [oslo] Proposal: add local hacking for oslo-incubator

[Joe Gordon]

On Tue, May 6, 2014 at 6:03 AM, Doug Hellmann
wrote:

> On Mon, May 5, 2014 at 9:06 PM, David Stanek  wrote:
> >
> > On Mon, May 5, 2014 at 5:28 PM, Doug Hellmann <
> doug.hellm...@dreamhost.com>
> > wrote:
> >>
> >>
> >> > The assert ones do seem to fit the best practices as I understand
> them,
> >> > but
> >> > I suspect there's going to be quite a bit of work to get projects
> >> > compliant.
> >>
> >> I've seen some work being done on that already, but I don't know how
> >> strongly we care about those specific rules as an overall project.
> >>
> >
> > I created the Keystone blueprint[1] to automate the things we already
> check
> > for in reviews. My motivation was to make it faster for contributors to
> > contribute because they would get feedback before getting a bunch of -1s
> in
> > Gerrit. I also wanted to free up core dev resources so that we can focus
> on
> > more important parts of reviews.
>
> Sure, that makes sense to do in keystone.
>


While local checks are great, when adding them projects should always think
if it makes sense to push them back to hacking itself. Otherwise we end up
with 10 different versions of the same checks.



>
> >
> > I'd be happy to start putting some of these in hacking, but I don't know
> > which rules would be acceptable to all projects. Maybe there is a way to
> > make optional checks that can be enabled in the tox.ini
>

All rules are optional in hacking, but all are enabled by default. If a
project doesn't want to use one they can just disable it.


>
> This is the part I wasn't sure about. Some of the rules look pretty
> useful (e.g., no mutable arguments). Others are more stylistic choices
> (e.g., which type of quotes to use).
>
> Joe Gordon drives the hacking project, and he might be able to give
> more detail about the process for adding new rules there.
>
> Doug
>
> >
> > 1.
> >
> https://blueprints.launchpad.net/keystone/+spec/more-code-style-automation
>


Taking the list from your blueprint, with responses after each.


   -  block comments should have a space after the # (this is already
   enforced for inline comments)
   - pep8 1.5.x has this check already, it will come out in hacking 0.9
  (which is currently blocked on reviews)
   -  mutables should not be used as default args
   - sounds like a good thing to add to hacking. Although a clear why this
  is good is required
   -  % should not be used in log statements
   - Belongs in Hacking, although we have to make sure 'LOG' is a logger
   -  assertNone should be used when using None with assertEqual
   - Why? what is the value here?
   -  spelling check for comments and docstrings
   - I have thought about adding this a few times, but I am -1 on it. The
  only way this can work is as a blacklist of words, since
developers love to
  make up there own words.
  - Having spelling feedback in a non-voting way would be very useful
  though
   -  warn if children that change method signature of their parent
   - Hacking doesn't really do warnings
   -  methods that just pass are useless and should be deleted
   - How do these even get in?
   -  warn on try-except that just passes
   - Hacking doesn't do warnings.
   -  enforce import ordering and spacing
   - So I am really sad to see this here. Hacking 0.9 supports this (once
  again blocked on reviews -- not enough reviewers)
   -  _() should not be used in debug log statements
  - Hacking, once again we need to be rigorous in this check when
  adding to hacking.

I'm sure that as I'm fixing the code to conform to the new checks, I'll
identify additional checks to implement.

(stevemar) if I may add some more:

   - ensure no vim headers
   - I don't think this one belongs in hacking, as once a project removes
  all vim headers I don't think they will be re-added. So I see value of
  having this short term in each project. But not something we
want to check
  for indefinitely
   - assertEqual(len(some_list), 0) should be assertEqual(some_list, [])
   - Why is this better?
   - methods / functions that are unused
   - This isn't really something hacking can do.
   - class properties that are unused
   - Once again this isn't something hacking can really do, or really any
  static analysis in python. pyflakes tries to do some of this.
   - ensure incoming method args are actually used
  - belongs in Pyflakes
   - doc strings - ensure all method args are mentioned (if any are
   mentioned)
   - I have to double check, but I think there is a docstring module for
  flake8 that can do things like this
   - use ' over "
   - Why? And is this a black and white thing that can be enforced.
   - ensure we don't go assigning copyrights to OpenStack Foundation
   - We cannot gate on this, otherwise foundation employees cannot commit
  code.



>
> >
> > --
> > David
> > blog: http://www.traceback.org
> > twitter: http://twitter.com/dstanek
> > www: http://dstanek.com
> >
> > 

Re: [openstack-dev] [oslo] Proposal: add local hacking for oslo-incubator

[Joe Gordon]

On Mon, May 5, 2014 at 10:56 AM, Ben Nemec  wrote:

> On 05/05/2014 10:02 AM, ChangBo Guo wrote:
>
>> Hi Stackers,
>>
>> I find some common code style would be avoided while I'm reviewing code
>> ,so think these check would
>> be nice to move into local hacking. The local hacking can ease reviewer
>> burden.
>>
>> The idea from keystone blueprint [1].
>> Hacking is a great start at automating checks for common style issues.
>> There are still lots of things that it is not checking for that it
>> probably should. The local hacking ease reviewer burden . This is the
>> list of from [1][2] that would be nice to move into an automated check:
>>
>> - use import style 'from openstack.common.* import' not use 'import
>> openstack.common.*'
>>
>
> This is the only one that I think belongs in Oslo.  The others are all
> generally applicable, but the other projects aren't going to want to
> enforce the import style since it's only to make Oslo syncs work right.
>
>
I agree this belongs in oslo-incubator only as well. But I am still
confused as to why this is needed. It sounds like this is a workaround for
a bug in the sync script.


>
>  - assertIsNone should be used when using None with assertEqual
>> - _() should not be used in debug log statements
>> -do not use 'assertTrue(isinstance(a, b)) sentence'
>> -do not use 'assertEqual(type(A), B) sentence'
>>
>
> The _() one in particular I think we'll want as we make the logging
> changes.  Some additional checks to make sure the the correct _ function is
> used with the correct logging function would be good too (for example,
> LOG.warning(_LE('foo')) should fail pep8).
>
> But again, that belongs in hacking proper, not an Oslo module.
>


Yup, this belongs in hacking although this gets a little tricky to do
right, as we don't want false positives
http://git.openstack.org/cgit/openstack-dev/hacking/tree/README.rst#n42

We have to make sure that '_' is what we think it is and that 'LOG' is the
logger, just checking for 'LOG'  isn't very robust.

Patches welcome!  http://git.openstack.org/cgit/openstack-dev/hacking


>
> The assert ones do seem to fit the best practices as I understand them,
> but I suspect there's going to be quite a bit of work to get projects
> compliant.
>

Although some projects already have the assert ones, I don't see a lot of
value in them.


>
>
>> [1]
>> https://blueprints.launchpad.net/keystone/+spec/more-code-
>> style-automation
>> [2] https://github.com/openstack/nova/blob/master/nova/hacking/checks.py
>>
>> I just registered a blueprint for this in [3] and submit first patch in
>> [4].
>>
>> [3] https://blueprints.launchpad.net/oslo/+spec/oslo-local-hacking
>>
>> [4] https://review.openstack.org/#/c/87832/
>> 
>>
>>
>> Should we add local hacking for oslo-incubator ?  If yes, what's the
>> other check will be added ?
>> Your comment is appreciated :-)
>>
>> --
>> ChangBo Guo(gcb)
>>
>>
>> ___
>> 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] [ML2] L2 population mechanism driver

[Sławek Kapłoński]

Hello,

Thanks for explanation. Now it is clear for me :) I made my own driver because 
I made config on hosts in "special way" but I can't describe details :/

Best regards
Slawek Kaplonski
sla...@kaplonski.pl

Dnia wtorek, 6 maja 2014 10:35:05 Mathieu Rohon pisze:
> Hi slawek,
> 
> As soon as you declare "l2population" in the  MD section of the config
> file, it will be loaded by ML2 plugin. l2population MD will listen to
> ML2 DB events and send RPC messages to ovs agent when needed.
> l2population MD will not bind the port, ovs MD will.
> By the way, you need to ad add the flag l2population in config file of
> the agent.
> 
> just to be curious, what your MD which inherit from l2_pop MD is made for?
> 
> regards
> 
> Mathieu
> 
> On Mon, May 5, 2014 at 11:06 PM, Sławek Kapłoński  
wrote:
> > Hello,
> > 
> > Thanks for answear. Now I made my own mech_driver which inherits from
> > l2_pop driver and it is working ok. But If I will set it as:
> > "mechanism_drivers=openvswitch,l2population" than ports will be binded
> > with
> > ovs driver so population mechanism will be working in such network?
> > 
> > Best regards
> > Slawek Kaplonski
> > sla...@kaplonski.pl
> > 
> > Dnia poniedziałek, 5 maja 2014 00:29:56 Narasimhan, Vivekanandan pisze:
> >> Hi Slawek,
> >> 
> >> I think L2 pop driver needs to be used in conjunction with other
> >> mechanism
> >> drivers.
> >> 
> >> It only deals with pro-actively informing agents on which MAC Addresses
> >> became available/unavailable on cloud nodes and is not meant for
> >> binding/unbinding ports on segments.
> >> 
> >> If you configure mechanism_drivers=openvswitch,l2population in your
> >> ml2_conf.ini and restart your neutron-server, you'll notice that
> >> bind_port
> >> is handled by OVS mechanism driver (via AgentMechanismDriverBase inside
> >> ml2/drivers/mech_agent.py).
> >> 
> >> --
> >> Thanks,
> >> 
> >> Vivek
> >> 
> >> 
> >> -Original Message-
> >> From: Sławek Kapłoński [mailto:sla...@kaplonski.pl]
> >> Sent: Sunday, May 04, 2014 12:32 PM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: [openstack-dev] [ML2] L2 population mechanism driver
> >> 
> >> Hello,
> >> 
> >> Last time I want to try using L2pop mechanism driver in ML2 (and
> >> openvswitch agents on compute nodes). But every time when I try to spawn
> >> instance I have got error "binding failed". After some searching in code
> >> I found that l2pop driver have not implemented method "bind_port" and as
> >> it inherit directly from "MechanismDriver" this method is in fact not
> >> implemented. Is is ok and this mechanism driver should be used in other
> >> way or maybe there is some bug in this driver and it miss this method?
> >> 
> >> Best regards
> >> Slawek Kaplonski
> >> sla...@kaplonski.pl
> >> 
> >> ___
> >> 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


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

Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)

[Dimitri Mazmanov]

Hi Solly,

On 06/05/14 19:16, "Solly Ross"  wrote:

>For your first question, I'll probably create a BP sometime today.

Great. Thanks. Happy to help with implementation.

>
>For your second question, allowing tenants to create flavors
>prevents one of the main parts of the flavor idea from working --
>having flavors that nicely fit together to prevent "wasted" host
>resources.  For instance suppose the normal system flavors used
>memory in powers of 2GB (2, 4, 8, 16, 32).  Now suppose someone
>came in, created a private flavor that used 3GB of RAM.  We now
>have 1GB of RAM that can never be used, unless someone decides
>to come along and create a 1GB flavor (actually, since RAM has
>even more granularity than that, you could have someone specify
>that they wanted 1.34GB of RAM, for instance, and then you have
>all sorts of weird stuff going on).

When I said "create custom flavor" I never meant allowing the users such
nonsense as specifying 1.34GB of RAM (this can be controlled by having
constraints). Although some can be very meticulous :)
Still an issue?
My basic idea was to let the users think in terms of physical resources
and based on that let them create the configuration they need (if they
don’t find the right flavor in the global list).

>
>Best Regards,
>Solly Ross
>
>- Original Message -
>From: "Dimitri Mazmanov" 
>To: "OpenStack Development Mailing List (not for usage questions)"
>
>Sent: Monday, May 5, 2014 3:40:08 PM
>Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation
>through Heat (pt.2)
>
>This is good! Is there a blueprint describing this idea? Or any plans
>describing it in a blueprint?
>Would happily share the work.
>
>Should we mix it with flavors in horizon though? I¹m thinking of having a
>separate ³Resources² page,
>wherein the user can ³define² resources. I¹m not a UX expert though.
>
>But let me come back to the project-scoped flavor creation issues.
>Why do you think it¹s such a bad idea to let tenants create flavors for
>their project specific needs?
>
>I¹ll refer again to the Steve Hardy¹s proposal:
>- Normal user : Can create a private flavor in a tenant where they
>  have the Member role (invisible to any other users)
>- Tenant Admin user : Can create public flavors in the tenants where they
>  have the admin role (visible to all users in the tenant)
>- Domain admin user : Can create public flavors in the domains where they
>  have the admin role (visible to all users in all tenants in that domain)
>
>
>> If you actually have 64 flavors, though, and it's overwhelming
>> your users, ...
>
>The users won¹t see all 64 flavor, only those they have defined and
>public.
>__
>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] Question about addit log in nova-compute.log

[Jiang, Yunhong]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Tuesday, May 06, 2014 10:44 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Question about addit log in
> nova-compute.log
> 
> On 05/06/2014 01:37 PM, Jiang, Yunhong wrote:
> >> -Original Message-
> >> From: Jay Pipes [mailto:jaypi...@gmail.com]
> >> Sent: Monday, May 05, 2014 6:19 PM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [nova] Question about addit log in
> >> nova-compute.log
> >>
> >> On 05/05/2014 04:19 PM, Jiang, Yunhong wrote:
>  -Original Message-
>  From: Jay Pipes [mailto:jaypi...@gmail.com]
>  Sent: Monday, May 05, 2014 9:50 AM
>  To: openstack-dev@lists.openstack.org
>  Subject: Re: [openstack-dev] [nova] Question about addit log in
>  nova-compute.log
> 
>  On 05/04/2014 11:09 PM, Chen CH Ji wrote:
> > Hi
> >   I saw in my compute.log has following logs
> which
> >> looks
> > to me strange at first, Free resource is negative make me confused
> >> and I
> > take a look at the existing code
> >   looks to me the logic is correct and calculation
> >> doesn't
> > have problem ,but the output 'Free' is confusing
> >
> >   Is this on purpose or might need to be
> enhanced?
> >
> > 2014-05-05 10:51:33.732 4992 AUDIT
> >> nova.compute.resource_tracker
>  [-]
> > Free ram (MB): -1559
> > 2014-05-05 10:51:33.732 4992 AUDIT
> >> nova.compute.resource_tracker
>  [-]
> > Free disk (GB): 29
> > 2014-05-05 10:51:33.732 4992 AUDIT
> >> nova.compute.resource_tracker
>  [-]
> > Free VCPUS: -3
> 
>  Hi Kevin,
> 
>  I think changing "free" to "available" might make things a little more
>  clear. In the above case, it may be that your compute worker has
> both
>  CPU and RAM overcommit enabled.
> 
>  Best,
>  -jay
> >>>
> >>> HI, Jay,
> >>>   I don't think change 'free' to 'available' will make it clearer.
> >>>   IMHO, the calculation of the 'free' is bogus. When report the
> status in
> >> the periodic task, the resource tracker has no idea of the over-commit
> >> ration at all, thus it simply subtract the total RAM number assigned to
> >> instances from the RAM number provided by hypervisor w/o
> considering
> >> the over-commitment at all. So this number really have meaningless.
> >>
> >> Agreed that in it's current state, it's meaningless. But... that said,
> >> the numbers *could* be used to show oversubscription percentage,
> and
> >> you
> >> don't need to know the max overcommit ratio in order to calculate that
> >> with the numbers already known.
> >
> > I don't think user can use these number to calculate the 'available'. User
> has to know the max overcommit ratio to know the 'available'. Also, it's
> really ironic to provide some meaningless information and have the user
> to calculate to get meaningful.
> >
> > This is related to https://bugs.launchpad.net/nova/+bug/1300775 . I
> think it will be better if we can have the resource tracker to knows about
> the ratio.
> 
> Sorry, you misunderstood me... I was referring to the resource tracker
> above, not a regular user. The resource tracker already knows the total
> amount of physical resources available on each compute node, and it
> knows the resource usage reported by each compute node. Therefore,
> the
> resource tracker already has all the information it needs to understand
> the *actual* overcommit ratio of CPU and memory on each compute
> node,
> regardless of the settings of the *maximum* overcommit ratio on a
> compute node (which is in each compute node's nova.conf).
> 
> Hope that makes things a bit clearer! Sorry for the confusion :)

Aha, the 'actual' and 'maximum' makes it quite clear now , thanks for 
clarification.

--jyh
> 
> Best,
> -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] [Juno-Summit] availability of the project "project pod" rooms on Monday May 12th?

[Sergey Lukjanov]

Will we have an ATC Lounge like in Hong Kong?

On Tue, May 6, 2014 at 9:58 AM, Carl Baldwin  wrote:
> Is there a map, a list, or some other official reference?  I may like
> to use a pod for a cross-project discussion about DNS between Nova,
> Neutron, and Designate.  Not a big deal but it might be nice to know
> more about what we're looking for when we get there.
>
> Thanks,
> Carl
>
> On Tue, May 6, 2014 at 6:37 AM, Thierry Carrez  wrote:
>> Eoghan Glynn wrote:
 IIRC Thierry said that pods will be available starting from Monday.
>>>
>>> Thanks Sergey, in the absence of any other indications to the
>>> contrary, I'm gonna assume that's the case :)
>>
>> Yes, pods should be available on Monday, although there won't be any
>> drinks/food served around them.
>>
>> --
>> Thierry Carrez (ttx)
>>
>> ___
>> 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



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.

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

[openstack-dev] nova-compute error

[sonia verma]

Hi all

I'm getting following error when booting VM onto compute node from
openstack dashboard...

014-05-06 12:47:22.393 DEBUG nova.openstack.common.processutils
[req-cc3cf4c6-160d-4dd4-b44d-d8f5c25fb55c admin admin] Result was 12
execute /opt/stack/nova/nova/openstack/common/processutils.py:172
2014-05-06 12:47:22.395 DEBUG nova.virt.disk.mount.api
[req-cc3cf4c6-160d-4dd4-b44d-d8f5c25fb55c admin admin] Failed to mount
filesystem: Unexpected error while running command.
Command: sudo nova-rootwrap /etc/nova/rootwrap.conf mount /dev/nbd9
/tmp/openstack-vfs-localfsjqwQWj
Exit code: 12
Stdout: ''
Stderr: "Failed to read bootsector (size=0)\nFailed to mount '/dev/nbd9':
Invalid argument\nThe device '/dev/nbd9' doesn't seem to have a valid
NTFS.\nMaybe the wrong device is used? Or the whole disk instead of
a\npartition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?\n"
mnt_dev /opt/stack/nova/nova/virt/disk/mount/api.py:198
2014-05-06 12:47:22.396 DEBUG nova.virt.disk.mount.api
[req-cc3cf4c6-160d-4dd4-b44d-d8f5c25fb55c admin admin] Fail to mount,
tearing back down do_mount /opt/stack/nova/nova/virt/disk/mount/api.py:219
2014-05-06 12:47:22.396 DEBUG nova.virt.disk.mount.api
[req-cc3cf4c6-160d-4dd4-b44d-d8f5c25fb55c admin admin] Unmap dev /dev/nbd9
unmap_dev /opt/stack/nova/nova/virt/disk/mount/api.py:184
2014-05-06 12:47:22.397 DEBUG nova.virt.disk.mount.nbd
[req-cc3cf4c6-160d-4dd4-b44d-d8f5c25fb55c admin admin] Release nbd device
/dev/nbd9 unget_dev /opt/stack/nova/nova/virt/disk/mount/nbd.py:129
2014-05-06 12:47:22.398 DEBUG nova.openstack.common.processutils
[req-cc3cf4c6-160d-4dd4-b44d-d8f5c25fb55c admin admin] Running cmd
(subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf qemu-nbd -d
/dev/nbd9 execute /opt/stack/nova/nova/openstack/common/processutils.py:147
2014-05-06 12:47:22.573 DEBUG nova.virt.disk.vfs.localfs
[req-cc3cf4c6-160d-4dd4-b44d-d8f5c25fb55c admin admin] Failed to mount
image Failed to mount filesystem: Unexpected error while running command.
Command: sudo nova-rootwrap /etc/nova/rootwrap.conf mount /dev/nbd9
/tmp/openstack-vfs-localfsjqwQWj
Exit code: 12

Please help regarding this.


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

Re: [openstack-dev] [Neutron][Nova][Designate][L3][IPv6] Discussion about Cross-Project Integration of DNS at Summit

[Veiga, Anthony]

Hi,

The only issue I would see with the pod is that not all of us are ATCs, so we 
may or may not have access to that area (I am open to correction on that point 
- in fact I hope someone does ;) )

I’ll second this.  I have an interest in attending and assisting here, but I 
don’t have ATC status yet (though I’m an active contributor technically, just 
not via code.)



I could see it fitting in with our design session, but maybe if we meet on the 
Monday to do some initial hashing out as well, I think that would be good.

I am around for the morning, and later on in the afternoon on Monday, if that 
suits.

Graham

On Tue, 2014-05-06 at 11:21 -0600, Carl Baldwin wrote:

I have just updated my etherpad [1] with some proposed times.  Not
knowing much about the venue, I could only propose the "pod area" as a
the location.

I also updated the designate session etherpad [2] per your suggestion.
 If there is time during the Designate sessions to include this in the
discussion then that may work out well.

Thanks,
Carl

[1] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate
[2] https://etherpad.openstack.org/p/DesignateAtlantaDesignSession

On Tue, May 6, 2014 at 8:58 AM, Joe Mcbride 
mailto:jmcbr...@rackspace.com>> wrote:
>> On 4/29/14, 3:09 PM, "Carl Baldwin" 
>> mailto:c...@ecbaldwin.net>> wrote:>>>I feel this is an 
>> important subject to discuss because the end result>>will be a better cloud 
>> user experience overall.  The design summit>>could be a great time to bring 
>> together interested parties from>>Neutron, Nova, and Designate to discuss 
>> the integration that I propose>>in these blueprints.>> Do you have a 
>> time/location planned for these discussions? If not, we may> have some time 
>> in one of the Designate sessions.  The priorities and> details for our 
>> design session will be pulled from> 
>> https://etherpad.openstack.org/p/DesignateAtlantaDesignSession. If you are> 
>> interested in joining us, can you add your proposed blueprints in the> 
>> format noted there?>> Thanks,> joe>>> 
>> ___> 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.orghttp://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] Question about addit log in nova-compute.log

[Jay Pipes]

On 05/06/2014 01:37 PM, Jiang, Yunhong wrote:

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, May 05, 2014 6:19 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Question about addit log in
nova-compute.log

On 05/05/2014 04:19 PM, Jiang, Yunhong wrote:

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, May 05, 2014 9:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Question about addit log in
nova-compute.log

On 05/04/2014 11:09 PM, Chen CH Ji wrote:

Hi
  I saw in my compute.log has following logs which

looks

to me strange at first, Free resource is negative make me confused

and I

take a look at the existing code
  looks to me the logic is correct and calculation

doesn't

have problem ,but the output 'Free' is confusing

  Is this on purpose or might need to be enhanced?

2014-05-05 10:51:33.732 4992 AUDIT

nova.compute.resource_tracker

[-]

Free ram (MB): -1559
2014-05-05 10:51:33.732 4992 AUDIT

nova.compute.resource_tracker

[-]

Free disk (GB): 29
2014-05-05 10:51:33.732 4992 AUDIT

nova.compute.resource_tracker

[-]

Free VCPUS: -3


Hi Kevin,

I think changing "free" to "available" might make things a little more
clear. In the above case, it may be that your compute worker has both
CPU and RAM overcommit enabled.

Best,
-jay


HI, Jay,
I don't think change 'free' to 'available' will make it clearer.
IMHO, the calculation of the 'free' is bogus. When report the status in

the periodic task, the resource tracker has no idea of the over-commit
ration at all, thus it simply subtract the total RAM number assigned to
instances from the RAM number provided by hypervisor w/o considering
the over-commitment at all. So this number really have meaningless.

Agreed that in it's current state, it's meaningless. But... that said,
the numbers *could* be used to show oversubscription percentage, and
you
don't need to know the max overcommit ratio in order to calculate that
with the numbers already known.


I don't think user can use these number to calculate the 'available'. User has 
to know the max overcommit ratio to know the 'available'. Also, it's really 
ironic to provide some meaningless information and have the user to calculate 
to get meaningful.

This is related to https://bugs.launchpad.net/nova/+bug/1300775 . I think it 
will be better if we can have the resource tracker to knows about the ratio.


Sorry, you misunderstood me... I was referring to the resource tracker 
above, not a regular user. The resource tracker already knows the total 
amount of physical resources available on each compute node, and it 
knows the resource usage reported by each compute node. Therefore, the 
resource tracker already has all the information it needs to understand 
the *actual* overcommit ratio of CPU and memory on each compute node, 
regardless of the settings of the *maximum* overcommit ratio on a 
compute node (which is in each compute node's nova.conf).


Hope that makes things a bit clearer! Sorry for the confusion :)

Best,
-jay

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

Re: [openstack-dev] [nova] Question about addit log in nova-compute.log

[Jiang, Yunhong]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Monday, May 05, 2014 6:19 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Question about addit log in
> nova-compute.log
> 
> On 05/05/2014 04:19 PM, Jiang, Yunhong wrote:
> >> -Original Message-
> >> From: Jay Pipes [mailto:jaypi...@gmail.com]
> >> Sent: Monday, May 05, 2014 9:50 AM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [nova] Question about addit log in
> >> nova-compute.log
> >>
> >> On 05/04/2014 11:09 PM, Chen CH Ji wrote:
> >>> Hi
> >>>  I saw in my compute.log has following logs which
> looks
> >>> to me strange at first, Free resource is negative make me confused
> and I
> >>> take a look at the existing code
> >>>  looks to me the logic is correct and calculation
> doesn't
> >>> have problem ,but the output 'Free' is confusing
> >>>
> >>>  Is this on purpose or might need to be enhanced?
> >>>
> >>> 2014-05-05 10:51:33.732 4992 AUDIT
> nova.compute.resource_tracker
> >> [-]
> >>> Free ram (MB): -1559
> >>> 2014-05-05 10:51:33.732 4992 AUDIT
> nova.compute.resource_tracker
> >> [-]
> >>> Free disk (GB): 29
> >>> 2014-05-05 10:51:33.732 4992 AUDIT
> nova.compute.resource_tracker
> >> [-]
> >>> Free VCPUS: -3
> >>
> >> Hi Kevin,
> >>
> >> I think changing "free" to "available" might make things a little more
> >> clear. In the above case, it may be that your compute worker has both
> >> CPU and RAM overcommit enabled.
> >>
> >> Best,
> >> -jay
> >
> > HI, Jay,
> > I don't think change 'free' to 'available' will make it clearer.
> > IMHO, the calculation of the 'free' is bogus. When report the status in
> the periodic task, the resource tracker has no idea of the over-commit
> ration at all, thus it simply subtract the total RAM number assigned to
> instances from the RAM number provided by hypervisor w/o considering
> the over-commitment at all. So this number really have meaningless.
> 
> Agreed that in it's current state, it's meaningless. But... that said,
> the numbers *could* be used to show oversubscription percentage, and
> you
> don't need to know the max overcommit ratio in order to calculate that
> with the numbers already known.

I don't think user can use these number to calculate the 'available'. User has 
to know the max overcommit ratio to know the 'available'. Also, it's really 
ironic to provide some meaningless information and have the user to calculate 
to get meaningful.

This is related to https://bugs.launchpad.net/nova/+bug/1300775 . I think it 
will be better if we can have the resource tracker to knows about the ratio.

--jyh

> 
> Best,
> -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] [Neutron][Nova][Designate][L3][IPv6] Discussion about Cross-Project Integration of DNS at Summit

[Hayes, Graham]

Hi,

The only issue I would see with the pod is that not all of us are ATCs,
so we may or may not have access to that area (I am open to correction
on that point - in fact I hope someone does ;) )

I could see it fitting in with our design session, but maybe if we meet
on the Monday to do some initial hashing out as well, I think that would
be good.

I am around for the morning, and later on in the afternoon on Monday, if
that suits.

Graham

On Tue, 2014-05-06 at 11:21 -0600, Carl Baldwin wrote:

> I have just updated my etherpad [1] with some proposed times.  Not
> knowing much about the venue, I could only propose the "pod area" as a
> the location.
> 
> I also updated the designate session etherpad [2] per your suggestion.
>  If there is time during the Designate sessions to include this in the
> discussion then that may work out well.
> 
> Thanks,
> Carl
> 
> [1] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate
> [2] https://etherpad.openstack.org/p/DesignateAtlantaDesignSession
> 
> On Tue, May 6, 2014 at 8:58 AM, Joe Mcbride  wrote:
> >
> > On 4/29/14, 3:09 PM, "Carl Baldwin"  wrote:
> >
> >>I feel this is an important subject to discuss because the end result
> >>will be a better cloud user experience overall.  The design summit
> >>could be a great time to bring together interested parties from
> >>Neutron, Nova, and Designate to discuss the integration that I propose
> >>in these blueprints.
> >
> > Do you have a time/location planned for these discussions? If not, we may
> > have some time in one of the Designate sessions.  The priorities and
> > details for our design session will be pulled from
> > https://etherpad.openstack.org/p/DesignateAtlantaDesignSession. If you are
> > interested in joining us, can you add your proposed blueprints in the
> > format noted there?
> >
> > Thanks,
> > joe
> >
> >
> > ___
> > 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




signature.asc
Description: This is a digitally signed message part


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] PGP keysigning party for Juno summit in Atlanta?

[Jeremy Stanley]

On 2014-05-06 12:36:34 +0200 (+0200), Thierry Carrez wrote:
> Note that we could pick any of the Design Summit rooms (they are
> larger and don't require us to move on 4th floor). They should all
> be empty during the break.

I was hesitant to try and use one of the design session rooms for
this since they tend to run long and wouldn't provide much
opportunity to set up in advance.

> B301 (160 seats) has infra sessions before and after the Wednesday
> 10:30am break, so there is overlap in attendance and we can easily
> push people out to start the keysigning ASAP.

Given that's Sean's session before the break (assuming it doesn't
get reshuffled) and he's signed up for the key signing too, he could
probably be persuaded to end on time and allow us to quickly free up
the room for that. If we go this route we'll probably still need to
plan to begin promptly at 10:35 AM EDT (five minutes into the break)
so that the projector can be attached and confirmed working while
attendees for the infra session in there clear out.

Any objections to this (particularly from Sean)? Preferences for
this plan over the separate room one floor up? Note that one down
side I see to this option is if anyone who isn't an ATC wants to
participate, we may need someone to help get them into the Design
Summit area.

> NB: I may be late as I've a summit presentation in the slot before
> and I may stay around to answer questions.

You'll likely miss the reading aloud of the file checksum and
(depending on how late you'll be) may miss display of some
individuals' identification on the projection screen, but at least
you can try to hit them up for a more traditional peek directly at
their passports/whatever later.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron][Nova][Designate][L3][IPv6] Discussion about Cross-Project Integration of DNS at Summit

[Carl Baldwin]

I have just updated my etherpad [1] with some proposed times.  Not
knowing much about the venue, I could only propose the "pod area" as a
the location.

I also updated the designate session etherpad [2] per your suggestion.
 If there is time during the Designate sessions to include this in the
discussion then that may work out well.

Thanks,
Carl

[1] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate
[2] https://etherpad.openstack.org/p/DesignateAtlantaDesignSession

On Tue, May 6, 2014 at 8:58 AM, Joe Mcbride  wrote:
>
> On 4/29/14, 3:09 PM, "Carl Baldwin"  wrote:
>
>>I feel this is an important subject to discuss because the end result
>>will be a better cloud user experience overall.  The design summit
>>could be a great time to bring together interested parties from
>>Neutron, Nova, and Designate to discuss the integration that I propose
>>in these blueprints.
>
> Do you have a time/location planned for these discussions? If not, we may
> have some time in one of the Designate sessions.  The priorities and
> details for our design session will be pulled from
> https://etherpad.openstack.org/p/DesignateAtlantaDesignSession. If you are
> interested in joining us, can you add your proposed blueprints in the
> format noted there?
>
> Thanks,
> joe
>
>
> ___
> 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] [Heat] Custom Nova Flavor creation through Heat (pt.2)

[Solly Ross]

For your first question, I'll probably create a BP sometime today.

For your second question, allowing tenants to create flavors
prevents one of the main parts of the flavor idea from working --
having flavors that nicely fit together to prevent "wasted" host
resources.  For instance suppose the normal system flavors used
memory in powers of 2GB (2, 4, 8, 16, 32).  Now suppose someone
came in, created a private flavor that used 3GB of RAM.  We now
have 1GB of RAM that can never be used, unless someone decides
to come along and create a 1GB flavor (actually, since RAM has
even more granularity than that, you could have someone specify
that they wanted 1.34GB of RAM, for instance, and then you have
all sorts of weird stuff going on).

Best Regards,
Solly Ross

- Original Message -
From: "Dimitri Mazmanov" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, May 5, 2014 3:40:08 PM
Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through 
Heat (pt.2)

This is good! Is there a blueprint describing this idea? Or any plans
describing it in a blueprint?
Would happily share the work.

Should we mix it with flavors in horizon though? I¹m thinking of having a
separate ³Resources² page,
wherein the user can ³define² resources. I¹m not a UX expert though.

But let me come back to the project-scoped flavor creation issues.
Why do you think it¹s such a bad idea to let tenants create flavors for
their project specific needs?

I¹ll refer again to the Steve Hardy¹s proposal:
- Normal user : Can create a private flavor in a tenant where they
  have the Member role (invisible to any other users)
- Tenant Admin user : Can create public flavors in the tenants where they
  have the admin role (visible to all users in the tenant)
- Domain admin user : Can create public flavors in the domains where they
  have the admin role (visible to all users in all tenants in that domain)


> If you actually have 64 flavors, though, and it's overwhelming
> your users, ...

The users won¹t see all 64 flavor, only those they have defined and public.

-

Dimitri

On 05/05/14 20:18, "Chris Friesen"  wrote:

>On 05/05/2014 11:40 AM, Solly Ross wrote:
>> One thing that I was discussing with @jaypipes and @dansmith over
>> on IRC was the possibility of breaking flavors down into separate
>> components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor.
>> This way, you still get the control of the size of your building blocks
>> (e.g. you could restrict RAM to only 2GB, 4GB, or 16GB), but you avoid
>> exponential flavor explosion by separating out the axes.
>
>I like this idea because it allows for greater flexibility, but I think
>we'd need to think carefully about how to expose it via horizon--maybe
>separate tabs within the overall "flavors" page?
>
>As a simplifying view you could keep the existing flavors which group
>all of them, while still allowing instances to specify each one
>separately if desired.
>
>Chris
>
>___
>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] [Trove] Proposal to add Craig Vyvial to trove-core

[McReynolds, Auston]

+1

On 5/6/14, 2:31 AM, "Nikhil Manchanda"  wrote:

>
>Hello folks:
>
>I'm proposing to add Craig Vyvial (cp16net) to trove-core.
>
>Craig has been working with Trove for a while now. He has been a
>consistently active reviewer, and has provided insightful comments on
>numerous reviews. He has submitted quality code to multiple features in
>Trove, and most recently drove the implementation of configuration
>groups in Icehouse.
>
>https://review.openstack.org/#/q/reviewer:%22Craig+Vyvial%22,n,z
>https://review.openstack.org/#/q/owner:%22Craig+Vyvial%22,n,z
>
>Please respond with +1/-1, or any further comments.
>
>Thanks,
>Nikhil
>
>___
>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] Add VMware dvSwitch/vSphere API support for Neutron ML2

[Armando M.]

Hi Ilkka,

As Mathieu suggested there is a blueprint submission and revision
process put in place since the Juno release. Also, since Icehouse, to
incorporate a new plugin/mechanism driver into the Neutron source
tree, and to be designated as compatible, such a plugin/driver must be
accompanied by external third party CI testing (more details in [1]).

This means that, once the blueprint work has been approved, the code
must be submitted through the same review process adopted for the
blueprint, as detailed in [2], and accompanied by validation through
third party CI.

This sounds like a lot of work, but it is aimed at ensuring all the
usual ilities of the software being part of the official source tree.

That said, you are not alone and you can tap into the usual channels,
like the mailing list or IRC ([3]). If there is anything vmware
specific that you would like to address, we are here to help, so feel
free to direct your questions to #openstack-vmware.

Keep up the good work!

Cheers,
Armando

[1] - https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers
[2] - https://wiki.openstack.org/wiki/Gerrit_Workflow
[3] - https://wiki.openstack.org/wiki/IRC

On 6 May 2014 01:17, Mathieu Rohon  wrote:
> Hi IIkka,
>
> this is a very interesting MD for ML2. Have you ever tried to use your
> ML2 driver with VMWare drivers on the nova side, so that you could
> manage your VM with nova, and its network with neutron.
> Do you think it would be difficult to extend your driver to support
> vxlan encapsulation?
>
> Neutron has a new process to validate BP. Please follow those
> instructions to submit your spec for review :
> https://wiki.openstack.org/wiki/Blueprints#Neutron
>
> regards
>
> On Mon, May 5, 2014 at 2:22 PM, Ilkka Tengvall
>  wrote:
>> Hi,
>>
>> I would like to start a discussion about a ML2 driver for VMware distributed
>> virtual switch (dvSwitch) for Neutron. There is a new blueprint made by Sami
>> Mäkinen (sjm) in
>> https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mech-vmware-dvswitch.
>>
>> The driver is described and code is publicly available and hosted in github:
>> https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mech-vmware-dvswitch
>>
>> We would like to get the driver through contribution process, what ever that
>> exactly means :)
>>
>> The original problem this driver solves for is is the following:
>>
>> We've been running VMware virtualization platform in our data center before
>> OpenStack, and we will keep doing it due existing services. We also have
>> been running OpenStack for a while also. Now we wanted to get the most out
>> of both by combining the customers networks on the both plafroms by using
>> provider networks. The problem is that the networks need two separate
>> managers, neutron and vmware. There was no OpenStack tools to attach the
>> guests on VMware side to OpenStack provider networks during instance
>> creation.
>>
>> Now we are putting our VMware under control of OpenStack. We want to have
>> one master to control the networks, Neutron. We implemented the new ML2
>> driver to do just that. It is capable of joining the machines created in
>> vSphere to the same provider networks the OpenStack uses, using dvSwitch
>> port groups.
>>
>>
>> I just wanted to open the discussion, for the technical details please
>> contact our experts on the CC list:
>>
>> Sami J. Mäkinen
>> Jussi Sorjonen (freenode: mieleton)
>>
>>
>> BR,
>>
>> Ilkka Tengvall
>>  Advisory Consultant, Cloud Architecture
>>  email:  ilkka.tengv...@cybercom.com
>>  mobile: +358408443462
>>  freenode: ikke-t
>>  web:http://cybercom.com - http://cybercom.fi
>>
>> ___
>> 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] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

[Duncan Thomas]

On 6 May 2014 14:46, Trump.Zhang  wrote:

> Did you mean using volume metadata was not the right way for the first
> situation I mentioned in ealier mail?


Correct. Volume metadata is entirely for the tenant to use, it is not
interpreted by cinder or nova as meaning anything.

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

Re: [openstack-dev] [Juno-Summit] availability of the project "project pod" rooms on Monday May 12th?

[Carl Baldwin]

Is there a map, a list, or some other official reference?  I may like
to use a pod for a cross-project discussion about DNS between Nova,
Neutron, and Designate.  Not a big deal but it might be nice to know
more about what we're looking for when we get there.

Thanks,
Carl

On Tue, May 6, 2014 at 6:37 AM, Thierry Carrez  wrote:
> Eoghan Glynn wrote:
>>> IIRC Thierry said that pods will be available starting from Monday.
>>
>> Thanks Sergey, in the absence of any other indications to the
>> contrary, I'm gonna assume that's the case :)
>
> Yes, pods should be available on Monday, although there won't be any
> drinks/food served around them.
>
> --
> Thierry Carrez (ttx)
>
> ___
> 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] Monitoring as a Service

[Thierry Carrez]

Sandy Walsh wrote:
> I'd be curious to know more what "managed" means in this situation? Is
> the core project expected to allocate time in the IRC meeting to the
> concerns of these adjacent projects? What if the core project doesn't
> agree with the direction or deems there's too much overlap? Does the
> core team instantly have sway over the adjacent project?

It has to be basically the same team of people working on the two
projects. The goals and the direction of the project are shared. There
is no way it can work if you consider some "core" and some "adjacent",
that would quickly create a us vs. them mentality and not work out that
well in reviews.

Of course, there can be contributors that are not interested in one
project or another. But if you end up with completely-separated
subteams, then there is little value in living under the same umbrella
and sharing a core team.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [horizon] Unofficial Sunday Summit Meetup

[Jason Rist]

On Tue 06 May 2014 10:29:43 AM MDT, Jaromir Coufal wrote:
> Hi folks,
>
> during Horizon's IRC meeting, we got to the idea that it would be
> great to hang out on Sunday evening and meet unofficially before the
> Summit.
>
> We are gathering all suggestions in following etherpad:
> https://etherpad.openstack.org/p/juno-summit-horizon-sunday-evening
> (you can find the latest info here).
>
> So everybody interested - join us - we are looking forward to all of
> you! :)
>
> -- Jarda
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

At the moment, looks like we're planning on meeting at the Westin 
Sundial restaurant bar at 8PM!  See the etherpad for more info.

-Jason

--
Jason E. Rist
Senior Software Engineer
OpenStack Management UI
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/identi.ca: knowncitizen

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

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Stephen Wong]

Hi Sean,

Yes. Please count me in (we need to integrate QoS parameters as
possible actions for group-policy).

Thanks,
- Stephen


On Tue, May 6, 2014 at 9:19 AM, Collins, Sean <
sean_colli...@cable.comcast.com> wrote:

> For those attending, to discuss the QoS API current status?
>
> --
> Sean M. Collins
> ___
> 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] [horizon] Unofficial Sunday Summit Meetup

[Aditya Thatte]

Thats a great idea. Looking forward to it.


On Tue, May 6, 2014 at 9:59 PM, Jaromir Coufal  wrote:

> Hi folks,
>
> during Horizon's IRC meeting, we got to the idea that it would be great to
> hang out on Sunday evening and meet unofficially before the Summit.
>
> We are gathering all suggestions in following etherpad:
> https://etherpad.openstack.org/p/juno-summit-horizon-sunday-evening
> (you can find the latest info here).
>
> So everybody interested - join us - we are looking forward to all of you!
> :)
>
> -- Jarda
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [Cinder] Question about synchronized decoration usage in cinder-volume

[Vishvananda Ishaya]

On Apr 26, 2014, at 2:56 AM, Zhangleiqiang (Trump)  
wrote:

> Hi, all:
> 
>   I find almost all of the @utils.synchronized decoration usage in 
> cinder-volume (cinder.volume.manager / cinder.volume.drivers.*) with an 
> "external=True" param. Such as 
> cinder.volume.manager.VolumeManager:attach_volume:
> 
>   def attach_volume(self, context, volume_id, instance_uuid, 
> host_name,
>  mountpoint, mode):
>"""Updates db to show volume is attached."""
>@utils.synchronized(volume_id, external=True)
>def do_attach():
> 
>   However, in docstring of common.lockutils.synchronized, I find param 
> "external" is used for multi-workers scenario:
>   
>   :param external: The external keyword argument denotes whether 
> this lock
>   should work across multiple processes. This means that if two different
>   workers both run a a method decorated with @synchronized('mylock',
>   external=True), only one of them will execute at a time.
>   
>   I have two questions about it.
>   1. As far as I know, cinder-api has supported multi-worker mode and 
> cinder-volume doesn't support it, does it? So I wonder why the 
> "external=True" param is used here?

Before the multibackend support in cinder-volume it was common to run more than 
one cinder-volume for different backends on the same host. This would require 
external=True
>   2. Specific to cinder.volume.manager.VolumeManager:attach_volume, all 
> operations in "do_attach" method are database related. As said in [1], 
> operations to the database will block the main thread of a service, so 
> another question I want to know is why this method is needed to be 
> synchronized?
Currently db operations block the main thread of the service, but hopefully 
this will change in the future.

Vish

> 
>   Thanks.
> 
> [1] 
> http://docs.openstack.org/developer/cinder/devref/threading.html#mysql-access-and-eventlet
> --
> zhangleiqiang (Trump)
> 
> Best Regards
> 
> 
> 
> ___
> 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

[openstack-dev] [horizon] Unofficial Sunday Summit Meetup

[Jaromir Coufal]

Hi folks,

during Horizon's IRC meeting, we got to the idea that it would be great 
to hang out on Sunday evening and meet unofficially before the Summit.


We are gathering all suggestions in following etherpad:
https://etherpad.openstack.org/p/juno-summit-horizon-sunday-evening
(you can find the latest info here).

So everybody interested - join us - we are looking forward to all of you! :)

-- Jarda

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

[openstack-dev] [Horizon]Atlanta Summit Sunday Evening Unofficial Meetup Plan

[Douglas Fish]

The Horizon team is planning an informal meet up before the Atlanta summit.
We're still working out the time and place.  Discussion is happening here:
https://etherpad.openstack.org/p/juno-summit-horizon-sunday-evening


Doug Fish


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

Re: [openstack-dev] Monitoring as a Service

[Clint Byrum]

Excerpts from Sandy Walsh's message of 2014-05-06 07:02:05 -0700:
> On 5/6/2014 10:04 AM, Thierry Carrez wrote:
> > John Dickinson wrote:
> >> One of the advantages of the program concept within OpenStack is that 
> >> separate code projects with complementary goals can be managed under the 
> >> same program without needing to be the same codebase. The most obvious 
> >> example across every program are the "server" and "client" projects under 
> >> most programs.
> >>
> >> This may be something that can be used here, if it doesn't make sense to 
> >> extend the ceilometer codebase itself.
> > +1
> >
> > Being under the Telemetry umbrella lets you make the right technical
> > decision between same or separate codebase, as both would be supported
> > by the organizational structure.
> >
> > It also would likely give you an initial set of contributors interested
> > in the same end goals. So at this point I'd focus on engaging with the
> > Telemetry program folks and see if they would be interested in that
> > capability (inside or outside of the Ceilometer code base).
> 
> This is interesting.
> 
> I'd be curious to know more what "managed" means in this situation? Is
> the core project expected to allocate time in the IRC meeting to the
> concerns of these adjacent projects? What if the core project doesn't
> agree with the direction or deems there's too much overlap? Does the
> core team instantly have sway over the adjacent project?
> 

Yes, the core team instantly has sway. It is not to be taken lightly.

We absorbed Tuskar into the Deployment program, and our PTL, Robert
Collins, was able to get involved with the design of Tuskar early and
convince them to stay more aligned with other OpenStack projects. So
the benefit is now Tuskar can focus on the thing that they _do_ need
to do that are unique.  Likewise, their core team was given core status
in the deployment program, and was able to influence the pieces of the
Deployment program that they needed to work better.

This has created a nice cycle of contribution where many aspects of the
Deployment program's projects have been improved as a result. Had Tuskar
decided to just stay out of the Deployment program, they might have
reimplemented many of the things we had already done, and thus would
be less adoptable by users and they would receive less contribution as
a whole.

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

[openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Collins, Sean]

For those attending, to discuss the QoS API current status?

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

Re: [openstack-dev] [neutron] Design Summit Sessions

[Edgar Magana Perdomo (eperdomo)]

Great Idea Terry!

Edgar

On 5/6/14, 6:07 AM, "Thierry Carrez"  wrote:

>Manish Godara wrote:
>> Sounds like a good idea to me.  Is the pod area for neutron-specific
>> discussions?
>
>Each program (including Networking (Neutron)) has an assigned "pod"
>(round table). So the Networking one would be for neutron-specific
>discussions, yes.
>
>-- 
>Thierry Carrez (ttx)
>
>___
>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] [Climate] Query leases by project_id/domain_id

[Fuente, Pablo A]

Any comments on this?

On Mon, 2014-04-28 at 16:57 +, Fuente, Pablo A wrote:
> Any comments on this?
> 
> On Tue, 2014-04-22 at 18:58 +, Fuente, Pablo A wrote:
> > Hi
> > I'm trying to tackle this bug
> > (https://bugs.launchpad.net/climate/+bug/1304435). The options that I'm
> > considering are:
> > 
> > 1 - Add the project_id query parameter to the leases API
> > 2 - Use the X_PROJECT_ID header
> > 
> > I prefer the first option, but I would like to know if there is a
> > general OpenStack approach for implementing this. BTW, I'm planning to
> > apply the same criteria for making queries for Domains.
> > 
> > Pablo.
> > ___
> > 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] [infra] Intermittent network problems allowed to sneak passed the gate?

[Derek Higgins]

On 06/05/14 16:17, Sean Dague wrote:
> On 05/06/2014 10:52 AM, Derek Higgins wrote:
>> Hi,
>>
>> I've been working on a check job that uses devstack-gate jobs to run
>> the nova with the docker driver, while doing this I noticed that
>> sometimes during the nova boot for an instance the node looses network
>> connectivity(obviously a problem that needs to be worked on).
>> Whats interesting is zuuls behavior when this occurs in the check queue.
>> The job simply got restarted and this kept happening until the job passed.
>>
>> A legitimately failed job :
>>   https://jenkins05.openstack.org/job/check-nova-docker-dsvm-f20/2/
>>
>> http://logs.openstack.org/14/91514/5/check/check-nova-docker-dsvm-f20/d5c1ebf/console.html
>>
>> Retry (also failed)  :
>>   https://jenkins07.openstack.org/job/check-nova-docker-dsvm-f20/3/
>>
>> http://logs.openstack.org/14/91514/5/check/check-nova-docker-dsvm-f20/d5f26ed/console.html
>>
>> Retried again (passed)   :
>>   https://jenkins01.openstack.org/job/check-nova-docker-dsvm-f20/3/
>>
>> http://logs.openstack.org/14/91514/5/check/check-nova-docker-dsvm-f20/2ebfa88/console.html
>>
>> And success gets reported back to gerrit
>> https://review.openstack.org/#/c/91514/
>> Patch Set 5: Verified+1
>> check-nova-docker-dsvm-f20 SUCCESS in 17m 27s (non-voting)
>>
>>
>> Wouldn't this behavior allow commits that cause intermittent network
>> problems to more easily sneak passed the gating infrastructure?
>>
>>
>> I'm guessing that the retry is being triggered in
>> zuul/launcher/gearman.py : onBuildCompleted()
>>
>> because onDisconnect calls onBuildCompleted with no results param
>>
>> Any thoughts?
> 
> There is some automatic retry facility in zuul right now to deal with a
> set of issues which are considered recoverable and typically the fault
> of the infrastructure provider.
> 
> There might be a way to slip something through, however, all failures in
> the gate do tend to get eyes on them, and I've yet to see this kind of
> issue slip through. So something to keep an eye out for. Would be
Hasn't this problem already slipped through (although its in the check
queue not the gate), I mean it can now be merged and was only noticed
because I was watching the zuul status page while the jobs were running?

> curious to see if we can mine out these issues in elastic recheck. The
> failed results are still reported to logstash from what I can see, so we
> can track them.
I'll see if I can find any similar occurrences in other jobs and report
back.

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