[openstack-dev] [Heat] [TripleO] Better handling of lists in Heat - a proposal to add a map function

[Clint Byrum]

Since picking up Heat and trying to think about how to express clusters
of things, I've been troubled by how poorly the CFN language supports
using lists. There has always been the Fn::Select function for
dereferencing arrays and maps, and recently we added a nice enhancement
to HOT to allow referencing these directly in get_attr and get_param.

However, this does not help us when we want to do something with all of
the members of a list.

In many applications I suspect the template authors will want to do what
we want to do now in TripleO. We have a list of identical servers and
we'd like to fetch the same attribute from them all, join it with other
attributes, and return that as a string.

The specific case is that we need to have all of the hosts in a cluster
of machines addressable in /etc/hosts (please, Designate, save us,
eventually. ;). The way to do this if we had just explicit resources
named NovaCompute0, NovaCompute1, would be:

  str_join:
- "\n"
- - str_join:
- ' '
- get_attr:
  - NovaCompute0
  - networks.ctlplane.0
- get_attr:
  - NovaCompute0
  - name
  - str_join:
- ' '
- get_attr:
  - NovaCompute1
  - networks.ctplane.0
- get_attr:
  - NovaCompute1
  - name

Now, what I'd really like to do is this:

map:
  - str_join:
- "\n"
- - str_join:
  - ' '
  - get_attr:
- "$1"
- networks.ctlplane.0
  - get_attr:
- "$1"
- name
  - - NovaCompute0
- NovaCompute1

This would be helpful for the instances of resource groups too, as we
can make sure they return a list. The above then becomes:


map:
  - str_join:
- "\n"
- - str_join:
  - ' '
  - get_attr:
- "$1"
- networks.ctlplane.0
  - get_attr:
- "$1"
- name
  - get_attr:
  - NovaComputeGroup
  - member_resources

Thoughts on this idea? I will throw together an implementation soon but
wanted to get this idea out there into the hive mind ASAP.

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

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

[Oleg Bondarev]

Hi folks,
please see a few comments inline.

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

> A couple quick suggestions (additions):
>
>  Entity: L7Rule
>
> o   Attribute: type
>
> §  Possible values:
>
>
>- HTTP_METHOD
>
> o   Attribute: compare_type
>
> §  Possible values:
>
>
>- GT (greater than)
>- LT (less than)
>- GE (greater than or equal to)
>- LE (less than or equal to)
>
> Will we be doing syntax checking based on the L7Rule type being presented?
>  (eg. if w'ere going to check that HEADER X has a value that is greater
> than Y, are we going to make sure that "Y" is an integer? Or if we're going
> to check that the PATH STARTS_WITH Z, are we going to make sure that Z is a
> non-zero-length string? )
>
I think we should do these checks on the plugin level (API level doesn't
support such checks at the moment).

>
>
Thanks,
> Stephen
>
> On Tue, Feb 18, 2014 at 3:58 AM, Avishay Balderman 
> wrote:
>
>>  Here are the suggested values for the attributes below:
>>
>> · Entity: L7Rule
>>
>> o   Attribute: type
>>
>> §  Possible values:
>>
>> · HOST_NAME
>>
>> · PATH
>>
>> · FILE_NAME
>>
>> · FILE_TYPE
>>
> Can somebody please clarify what FILE_NAME and FILE_TYPE mean? Just can't
find corresponding matching criterias in haproxy.

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

Re: [openstack-dev] [Nova][EC2][Cinder] Asking for time to review my patches

[Rushi Agrawal]

Thanks, Ben. Point noted. Sorry for the noise :)

Regards,
Rushi Agrawal
Cloud engineer,
Reliance Jio Infocomm, India
Ph: (+91) 99 4518 4519


On 17 February 2014 22:13, Ben Nemec  wrote:

>  Rushi, please see
> http://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html
>
> Thanks.
>
> -Ben
>
> On 2014-02-15 07:18, Rushi Agrawal wrote:
>
> Over the last two months, I have submitted few patches which increases
> support of block storage volumes in OpenStack's EC2 API. The blueprints for
> them have been approved, and the code is ready for review.
>
> * Expose volume type
>  https://review.openstack.org/#/c/61041/
>
> * Expose volume tags
> https://review.openstack.org/#/c/64690/
>
> * Expose volume snapshot tags
> https://review.openstack.org/#/c/66291/
>
> * Expose filtering of volumes
>  https://review.openstack.org/#/c/62350/
> https://review.openstack.org/#/c/70085/
>
> I would like to solicit some feedback from interested/affected folks, so
> that I can incorporate them sooner so as not to bother you people near the
> end of milestone :)
>
> Any help would be greatly appreciated.
>
>  Thanks and regards,
> Rushi Agrawal
> Cloud engineer,
> Reliance Jio Infocomm, India
> Ph: (+91) 99 4518 4519
>
> ___
> OpenStack-dev mailing 
> listOpenStack-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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Eugene Nikanorov]

Thanks for quick response, Stephen,

See my comments inline:


On Wed, Feb 19, 2014 at 6:28 AM, Stephen Balukoff 
 wrote:

> Hi y'all!
>
> Eugene:  Are the arrows in your diagrams meaningful?
>
Arrow means 'one object references another'.


> Regarding existing workflows: Do we have any idea how widely the existing
> Neutron LBaaS is being deployed / used in the wild?  (In our environment,
> we don't use it yet because it's not sophisticated enough for many of our
> customers' needs.)  In other words, is breaking backward compatibility a
> huge concern?  In our environment, obviously it's not.
>
It's more a policy then a concern: we need to maintain compatibility for at
least one release cycle before deprecating workflow/API parts.

>
> I personally favor #3 as suggested, but again, I do doubt the need to have
> pools associated with a vip_id, or listener_id:  That is, in larger
> clusters it may be advantageous to have a single pool that is referenced by
> several listeners and VIPs.
>
Agree, the pool can be shared, we concluded this as well during the
discussion with Mark.
Just one concern here - pool currently has 'subnet' attribute which means
the subnet where members reside. More formally it means that loadbalancer
device should have a port on that subnet (Say in routed mode vip and pool
may be on different subnets and then device should have two ports on those
subnets)

If we keep the vip_id as an attribute of a pool (implying a pool can belong
> to only one vip), this isn't too bad--  you can duplicate the behavior by
> having multiple pools with the same actual member ips associated (though
> different member object instantiations, of course), and just make sure you
> update all of these "clone" pools whenever adding / removing members or
> changing healthmonitors, etc. It's certainly more housekeeping on the part
> of the application developer, though.
>
Right, it isn't a big deal.


> You mention in the notes that having the pools with a vip_id attribute
> solves a collocation problem. What is this specific collocation problem?
>
When making complex configurations with several pools (L7 rules usage) or
multiple VIPs (or Listeners) user may want to have this in a single
'logical configuration' for various reasons. One of the important reasons
is resource consumption: user may want to consume/pay for 1 backend, where
his configuration will be deployed. With existing API and workflow it's not
quite possible because 1) pool is the root object 2) pool is associated
with backend at the point when it is created.

If we go with #3, I would keep IP address as an attribute of the VIP in
> this model.
>
Yes, that makes sense. I'd say that we need port_id there, rather than ip.


> As far as not having a 'loadbalancer' entity: Again, I think we're going
> to need something like this when we solve the HA or horizontal scalability
> problem. If we're going to break workflows with the introduction of L7
> rules, then I would prefer to approach the model changes that will need to
> happen for HA and horizontal scalability sooner rather than later, so that
> we don't have to (potentially) contemplate yet another
> workflow-backward-compatibility model change.
>

That will need further clarification. So far we planned to introduce HA in
such way that user can't control it other then 'enable-disable', so
everything related to HA isn't really exposed to API. With approaches
either #2 or #3 HA is just a flag on the instance that indicates that it is
deployed in HA mode. Then driver does whatever it thinks HA is.
While HA may require additional DB objects, like additional
associations/bindings between logical config and backends, those objects
are not a part of public API.


> Could you please describe what is the 'provider/flavor' attribute of the
> VIP being proposed?
>
Currently we have a notion of 'provider' which is a user-facing
representation of 'driver', e.g. vendor-specific code that works after the
persistence layer and communicates with physical backend. Currently Pool,
as a root of configuration, has such attribute, so when any call is handled
for the pool or its child objects, that attribute is used to dispatch the
call to the appropriate driver.

Flavor is something more flexible (it's not there right now, we're working
on designing the framework), that would allow user to choose capabilities
rather then vendors. In particular, that will allow, having several
configurations for one driver.

As for the pictures - I have intentionally omitted some objects like L7
rules, ssl objects, health monitors since existing API around these object
makes sense and at this point we don't have plans to change it.

Regarding picture #4, could you describe once again in more details, what
is cluster and loadbalancer in this scheme?

>
> Thoughts?
>
> Thanks,
> Stephen
>


On Wed, Feb 19, 2014 at 6:28 AM, Stephen Balukoff wrote:

> Hi y'all!
>
> Eugene:  Are the arrows in your diagrams meaningful?
>
> Regarding existing wo

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

[Sumit Naiksatam]

Inline...


On Tue, Feb 18, 2014 at 10:33 AM, Mohammad Banikazemi  wrote:

> Thanks Sumit and Stephen for information provided.
>
> It appears to me that we can (and should) use the notion of
> services/service chains within the group policy extension (and that has
> been always one of our options). If this is a reasonable approach, then we
> need to see how we can bring in these services to our group policy and if
> there are changes we may require.
>
> Agreed. Our thinking was that the service instance, insertion context, and
the service chain are elemental abstractions on which the policy could be
layered upon.

> The first thing that comes to mind is to have a new service insertion
> context, namely policy (or should it be policy_rule?). If that is in place,
> then a service chain (we can start with a chain of one single service) gets
> created with it's context set to a particular policy.
>

The notion of a service insertion context is being introduced in this
patch:
https://review.openstack.org/#/c/62599/16/neutron/db/service_context.py

Although the service insertion context need not necessarily be aware of the
policy, I think the mapping is probably the other way around. The rendering
of the policy would lead to a particular service insertion context for that
service/chain.

While the service plugin is responsible for standing up the service, the
> connectivity is established through the implementation of the group policy
> extension, in particular the "redirect" action. Is this a reasonable
> approach?
>

Agreed.

> This approach requires some kind of coordination wrt how these operations
> are done by the service plugin and the group policy extension. May be a
> policy simply provides the insertion context for creation of the service
> chain (in isolation and by the appropriate service plugin) and policy rules
> are then used to make the service operational. This is different from how
> services are expected to be instantiated right now. Right? Thinking aloud
> here. Please comment.
>
> Agreed. That said, the two models/workflows can very nicely coexist. The
first one is using the elemental abstractions (service instances, chains,
etc) where the user needs to manage each of them individually to realize
the entire logical topology. The second option is where a group policy
plugin interprets the policy, and proceeds to render that policy using the
elemental abstractions (but might also perform the same directly on a
backend that supports the policy model).

> A lot of interesting things to work on. May be Juno is where all these
> efforts come to fruition together :)
>
> Totally. We have been incubating some of these ideas for a while now, and
hopefully its becoming more apparent as to why these constructs are
required in Neutron.



> Mohammad
>
> [image: Inactive hide details for Sumit Naiksatam ---02/17/2014 02:12:12
> AM---Thanks Mohammad for bringing this up. I responded in anot]Sumit
> Naiksatam ---02/17/2014 02:12:12 AM---Thanks Mohammad for bringing this up.
> I responded in another thread: http://lists.openstack.org/pipe
>
> From: Sumit Naiksatam 
> To: Mohammad Banikazemi/Watson/IBM@IBMUS,
> Cc: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 02/17/2014 02:12 AM
> Subject: Re: [openstack-dev] [neutron][policy] Using network services
> with network policies
> --
>
>
>
> Thanks Mohammad for bringing this up. I responded in another thread:
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/027306.html
>
> ~Sumit.
>
> On Sun, Feb 16, 2014 at 7:27 AM, Mohammad Banikazemi 
> wrote:
> > During the last IRC call we started talking about network services and
> how
> > they can be integrated into the group Policy framework.
> >
> > In particular, with the "redirect" action we need to think how we can
> > specify the network services we want to redirect the traffic to/from.
> There
> > has been a substantial work in the area of service chaining and service
> > insertion and in the last summit "advanced service" in VMs were
> discussed.
> > I think the first step for us is to find out the status of those efforts
> and
> > then see how we can use them. Here are a few questions that come to mind.
> > 1- What is the status of service chaining, service insertion and advanced
> > services work?
> > 2- How could we use a service chain? Would simply referring to it in the
> > action be enough? Are there considerations wrt creating a service chain
> > and/or a service VM for use with the Group Policy framework that need to
> be
> > taken into account?
> >
> > Let's start the discussion on the ML before taking it to the next call.
> >
> > Thanks,
> >
> > Mohammad
>
>
>
<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

[Aaron Rosen]

+1
On Feb 16, 2014 8:10 PM, "Armando M."  wrote:

> +1
> On Feb 13, 2014 5:52 PM, "Nachi Ueno"  wrote:
>
>> +1
>>
>> 2014年2月12日水曜日、Mayur Patilさんは書きました:
>>
>>> +1
>>>
>>> *--*
>>> *Cheers,*
>>> *Mayur*
>>>
>>
>> ___
>> 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] help with python-cinderclient unit test

[Chris Buccella]

On 02/18/2014 04:31 PM, Luis de Bethencourt wrote:



I am finishing a patch that Seif Lofty started. It shows more 
information for the quota-usage health.


https://review.openstack.org/gitweb?p=openstack%2Fpython-cinderclient.git;a=commitdiff;h=785cae3a17fbeccb366b01ece8f8704edf4d2ae7

I am not sure how the unit test for this should work.
I've tried to add...

def test_quota_usage_show(self):
self.run_command('quota-usage demo')

at the end of cinder/tests/v1/test_shell.py, and when running tox I get:

AssertionError: Called unknown API method: GET 
/os-quota-sets/demo?usage=True, expected fakes method name: 
get_os_quota_sets_demo


Any ideas or suggestions?




I haven't looked at this in detail, but here's a general suggestion:

The unit tests run independently from cinder. So you'll need to make 
sure that whatever changes were made on the server side are faked some 
way in the unit test suite. Look at the backtrace you received and 
you'll find cinderclient/tests/v1/fakes.py is where the call is failing. 
Start looking there.



-Chris (hdd)


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

Re: [openstack-dev] Glance v1 and v2

[Pete Zaitcev]

On Tue, 18 Feb 2014 10:57:03 +0100
Joe Hakim Rahme  wrote:

> Again, I have just spent a couple of days playing with it on a devstack. I'm 
> by
> no means a reference on the subject of the API v2. I hope this will help you 
> get
> a better idea of where it stands today.

Thanks a lot, it clears up some misconceptions on my part.
I noticed that glance CLI client was using v1, should've looked
at the source for --os-image-api, but I was sure we just postponed it.

> [1]: 
> http://docs.openstack.org/api/openstack-image-service/2.0/content/image-sharing.html

Thanks for the links too.

-- Pete

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

[openstack-dev] [oslo] Some questions about Rest API and log messages translation

[Peng Wu]

Hi,

  Currently I am analyzing the blueprint of translated message id
generation.[1]
  Recently I just found that there is an implementation to generate both
English and translated log messages.
  I think if English and translated log messages are provided, then we
don't need to generate a message id for log messages.

  My question is about Rest API messages translation. If we will return
both English and translated Rest API message, then we don't need to
generate a message id for Rest API message, either.

  And currently message id generation blueprint is only for log message
and translated Rest API message. If we provide both English and
translated messages, then we don't need to generate any message id for
messages. Because we just need to read the English log and Rest API
messages.

  Feel free to comment it.

Thanks,
  Peng Wu

Refer URL:
[1] https://blueprints.launchpad.net/oslo/+spec/log-messages-id
[2]
https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain



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

[openstack-dev] [third party testing] Article series on setting up an external CI system

[Jay Pipes]

Hi all,

There have been efforts recently by lots of folks, particularly in the
Nova, Neutron, and Cinder contributor communities, trying to set up a
third-party testing platform that can get notified by the upstream
OpenStack CI system, run tests, and post votes on code reviews upstream.

Partly in response to these efforts, and partly due to the
recently-announced Mirantis push to "open source" driver certification
procedures [1], I wrote a series of blog articles that describe both how
the upstream CI system works, as well as provide some instructions on
setting up an external CI system yourself in a (mostly) automated
fashion.

http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/

I hope that folks find these articles useful. Feedback, criticism, and
error corrections are very much welcomed. Please do let me know, either
on the ML or on blog comments, if there are specific things or examples
you would like me to cover further.

Best,
-jay

[1]
http://www.mirantis.com/blog/openstack-will-open-source-vendor-certifications/



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

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

[Jay Lau]

Thanks Liu Dong.

In case that you may not get my previous question, so here just post it
again to see if you can give a help.

Is it possible to bind MAC to a FLOATING IP?

Thanks,

Jay



2014-02-19 10:38 GMT+08:00 Dong Liu :

> yes, it does not worked via dashboard
>
> Dong Liu
>
> 于 2014-02-19 8:11, Jay Lau 写道:
>
>> Thanks Dong for the great help, it does worked with command line!
>>
>> This seems not available via dashboard, right?
>>
>> Thanks,
>>
>> Jay
>>
>>
>>
>> 2014-02-19 1:11 GMT+08:00 Dong Liu > >:
>>
>>
>> Hi Jay,
>>
>> In neutron API, you could create port with specified mac_address and
>> fix_ip, and then create vm with this port.
>> But the mapping of them need to manage by yourself.
>>
>>
>> 在 2014年2月18日，22:41，Jay Lau > > 写道：
>>
>>
>>  > Greetings,
>>  >
>>  > Not sure if it is suitable to ask this question in openstack-dev
>> list. Here come a question related to network and want to get some
>> input or comments from you experts.
>>  >
>>  > My case is as this: For some security issue, I want to put both
>> MAC and internal IP address to a pool and when create VM, I can get
>> MAC and its mapped IP address and assign the MAC and IP address to
>> the VM.
>>  >
>>  > For example, suppose I have following MAC and IP pool:
>>  > 1) 78:2b:cb:af:78:b0, 192.168.0.10
>>  > 2) 78:2b:cb:af:78:b1, 192.168.0.11
>>  > 3) 78:2b:cb:af:78:b2, 192.168.0.12
>>  > 4) 78:2b:cb:af:78:b3, 192.168.0.13
>>  >
>>  > Then I can create four VMs using above MAC and IP address, each
>> row in above can be mapped to a VM.
>>  >
>>  > Does any of you have any idea for the solution of this?
>>  >
>>  > --
>>  > Thanks,
>>  >
>>  > Jay
>>  > ___
>>  > OpenStack-dev mailing list
>>  > OpenStack-dev@lists.openstack.org
>> 
>>
>>  > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> Thanks,
>>
>> Jay
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,

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

Re: [openstack-dev] [solum] async / threading for python 2 and 3

[Georgy Okrokvertskhov]

Hi Angus,

I think that we need to keep python 2 as a lot of enterprise customers
still use python 2.x versions. If you target Solum only for python 3 users
you will significantly reduce potential customer adoption.

I would rather spend some time and research round option #3. I saw in
openstack-dev mailing list that there is a work around asyncio native in
py3 and its port for python2.

Here is related BP https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio

Here is the e-mail thread:
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026237.html

Thanks
Gosha


On Tue, Feb 18, 2014 at 4:53 PM, Angus Salkeld
wrote:

> Hi all
>
> I need to use some async / threaded behaviour to solum for image
> creation (all I need right now is to run a job asyncronously).
>
> eventlet is python 2 only
> tulip is python 3 only
> tornado (supports 2 + 3) http://www.tornadoweb.org
> twisted
> pyev
> etc...
>
> Options:
> 1) use eventlet and have the same path of migration as the rest
>of openstack. Basically give up python 3 for now.
> 2) use tulip and give up python 2
> 3) choose an existing framework that supports both py2+3
>
>
> Thoughts?
>
> Since we are starting out fresh, I'd suggest "2)".
> This will mean some learning, but that is always fun and would be benefical
> to other projects to see how this code looks.
>
> I am not sure how important support for python 2 is, I'd suggest
> supporting python 3 is more important.
>
> -Angus
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] help the oslo team help you

[黎林果]

+1
But if we don't sync the oslo, sometimes we have to modify the files
in openstack/common/ in order to run Jekins.

2014-02-19 10:03 GMT+08:00 Joe Gordon :
> On Wed, Feb 12, 2014 at 12:16 PM, Doug Hellmann
>  wrote:
>> If you have a change in your project that is blocked waiting for a patch to
>> land in oslo (in the incubator, or any of the libraries we manage) *please*
>> either open a blueprint or mark the associated bug as also affecting the
>> relevant oslo project, then let me know about it so I can put it on our
>> review priority list. We have a lot going on in oslo right now, but will do
>> our best to prioritize reviews that affect features landing in other
>> projects -- if you let us know about them.
>
>
> While I don't think this is what you meant when you said let oslo help
> you, I do have a request:
>
> While trying to do a basic oslo-incubator update ('./update.sh
> --nodeps --modules fixture --base nova --dest-dir ../nova')  I hit a
> bug https://bugs.launchpad.net/oslo/+bug/1281860
>
> Due to the nature of oslo-incubator (it may break at any time) it is
> hard for downstream projects (nova, cinder etc.) to keep there
> oslo-incubator copies up to date, so when someone wants to sync across
> a new change they have to deal with many unrelated changes, some of
> which may break things. For example
>
> oslo-incubator$ ./update.sh --config-file
> ../cinder/openstack-common.conf --base cinder --dest-dir ../cinder
> cinder$ git diff --stat HEAD
> 52 files changed, 3568 insertions(+), 961 deletions(-)
>
>
> I would like to propose making the oslo team responsible for syncing
> across oslo-incubator code, they know the code base best and can fix
> things when they break.  This doesn't mean no one else can use
> update.sh it just means that the oslo team would make sure that syncs
> are done in a timely fashion, so the diffs don't get too big.
>
>>
>> Doug
>>
>>
>> ___
>> 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] Change in openstack-dev/devstack[master]: Remove limitation to 12.04 release because the problematic 1...

[Mike Spreitzer]

"Dean Troyer (Code Review)"  wrote on 02/18/2014 
05:53:03 PM:

> I'm curious why we haven't seen this before now?  I've run on bare 
> raring and saucy systems a number of times...need to try again I 
suppose...

Yes, I have previously done lots of DevStack installs on post-precise 
releases of Ubuntu without seeing this problem.  This problem could have 
arisen now either because something gained a dependency or something else 
stopped requiring cmd2.  There is no automated comprehensive way of doing 
this sort of analysis, right?

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

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

[Dong Liu]

yes, it does not worked via dashboard

Dong Liu

于 2014-02-19 8:11, Jay Lau 写道:

Thanks Dong for the great help, it does worked with command line!

This seems not available via dashboard, right?

Thanks,

Jay



2014-02-19 1:11 GMT+08:00 Dong Liu mailto:willowd...@gmail.com>>:

Hi Jay,

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


在 2014年2月18日，22:41，Jay Lau mailto:jay.lau@gmail.com>> 写道：

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

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


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

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




--
Thanks,

Jay


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




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

Re: [openstack-dev] help the oslo team help you

[Joe Gordon]

On Wed, Feb 12, 2014 at 12:16 PM, Doug Hellmann
 wrote:
> If you have a change in your project that is blocked waiting for a patch to
> land in oslo (in the incubator, or any of the libraries we manage) *please*
> either open a blueprint or mark the associated bug as also affecting the
> relevant oslo project, then let me know about it so I can put it on our
> review priority list. We have a lot going on in oslo right now, but will do
> our best to prioritize reviews that affect features landing in other
> projects -- if you let us know about them.


While I don't think this is what you meant when you said let oslo help
you, I do have a request:

While trying to do a basic oslo-incubator update ('./update.sh
--nodeps --modules fixture --base nova --dest-dir ../nova')  I hit a
bug https://bugs.launchpad.net/oslo/+bug/1281860

Due to the nature of oslo-incubator (it may break at any time) it is
hard for downstream projects (nova, cinder etc.) to keep there
oslo-incubator copies up to date, so when someone wants to sync across
a new change they have to deal with many unrelated changes, some of
which may break things. For example

oslo-incubator$ ./update.sh --config-file
../cinder/openstack-common.conf --base cinder --dest-dir ../cinder
cinder$ git diff --stat HEAD
52 files changed, 3568 insertions(+), 961 deletions(-)


I would like to propose making the oslo team responsible for syncing
across oslo-incubator code, they know the code base best and can fix
things when they break.  This doesn't mean no one else can use
update.sh it just means that the oslo team would make sure that syncs
are done in a timely fashion, so the diffs don't get too big.

>
> Doug
>
>
> ___
> 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] Proposal for model change - Loadbalancer Instance feedback

[Stephen Balukoff]

Hi Eugene,

First, thanks again for your speedy response and entertaining my ideas, eh!
And I apologize that it took me a few days to get back to you on this.

My thoughts are inline below:


On Thu, Feb 13, 2014 at 4:07 AM, Eugene Nikanorov
wrote:

>
>> I've been reading through the LoadBalancerInsance description as outlined
>> here and have some feedback:
>> https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance
>>
>> First off, I agree that we need a container object and that the pool
>> shouldn't be the object root. This container object is going to have some
>> attributes associated with it which then will apply to all related objects
>> further down on the chain.  (I'm thinking, for example, that it may make
>> sense for the loadbalancer to have 'network_id' as an attribute, and the
>> associated VIPs, pools, etc. will inherit this from the container object.)
>>
>
> Particularly, network_id could be different for vip and a pool in case the
> balancer works in routed mode (e.g. connects to different networks)
>

For VIP and pool subnets in routed mode, would these be associated with a
neutron network? (It occurs to me that layer-3 routing means subnets in
this category won't be associated with a "connected" layer-2 network, so
much as a layer-3 routing rule, which sends all traffic destined for said
subnets ultimately to some address on a layer-2 "connected" subnet.)  I'm
unfamiliar with how this is supposed to work with Neutron.

Also, do "pools" really need a network_id?  (Wouldn't it be valid for the
pool's members to come from several different networks, so long as the load
balancer has a way (route, NAT, etc.) to communicate with them?)
 (Practically speaking, we almost never see this--  but there's no
technical reason it couldn't be done.)


> One thing that was not clear to me just yet:  Is the 'loadbalancer' object
>> meant, at least eventually, to be associated with an actual load balancer
>> device of some kind (be that the neutron node with haproxy, a vendor
>> appliance or a software appliance)?
>>
>
> Yes, that is one of the proposed roles of 'loadbalancer' object. But not
> the only. Appliance is not the only representation of the balancer that we
> are working with, it could also be a process on the host that is controlled
> by the agent. So other types of associations also are necessary (like
> association between the agent and the 'loadbalancer')
>
>
Yes, of course the local haproxy instance would fall under the same model--
but what I mean by this is that a 'loadbalancer' is meant to ultimately be
associated with a "device" of some kind, even if that device is the special
case of an haproxy instance running on the neutron network node.


>
>> If not, then I think we should use a name other than 'Loadbalancer' so we
>> don't confuse people. I realize I might just be harping on one of the two
>> truly difficult problems in software engineering (which are: Naming things,
>> cache invalidation, and off-by-one errors). But if a 'loadbalancer' object
>> isn't meant to actually be synonymous with a load balancer appliance of
>> some kind, the object needs a new name.
>>
>
> I don't mind to have other name like 'instance', for example. But
> appliance (would it be a device or a process+agent) is really a synonym of
> what I am proposing.
>
>
>> If the object and the device are meant to essentially be synonymous, then
>> I think we're starting off too simplistic here, and the model proposed is
>> going to need another significant revision when we add additional features
>> later on.  I suspect we'll be painting ourselves into a corner with the
>> LoadBalancerInstance as proposed. Specifically, I'm thinking about:
>>
>>
>>- Operational concerns around the life cycle of a physical piece of
>>infrastructure. If we're going to replace a physical load balancer, it
>>often makes sense to have both the old and new load balancer defined in 
>> the
>>system at the same time during the transition. If you then swap all the
>>VIPs from the old to the new, suddenly all the child objects have their
>>loadbalancer_id changed, which will often wreak havoc on client 
>> application
>>code (who really shouldn't be hard-coding things like loadbalancer_id, but
>>will do so anyway. :P ) Such transitions are much easier accomplished if
>>both load balancers can exist within an overarching container object (ie.
>>"cluster" in my proposal) which will never need to be swapped out.
>>
>> I'd like to understand that better. I guess no model is complex enough to
> describe each end every use case. What I'm trying to address with the lb
> instance is both simplistic cases that are only supported by the current
> code plus some more complex configurations like multiple pools (L7) and
> multiple vips. And at the same time we need to consider backward
> compatibility and plus we need to make some progress. The bigger is the
> change, the harder it is to make a progress. S

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

[Richard Woo]

Hello, Swami,

Would you mind to forward the powerpoint slide link again?

Thanks,
Richard


On Tue, Feb 18, 2014 at 1:03 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hp.com> wrote:

> Hi Assaf,
> Thanks for letting me know.
> This document was completely open and accessible by everyone till last
> week.
> Someone might have changed the settings on this document.
>
> I don't remember that I changed any settings on this document.
> The Powerpoint slides link that I forwarded yesterday also captures the
> same details and still that is accessible.
>
> I have opened it again for the public.
>
> If it would have caused any trouble for you to participate in the upstream
> discussions for the last two days, I feel sorry for it.
>
> Feel free to send an email to me, if you have any other issues or concerns.
>
> Thanks
> Swami
>
> -Original Message-
> From: Assaf Muller [mailto:amul...@redhat.com]
> Sent: Tuesday, February 18, 2014 2:33 AM
> To: openstack-dev@lists.openstack.org
> Cc: Vasudevan, Swaminathan (PNB Roseville); Baldwin, Carl (HPCS Neutron);
> mmccl...@yahoo-inc.com; Livnat Peer; Sylvain Afchain
> Subject: [Neutron] DVR blueprint document locked / private
>
> Regarding the DVR blueprint [1], I noticed that its corresponding Google
> Doc [2] has been private / blocked for nearly a week now. It's very
> difficult to participate in upstream design discussions when the document
> is literally locked.
>
> I would appreciate the re-opening of the document, especially considering
> the recent face to face meeting and the contested discussion points that
> were raised.
>
> [1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
> [2]
> https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit
>
>
> Thank you,
> Assaf Muller, Cloud Networking Engineer Red Hat
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] VPC Proposal

[Rudra Rugge]

Please see inline:

On Feb 18, 2014, at 2:57 PM, Martin, JC  wrote:

> Maybe I should explain this one a bit.
> 
> Shared network: If a user has defined a shared network, and they used your 
> API to create a VPC, the instances within the VPC will automatically get an 
> interface on the shared network. I don't think that this is the expected 
> behavior
> 

When a user launches a VM in a VPC (AWS) the user needs to specify a subnet 
(network in openstack terminology) for each of the interfaces. Hence the 
instances will only get interfaces on the passed subnets/networks. The network 
being shared or not is not relevant for the VM launch. AWS APIs need the 
subnet/network to be passed for a VM launch in VPC.


> FIP in scope of VPC: I was not talking about the EIP for Internet access, 
> sorry if it was confusing. Since you are not really describing how you create 
> the external networks, it's not clear how you implement the multiple gateways 
> (public and private) that AWS supports, and how you connects networks to 
> routers and external networks. i.e. are the CIDRs used in the VPC, NAT'ED to 
> be routed in the customer datacenter, in which case, there is a floating IP 
> pool that is private to each private gateway and VPC (not the 'public' one).

Gateways are built using Openstack neutron router resource. Networks are 
connected to the router interfaces. For internet access cloud administrator 
needs to provision a floating IP pool for the router to use. For CIDRs used in 
the VPC we need to implement a route-table extension which holds the prefix 
list. The prefix-list or route-table is attached to a 
subnet(AWS)/network(Openstack).  All internal(private) routing is managed by 
the Openstack router. NAT and VPN are used as next-hops to exit the VPC. In 
these cases similar to AWS we need to launch NAT and VPN capable instances as 
supported by Openstack FWAAS and VPNAAS. 

> 
> It would be useful for you to describe the pre-setup required to do make this 
> works.

The only pre-setup needed by the cloud admin is to provide a public pool for 
floating IP. 

Rudra

> 
> 
> JC
> 
> 
> On Feb 18, 2014, at 1:09 PM, Harshad Nakil  wrote:
> 
>> 2. It does give full AWS compatibility (except for network ACL which was 
>> differed). Shared networks, FIP within scope of VPC is not some thing AWS 
>> provides. So it is not partial support.
> 
> 
> ___
> 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] [solum] async / threading for python 2 and 3

[Angus Salkeld]

Hi all

I need to use some async / threaded behaviour to solum for image
creation (all I need right now is to run a job asyncronously).

eventlet is python 2 only
tulip is python 3 only
tornado (supports 2 + 3) http://www.tornadoweb.org
twisted
pyev
etc...

Options:
1) use eventlet and have the same path of migration as the rest
   of openstack. Basically give up python 3 for now.
2) use tulip and give up python 2
3) choose an existing framework that supports both py2+3


Thoughts?

Since we are starting out fresh, I'd suggest "2)".
This will mean some learning, but that is always fun and would be benefical
to other projects to see how this code looks.

I am not sure how important support for python 2 is, I'd suggest
supporting python 3 is more important.

-Angus


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

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

[Jay Lau]

Also thanks Tim and Amir for the input here.

Just one more question and hope can also get some help from you ;-)

I have tried that we can create VM with MAC and FIXED IP bind together,
what about floating IP? Is it possible that I also bind MAC and FLOATING IP
for a VM?

===MAC and FIXED IP BIND===
[root@db01b05 ~(keystone_admin)]# neutron net-list
+--+--+---+
| id   | name |
subnets   |
+--+--+---+
| 489e5aac-aedb-4d94-b908-fc8079dee25c | Int  |
f307d9fd-2444-4ad0-b21a-9f490b182cbb 10.0.0.0/24  |
| 9b758062-2be8-4244-a5a9-3f878f74e006 | Ex   |
b76e9845-8ee1-4794-ae81-4514ce18b428 9.21.52.0/24 |
| fb1a75f9-e468-408b-a172-5d2b3802d862 | IntAdmin |
0fff20f4-142a-4e89-add1-5c5a79c6d54d 10.0.1.0/24  |
+--+--+---+
[root@db01b05 ~(keystone_admin)]# neutron subnet-list
+--+-+--+--+
| id   | name| cidr |
allocation_pools |
+--+-+--+--+
| 0fff20f4-142a-4e89-add1-5c5a79c6d54d | SubIntAdmin | 10.0.1.0/24  |
{"start": "10.0.1.2", "end": "10.0.1.254"}   |
| b76e9845-8ee1-4794-ae81-4514ce18b428 | SubEx   | 9.21.52.0/24 |
{"start": "9.21.52.20", "end": "9.21.52.30"} |
| f307d9fd-2444-4ad0-b21a-9f490b182cbb | SubInt  | 10.0.0.0/24  |
{"start": "10.0.0.3", "end": "10.0.0.254"}   |
|  | |  |
{"start": "10.0.0.1", "end": "10.0.0.1"} |
+--+-+--+--+
[root@db01b05 ~(keystone_admin)]# neutron port-create IntAdmin
--mac-address fa:16:3e:9d:e9:11 --fixed-ip ip_address=10.0.1.2
Created a new port:
+---+-+
| Field |
Value
|
+---+-+
| admin_state_up|
True
|
| allowed_address_pairs
|
|
| binding:capabilities  | {"port_filter":
true}   |
| binding:host_id
|
|
| binding:vif_type  |
ovs
|
| device_id
|
|
| device_owner
|
|
| fixed_ips | {"subnet_id":
"0fff20f4-142a-4e89-add1-5c5a79c6d54d", "ip_address": "10.0.1.2"} |
| id|
75a4eca1-1edf-415e-9bce-34a228145110
|
| mac_address   |
fa:16:3e:9d:e9:11
|
| name
|
|
| network_id|
fb1a75f9-e468-408b-a172-5d2b3802d862
|
| security_groups   |
aa3f3025-ba71-476d-a126-25a9e3b34c9a
|
| status|
DOWN
|
| tenant_id |
f181a9c2b1b4443dbd91b1b7de716185
|
+---+-+
[root@db01b05 ~(keystone_admin)]# neutron port-list | grep 10.0.1.2
| 75a4eca1-1edf-415e-9bce-34a228145110 |  | fa:16:3e:9d:e9:11 |
{"subnet_id": "0fff20f4-142a-4e89-add1-5c5a79c6d54d", "ip_address":
"10.0.1.2"}   |
[root@db01b05 ~(keystone_admin)]# nova boot --image
centos64-x86_64-cfntools --flavor 2 --key-name adminkey --nic
port-id=75a4eca1-1edf-415e-9bce-34a228145110 vm0001
+--+--+
| Property |
Value|
+--+--+
| OS-EXT-STS:task_state|
scheduling   |
| image|
centos64-x86_64-cfntools |
| OS-EXT-STS:vm_state  |
building |
| OS-EXT-SRV-ATTR:instance_name|
instance-0023|
| OS-SRV-USG:launched_at   |
None |
| flavor   |
m1.small |
| id   |
9af14d06-6fa8-4757-8eb7-118ea01d3fdb |
| security_groups  | [{u'name':
u'default'}]  |
| user_id  |
345dd87da2364fa78ffe97ed349bb71b |
| OS-DCF:diskConfig|
MANUAL   |
| accessIPv4
|  |
| accessIPv6
|  |
| progress |
0|
| OS-EXT-STS:power_state   |
0

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

[Angus Salkeld]

On 18/02/14 14:19 +, Shaunak Kashyap wrote:

Thanks Angus and Devdatta. I think I understand.

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


Just to be clear, I am not totally sure we are going to glue git repo
generation to create plan (it *could* be part of create assembly).



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


If you are not using the git-push mechanism, but the git-pull.
Here you have your own repo (say on github) and there is not
a git-repo-generation phase.

-Angus



Thanks,

Shaunak


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

On 17/02/14 21:47 +, Shaunak Kashyap wrote:

Hey folks,

I was reading through 
https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/CLI-minimal-implementation
 and have a question.

If I’m understanding “app create” and “assembly create” correctly, the user 
will have to run “app create” first, followed by “assembly create” to have a 
running application. Is this correct? If so, what is the reason for “app 
create” not automatically creating one assembly as well?


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

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

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

Adrian might want to correct my here tho'

-Angus



Thanks,
Shaunak



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



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

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


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

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

[Jay Lau]

Thanks Dong for the great help, it does worked with command line!

This seems not available via dashboard, right?

Thanks,

Jay



2014-02-19 1:11 GMT+08:00 Dong Liu :

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



-- 
Thanks,

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

Re: [openstack-dev] VPC Proposal

[Martin, JC]

Maybe I should explain this one a bit.

Shared network: If a user has defined a shared network, and they used your API 
to create a VPC, the instances within the VPC will automatically get an 
interface on the shared network. I don't think that this is the expected 
behavior

FIP in scope of VPC: I was not talking about the EIP for Internet access, sorry 
if it was confusing. Since you are not really describing how you create the 
external networks, it's not clear how you implement the multiple gateways 
(public and private) that AWS supports, and how you connects networks to 
routers and external networks. i.e. are the CIDRs used in the VPC, NAT'ED to be 
routed in the customer datacenter, in which case, there is a floating IP pool 
that is private to each private gateway and VPC (not the 'public' one).

It would be useful for you to describe the pre-setup required to do make this 
works.


JC


On Feb 18, 2014, at 1:09 PM, Harshad Nakil  wrote:

> 2. It does give full AWS compatibility (except for network ACL which was 
> differed). Shared networks, FIP within scope of VPC is not some thing AWS 
> provides. So it is not partial support.


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

Re: [openstack-dev] VPC Proposal

[Joe Gordon]

On Tue, Feb 18, 2014 at 1:01 PM, Martin, JC  wrote:
> Joe,
>
> See my comments in line.
>
> On Feb 18, 2014, at 12:26 PM, Joe Gordon  wrote:
>
>> On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC  wrote:
>>> There was a lot of emails on that thread, but I am not seeing the 
>>> discussion converging. I would like to reiterate my concerns:
>>>
>>>   - We are trying to implement an API on a feature that is not supported by 
>>> openstack
>>
>> I don't see it that way. I see this BP as converting neutron calls
>> into AWS VPC calls with a little glue (which can be seen here
>> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support). But I am
>> no networking expert, so take that with a large grain of salt.
>
> If we had the supporting constructs, I would be in favor of implementing the 
> AWS VPC features.
>
>>
>>>   - As a result, the implementation is overloading existing construct 
>>> without implementing full AWS capabilities and semantic (e.g. Shared 
>>> network isolation from VPC, or Floating IP scoping to VPC).
>>
>> A partial implementation is better then no implementation, that being
>> said if we want to overhaul OpenStack's VPC capabilities I think the
>> partial implementation would have to be thrown out.
> I agree too. However, given the choice, I would have preferred that we first 
> augment the neutron network access and sharing model before the building the 
> API. It stills qualify as partial implementation, but at least in the right 
> order.
>
>>
>>>   - Dependent blueprints are not implemented and have been deferred, 
>>> resulting in the broken implementation (e.g. 
>>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron)
>>
>> That is a requirement for phase 3, and shouldn't matter for phase 1
>> and 2. And only phase 1 is up for review.
> My point is that it does matter a it gives users the feeling that they get 
> parity in term of isolation but they are not because of the missing isolation 
> and sharing constructs.
>
>>
>>>   - this "feature" is only available through EC2 API, which is likely going 
>>> to result in another implementation for general use.
>>>   - users adopting the VPC model proposed through EC2 API will be stuck in 
>>> an upgrade mess when the proper implementation comes along.
>>
>> This point concerns me the most, can you elaborate.
>
> First, while AWS does not support projects they do support, trough IAM, very 
> flexible policies for VPC resources access, see
> http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html
> If we wanted to reproduce this in openstack, we could map this to levels in 
> the multi tenant hierarchy that Vish is proposing.
> However, because this project put all the resources in the same VPC project, 
> it's not possible anymore to implement the access policies without moving 
> resources between projects or recreating the VPC.

Thanks for the clarification.

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

agreed.

>
> JC
> ___
> 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] [Openstack-dev] [neutron] [ml2] Neutron and ML2 - adding new network type

[Sławek Kapłoński]

Hello,

Thanks for an answear.
I want to add own network type which will be very similiar to flat network (in 
type_driver I think it will be the same) but will assign IPs to instances in 
different way (not exactly with some L2 protocol). I want to add own network 
because I want to have own name of this network that I can distinguish it.
Maybe there is other reason to do that.

--
Best regards
Sławek Kapłoński

Dnia wtorek, 18 lutego 2014 10:08:50 piszesz:
> [Moving to -dev list]
> 
> On Feb 18, 2014, at 9:12 AM, Sławek Kapłoński  wrote:
> > Hello,
> > 
> > I'm trying to make something with neutron and ML2 plugin. Now I need to
> > add my own external network type (as there are "Flat", "VLAN", "GRE" and
> > so on). I searched for manuals for that but I can't found anything. Can
> > someone of You explain me how I should do that? Is it enough to add own
> > type_driver and mechanism_driver to ML2? Or I should do something else
> > also?
> Hi Sławek:
> 
> Can you explain more about what you’re looking to achieve here? I’m just
> curious how the existing TypeDrivers won’t cover your use case. ML2 was
> designed to remove segmentation management from the MechanismDrivers
> so they could all share segment types. Perhaps understanding what you’re
> trying to achieve would help better understand the approach to take here.
> 
> Thanks,
> Kyle
> 
> > Thanks in advance
> > --
> > Sławek Kapłoński
> > sla...@kaplonski.pl
> > 
> > ___
> > Mailing list:
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openst...@lists.openstack.org
> > Unsubscribe :
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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

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

[Sylvain Bauza]

Hi Don,



2014-02-18 21:28 GMT+01:00 Dugger, Donald D :

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

That's the main reason why I was unable to attend the previous scheduler
meetings...
Now that I attended this today meeting, that's quite clear to me. I
apologize for this misunderstanding, but as I can't dedicate all my time on
Gantt/Nova, I have to make sure the time I'm taking on it can be worth it.

Now that we agreed on a plan for next steps, I think it's important to put
the infos on Gantt blueprints, even if most of the changes are related to
Nova. The current etherpad is huge, and frightening people who would want
to contribute IMHO.



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

Agreed. I'm just thinking on the opportunity of providing a REST API on top
of the scheduler RPC API with a 1:1 matching, so that the Gantt project
would step up by itself. I don't think it's a hard stuff, provided I
already did that stuff for Climate (providing Pecan/WSME API). What do you
think about it ? Even if it's not top priority, that's a quickwin.

-Sylvain

 --
>
> Don Dugger
>
> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>
> Ph: 303/443-3786
>
>
>
> *From:* Sylvain Bauza [mailto:sylvain.ba...@gmail.com]
> *Sent:* Monday, February 17, 2014 4:26 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Nova] Meetup Summary
>
>
>
> Hi Russell and Don,
>
>
>
> 2014-02-17 23:41 GMT+01:00 Russell Bryant :
>
> Greetings,
>
>
> 2) Gantt  - We discussed the progress of the Gantt effort.  After
> discussing the problems encountered so far and the other scheduler work
> going on, the consensus was that we really need to focus on decoupling
> the scheduler from the rest of Nova while it's still in the Nova tree.
>
> Don was still interested in working on the existing gantt tree to learn
> what he can about the coupling of the scheduler to the rest of Nova.
> Nobody had a problem with that, but it doesn't sound like we'll be ready
> to regenerate the gantt tree to be the "real" gantt tree soon.  We
> probably need another cycle of development before it will be ready.
>
> As a follow-up to this, I wonder if we should rename the current gantt
> repository from openstack/gantt to stackforge/gantt to avoid any
> possible confusion.  We should make it clear that we don't expect the
> current repo to be used yet.
>
>
>
> There is currently no precise meeting timeslot for Gantt but the one with
> Nova scheduler subteam. Would it be possible to have a status on the
> current path for Gantt so that people interested in joining the effort
> would be able to get in ?
>
>
>
> There is currently a discussion on how Gantt and Nova should interact, in
> particular regarding HostState and how Nova Computes could update their
> status so as Gantt would be able to filter on them. There are also other
> discussions about testing, API, etc. so I'm just wondering how to help and
> where.
>
>
>
> On a side note, if Gantt is becoming a Stackforge project planning to have
> Nova scheduling first, could we also assume that we could also implement
> this service for being used by other projects (such as Climate) in parallel
> with Nova ?
>
> The current utilization-aware-scheduling blueprint is nearly done so that
> it can be used for other queries than just Nova scheduling, but
> unfortunately as the scheduler is still part of Nova and without a REST
> API, it can't be leveraged on third-party projects.
>
>
>
>
>
> Thanks,
>
> -Sylvain
>
>
>
> [1] :
> https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] help with python-cinderclient unit test

[Luis de Bethencourt]

Hi,

I am finishing a patch that Seif Lofty started. It shows more information
for the quota-usage health.

https://review.openstack.org/gitweb?p=openstack%2Fpython-cinderclient.git;a=commitdiff;h=785cae3a17fbeccb366b01ece8f8704edf4d2ae7

I am not sure how the unit test for this should work.
I've tried to add...

def test_quota_usage_show(self):
self.run_command('quota-usage demo')

at the end of cinder/tests/v1/test_shell.py, and when running tox I get:

AssertionError: Called unknown API method: GET
/os-quota-sets/demo?usage=True, expected fakes method name:
get_os_quota_sets_demo

Any ideas or suggestions?

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

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

[Bob Ball]

> From: Russell Bryant [rbry...@redhat.com]
> Sent: 17 February 2014 22:41
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Nova] Meetup Summary
> 
> 5) Driver CI - We talked about the ongoing effort to set up CI for all
> of the compute drivers.  The discussion was mostly a status review.  At
> this point, the Xenserver and Docker drivers are both at risk of being
> removed from Nova for the Icehouse release if CI is not up and running
> in time.

Just a quick update on this - the Citrix CI is up and running and commenting on 
jobs that pass full tempest using XenServer 6.2 with the XenAPI Driver.
We are not currently commenting on jobs that fail as I think there are some 
false negatives we need to iron out - or convince ourselves they are the same 
as the bugs that are hitting the official gate - over the next few days.  The 
CI is currently working through a backlog of jobs, but it's running tests 
against nova, devstack and tempest.

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

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

[Amir Sadoughi]

Hi all,

In Rackspace's quark plugin (github.com/rackerlabs/quark), we’ve developed an 
extension for MAC address ranges (MARs) as a top-level resource. Thus, the 
Neutron service manages the MAC address allocation from a pool of ranges (as 
opposed to randomly generating a MAC address). However, we haven’t made a 
relationship between MARs and subnets/networks.

Amir


On Feb 18, 2014, at 11:24 AM, Tim Bell  wrote:

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


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

Re: [openstack-dev] [TripleO] mid-cycle meetup?

[James Slagle]

On Fri, Jan 31, 2014 at 4:42 AM, Robert Collins
 wrote:
> Ok location:
> HP's office in Sunnyvale. Dates:  Monday 3rd March through friday 7th March.
>
> All welcome, please RSVP to me cc cody.somerville at hp.com so that we
> can arrange a suitable sized room @ the venue.
>
> I figure we'll do a everyone-together dinner on tuesday night, but the
> rest of the time dinner will be your own problem :). We'll figure
> something out for lunches everyday - the office is in the middle of
> nothing, so we won't be popping out, but there is a great cafe in the
> building, or we might get catering in the meeting room.
>
> Cheers,
> Rob
>
> On 24 January 2014 08:47, Robert Collins  wrote:
>> Hi, sorry for proposing this at *cough* the mid-way point [christmas
>> shutdown got in the way of internal acks...], but who would come if
>> there was a mid-cycle meetup? I'm thinking the HP sunnyvale office as
>> a venue.


Hi, I started an etherpad to track some logistics:
https://etherpad.openstack.org/p/tripleo-icehouse-sprint

It's a bit sparse at the moment while some details are still being
worked out.  If you know you're coming, feel free to add yourself to
the etherpad if you'd like.

-- 
-- James Slagle
--

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

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

[Martin, JC]

Vish,

See comments below.

JC
On Feb 18, 2014, at 12:19 PM, Vishvananda Ishaya  wrote:

> 
> On Feb 18, 2014, at 11:31 AM, Martin, JC  wrote:
> 
>> 
>> I see a lot of good things happening on the hierarchical multi tenancy 
>> proposal that Vish made a while back.
>> 
>> However, the focus so far is on roles and quota but could not find any 
>> discussion related to resource ownership.
>> 
>> Is the plan to allow the creation of resources within any level of the 
>> hierarchy or is the plan to allow the visibility of the resources up to a 
>> level in the hierarchy ? or both ?
>> 
>> For example, if I have :
>> - orga.vpca.projecta
>> - orga.vpca.projectb
>> 
>> and I want to share a resource like a network between projecta and projectb, 
>> should the network be owned by vpca or should it be owned by projecta or 
>> projectb, or a vpca.admin project and then shared to all children of vpca ?
>> 
>> I think either would work, and both maybe required.
>> 
>> Opinions ?
> 
> We haven’t discussed inheriting ownership of objects but at first glance it 
> seems confusing: how would one determine if an object in vcpa is “shared” and 
> visible to projects below, and if it is how far down the hierarchy would it 
> be visible? It is probably best to keep this explicit for the moment.
> 
> I’ve been thinking of sharing as objects that appear at multiple places in 
> the hierarchy. This could be a list of “owners” or “shares”, but I think it 
> would support either of your options. My initial thoughts would be to just 
> put the network resource in orga.vcpa and then share it to the projects. This 
> of course gets a little tedious when other projects are added later, but it 
> avoids the complications i mentioned above.


The way it would work is that when one is, for example, is creating a network 
with a 'shared' semantic (in a leaf project for example), the call would have 
to be extended with a scope (for backward compatibility, no scope would mean 
all/domain).

e.g. 
neutron net-create --shared:orga.vpca vpca-shared-net
instead of just
neutron net-create --shared orga-shared-net

another option is to implement the same policy mechanism that AWS has to allow 
the definition of scope based on rules.
see http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html


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

Re: [openstack-dev] VPC Proposal

[Harshad Nakil]

1. Feature is giving AWS VPC api compatibility with existing openstack
structure
2. It does give full AWS compatibility (except for network ACL which was
differed). Shared networks, FIP within scope of VPC is not some thing AWS
provides. So it is not partial support.
3. IMO it would not be major change to go from what we are proposing to
what JC is proposing as far as AWS VPC API(s) are concerned.
4. I can understand developers not liking AWS API(s) but many users of
openstack will benefit
5. Multi tenant hierarchy and domains won't effect AWS API(s) in any way

IMO there no need to differ this blueprint.



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

> There was a lot of emails on that thread, but I am not seeing the
> discussion converging. I would like to reiterate my concerns:
>
>- We are trying to implement an API on a feature that is not supported
> by openstack
>- As a result, the implementation is overloading existing construct
> without implementing full AWS capabilities and semantic (e.g. Shared
> network isolation from VPC, or Floating IP scoping to VPC).
>- Dependent blueprints are not implemented and have been deferred,
> resulting in the broken implementation (e.g.
> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
> )
>- this "feature" is only available through EC2 API, which is likely
> going to result in another implementation for general use.
>- users adopting the VPC model proposed through EC2 API will be stuck
> in an upgrade mess when the proper implementation comes along.
>- There are new constructs in work that are better suited for
> implementing this concept properly (Multi tenant hierarchy and domains).
>
> As you can guess, I'm not really a fan, but it seems that only few
> individuals are concerned. I would think that this topic would create more
> interest, specially on the network side. Maybe because of the subject tags.
> I will therefore copy this email with the Neutron tag.
>
> JC
>
> On Feb 17, 2014, at 10:10 PM, Rudra Rugge  wrote:
>
> > I am not sure on how to dig out the archives. There were a couple of
> > emails exchanged with Salvatore on the thread pertaining to the
> extensions
> > we were referring to as part of this blueprint.
> >
> > There are a few notes on the whiteboard of the blueprint as well.
> >
> > Regards,
> > Rudra
> >
> >
> > On 2/17/14, 1:28 PM, "jc Martin"  wrote:
> >
> >> Thanks,
> >>
> >> Do you have the links for the discussions ?
> >>
> >> Thanks,
> >>
> >> JC
> >>
> >> Sent from my iPhone
> >>
> >>> On Feb 17, 2014, at 11:29 AM, Rudra Rugge  wrote:
> >>>
> >>> JC,
> >>>
> >>> BP has been updated with the correct links. I have removed the
> abandoned
> >>> review #3.
> >>> Please review #1 and #2.
> >>>
> >>> 1. https://review.openstack.org/#/c/40071/
> >>>
> >>>  This is the active review.
> >>>  There is one comment by Sean regarding
> >>>  adding a knob when Neutron is not used.
> >>>  That will be addressed with the next path.
> >>> 2. https://review.openstack.org/#/c/53171
> >>>  This is the active review for tempest
> >>>  test cases as requested by Joe Gordon.
> >>>  Currently abandoned until #1 goes through.
> >>> 3. https://review.openstack.org/#/c/53171
> >>>  This review is not active. It was accidentally submitted with a new
> >>> change-id.
> >>>
> >>> Regards,
> >>> Rudra
> >>>
>  On 2/16/14, 9:25 AM, "Martin, JC"  wrote:
> 
>  Harshad,
> 
>  I tried to find some discussion around this blueprint.
>  Could you provide us with some notes or threads  ?
> 
>  Also, about the code review you mention. which one are you talking
>  about :
>  https://review.openstack.org/#/c/40071/
>  https://review.openstack.org/#/c/49470/
>  https://review.openstack.org/#/c/53171
> 
>  because they are all abandoned.
> 
>  Could you point me to the code, and update the BP because it seems
> that
>  the links are not correct.
> 
>  Thanks,
> 
>  JC
> > On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu" 
> > wrote:
> >
> > Harshad,
> >
> > Thanks for clarifying.
> >
> >> We started looking at this as some our customers/partners were
> >> interested in get AWS API compatibility. We have this blueprint and
> >> code review pending for long time now. We will know based on this
> >> thread wether the community is interested. But I assumed that
> >> community
> >> was interested as the blueprint was approved and code review has no
> >> -1(s) for long time now.
> >
> > Makes sense. I would leave it to others on this list to chime in if
> > there is sufficient interest or not.
> >
> >> To clarify, a clear incremental path from an AWS compatible API to
> an
> >> OpenStack model is not clear.
> >>
> >> In my mind AWS compatible API does not need new openstack model. As
> >> more discussion happen on JC's proposal and implementation b

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

[Stephen Balukoff]

Oh!  One thing I forgot to mention below:


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

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



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

Re: [openstack-dev] VPC Proposal

[Martin, JC]

Joe,

See my comments in line.

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

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

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

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

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

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

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


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

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

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

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

[Georgy Okrokvertskhov]

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

Thanks
Georgy


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

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

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

[Stephen Balukoff]

A couple quick suggestions (additions):

 Entity: L7Rule

o   Attribute: type

§  Possible values:


   - HTTP_METHOD

o   Attribute: compare_type

§  Possible values:


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

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

Thanks,
Stephen

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

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


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

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

[iKhan]

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


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

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



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

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

[Matt Riedemann]

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

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

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

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


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

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

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

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


I haven't seen a blueprint for this yet.

Mark, is that something you were planning on driving?



Here we go:

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

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


--

Thanks,

Matt Riedemann


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

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

[Eugene Nikanorov]

Hi folks,

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

Thanks,
Eugene.



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

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

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

[John Griffith]

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

John

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

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

[Paul Montgomery]

Maybe a crazy idea butŠ

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

* Compiler version
* Language platform
* OS platform

Can we live with that for M1?


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

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

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

[Dugger, Donald D]

Sylvain-

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

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

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

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

Hi Russell and Don,

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


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

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

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

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

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

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


Thanks,
-Sylvain

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

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

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

[Sergey Lukjanov]

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

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

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

Thanks for voting.


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

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



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

Re: [openstack-dev] VPC Proposal

[Joe Gordon]

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

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

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

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

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

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

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

This point concerns me the most, can you elaborate.

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


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

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

 JC,

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

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

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

 Regards,
 Rudra

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

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

[Georgy Okrokvertskhov]

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

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

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

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

Thanks
Georgy


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

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

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

[iKhan]

Hi All,

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

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

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

[Stephen Balukoff]

Hi!


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

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


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

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

[Vishvananda Ishaya]

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

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

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

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

Vish

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



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

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

[Dan Smith]

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

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

> - put the db interactions in the conductor itself

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

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

--Dan

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

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

[Russell Bryant]

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

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

-- 
Russell Bryant

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

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

[Elizabeth Krumbach Joseph]

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

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

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

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

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

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

[Matthew Treinish]

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

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

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

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

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


-Matt Treinish

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

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

[Tracy Jones]

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



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




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

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

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

[openstack-dev] Hierarchical Multitenancy and resource ownership

[Martin, JC]

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

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

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

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

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

I think either would work, and both maybe required.

Opinions ?

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

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

[Eugene Nikanorov]

Hi folks,

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

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

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

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

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

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

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

[Vishvananda Ishaya]

Hi Everyone,

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

Thanks,
Vish


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

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

[Alan Pevec]

Hi John,

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

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

Cheers,
Alan

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

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

[Morgan Fainberg]

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

Cheers,
Morgan Fainberg

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

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

[Russell Bryant]

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

I haven't seen a blueprint for this yet.

Mark, is that something you were planning on driving?

-- 
Russell Bryant

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

Re: [openstack-dev] Unit Testing Nova

[Mike Spreitzer]

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

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

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

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

[Nachi Ueno]

Hi Paul

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

PS
Thank you for your rebasing this one

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

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

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

[Robert Li (baoli)]

Hi Folks,

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

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

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

[Ravi Chunduru]

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

Thanks,
-Ravi.


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

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



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

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

[Alan Pevec]

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

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

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

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

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

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


Cheers,
Alan

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

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

[Christopher Armstrong]

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

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


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

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


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

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

[Mohammad Banikazemi]

Thanks Sumit and Stephen for information provided.

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

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

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

Mohammad



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

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



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


~Sumit.

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

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

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

[Pitucha, Stanislaw Izaak]

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

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

Regards,
Stanisław Pitucha
Cloud Services 
Hewlett Packard



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

Re: [openstack-dev] Unit Testing Nova

[Mike Spreitzer]

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

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

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

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

[openstack-dev] [Neutron] VPC Proposal

[Martin, JC]

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

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

Please, jump in the discussion and share your comments.

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

and 

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

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

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

[Vasudevan, Swaminathan (PNB Roseville)]

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

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

I have opened it again for the public.

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

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

Thanks
Swami

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

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

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

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


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

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

[Sergey Lukjanov]

Ruslan,

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

Thanks.


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

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

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

[Adrian Otto]

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

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

Thanks,

Adrian

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

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


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

Re: [openstack-dev] VPC Proposal

[Martin, JC]

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

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

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

JC

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

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

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

[Abishek Subramanian (absubram)]

Hi shshang, all,

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

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

Thanks!!


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

Re: [openstack-dev] Unit Testing Nova

[Boris Pavlovic]

Mike,

What version of tox do you use?

Best regards,
Boris Pavlovic


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

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

[openstack-dev] Unit Testing Nova

[Mike Spreitzer]

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

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

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

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

[Matt Riedemann]

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

Greetings,

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

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

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

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

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

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

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

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

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

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

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


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


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

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


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




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

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


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


+1



Thanks,



--

Thanks,

Matt Riedemann


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

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

[Dolph Mathews]

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

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

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


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

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

[Tim Bell]

Jay,

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

We've not found a good solution so far.

Tim

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

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

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

[Boris Pavlovic]

Hi,


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

Who will lead this thing?)


Best regards,
Boris Pavlovic



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

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

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

[Dong Liu]

Hi Jay,

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


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

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


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

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

[Jay S Bryant]

All,

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

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

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

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

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




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



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

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

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

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

[Paul Czarkowski]

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

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

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


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

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

[Ben Nemec]

 

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

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

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

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

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


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

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

 

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

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

[Charles Crouch]

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

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

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

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

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


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

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

Thanks
Charles

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

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

[Frittoli, Andrea (HP Cloud)]

Hi, 

 

thanks for the update

 

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

 

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

 

andrea

 

 

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

 

 

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

Hi,

 

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

 

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

 

Much appreciated! Have a link to that bp?

 

 

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

 

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

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

 

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

 

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

 

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

 

 

Andrea

 

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

 

-- 

Andrea Frittoli

IaaS Systems Engineering Team 

HP Cloud ☁


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

 



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

[openstack-dev] Hyper-V meeting minutes

[Peter Pouliot]

Hi everyone,

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

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


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

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

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

[Christopher Armstrong]

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


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

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



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

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

[Kyle Mestery]

[Moving to -dev list]

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

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

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

Thanks,
Kyle

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


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

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

[Thomas Herve]

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

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

-- 
Thomas

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

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

[James E. Blair]

Sean Dague  writes:

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

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

-Jim

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

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

[Matthew Treinish]

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

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

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

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

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

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

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

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

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

-Matt Treinish


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

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

[Alexander Tivelkov]

Hi Ruslan,

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

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

--
Regards,
Alexander Tivelkov


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

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

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

[Christopher Armstrong]

This change was recently merged:

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

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

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

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

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

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

[Jay Pipes]

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

++

Best,
-jay



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

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

[Sean Dague]

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

-Sean

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


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



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

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

[Jay Lau]

Greetings,

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

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

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

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

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

-- 
Thanks,

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

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

[Frittoli, Andrea (Cloud Services)]

Hi all,

 

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

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

 

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

 

andrea

 

-- 

Andrea Frittoli

IaaS Systems Engineering Team 

HP Cloud ☁

PC Phone: +445601090317

 



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

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

[Shaunak Kashyap]

Thanks Angus and Devdatta. I think I understand.

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

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

Thanks,

Shaunak


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

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

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

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

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

Adrian might want to correct my here tho'

-Angus

>
>Thanks,
>Shaunak

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


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

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