[openstack-dev] Voting for the TC Election is now open

[Anita Kuno]

Voting for the TC Election is now open and will remain open until after
1300 utc October 17 2014.

We are electing 6 positions from a pool of 12 candidates[0].

When you receive your email providing you your link to your voting
opportunity, follow the instructions that are available on the page
where you may vote. If you are confused and need more instruction, close
the webpage without submitting your vote and then email myself and
Tristan[1]. Your ballot will still be enabled to vote until the election
is closed, as long as you don't submit your ballot before your close
your webpage.

We are selecting 6 TC members, please rank all candidates in your order
of preference.

You are eligible to vote if are a Foundation individual member[2] that
also has committed to one of the official programs projects[3] over the
Icehouse-Juno timeframe (September 26, 2013 06:00 UTC to September 26,
2014 05:59 UTC) Or if you are one of the extra-atcs.[4]

What to do if you don't see the email and have a commit in at least one
of the official programs projects[3]:
 * check the trash of your gerrit Preferred Email address[5], in
case it went into trash or spam
 * wait a bit and check again, in case your email server is a bit slow
 * find the sha of at least one commit from the program project
repos[3] and email me and Tristan[1]. If we can confirm that you are
entitled to vote, we will add you to the voters list and you will be
emailed a ballot.

Our democratic process is important to the health of OpenStack, please
exercise your right to vote.

Candidate statements/platforms can be found linked to Candidate names on
this page:
https://wiki.openstack.org/wiki/TC_Elections_October_2014#Candidates

Happy voting,
Anita. (anteaya)

[0]
https://wiki.openstack.org/wiki/TC_Elections_October_2014#Confirmed_Candidates
[1] Anita: anteaya at anteaya dot info
 Tristan: tristan dot cacqueray at enovance dot com
[2] http://www.openstack.org/community/members/
[3]
http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml?id=sept-2014-elections
[4]
http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs?id=sept-2014-elections
[5] Sign into review.openstack.org: Go to Settings > Contact
Information. Look at the email listed as your Preferred Email. That is
where the ballot has been sent.

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

[openstack-dev] [Nova][oslo] how to sync oslo.concurrency to nova?

[Chen CH Ji]

There used to method in oslo-incubator like
https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator or '
https://review.openstack.org/#/c/78429/ ' we can use

however, I was told to submit patch to oslo.concurrency instead of
oslo-incubator, so what's the method can be used now ? Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] what happened to ModularL2Agent?

[Wuhongning]

Hi,

In the Juno cycle there is proposal of ModularL2Agent [1,2], which is very 
useful to develop agent for new backend with much less redundant code. Without 
that, we have to either fork a new agent by copying large amount of existing 
l2agent code, or patch existing l2agent. However in the K pad [3] it seems that 
this feature disappeared?

Now there are some interest on hybrid backend (e.g. Hierachical Binding), and 
some BPs are proposed to patch OVS agent. But it has two drawbacks: 1) tightly 
coupled with OVS; 2) OVS agent became unnecessarily heavier. With ML2agent we 
only need to add separated driver modules in the common L2agent framework, but 
not to patch the monolithic ovs agent.

Also if it is convenient  to write only modules but not the whole agent, 
backend providers may prefer to move out most of the logic from MD to agent 
side driver, for better stability for Neutron controller node and easier 
co-existing with other backend. Ofagent shows good compatibility of l2pop to 
build vxlan/gre tunnel network between itself and other ovs/linuxbridge agent.

Or are there any general consideration about Neutron agent side consolidation, 
either L2/L3/L4-7？

1. https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions
2. https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
3. https://etherpad.openstack.org/p/kilo-neutron-summit-topics

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

[openstack-dev] [Nova] Juno RC2 available

[Thierry Carrez]

Hello everyone,

Due to a number of issues discovered in the published Nova 2014.2 RC1
(including a security regression during the Juno development cycle), we
generated a new Juno release candidate. You can find the list of
bugfixes in this RC and a link to a source tarball at:

https://launchpad.net/nova/juno/juno-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as Nova 2014.2 on
October 16. You are therefore strongly encouraged to test and validate
this tarball !

Alternatively, you can directly test the proposed/juno branch at:
https://github.com/openstack/nova/tree/proposed/juno

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/nova/+filebug

and tag it *juno-rc-potential* to bring it to the release crew's
attention.

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Fuel] Let's remove "fuelweb" from repo paths

[Vladimir Kuklin]

I do not have any objections about removing legacy "fuelweb" suffix from
our repo URLs. So I am +1 here.

On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky 
wrote:

> Hi fuelers,
>
> I'm going to propose you remove "fuelweb" word from repos' paths. What
> am I talking about? Let me show you.
>
> Currently we have the following paths to repos:
>
> /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/
> /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/
>
> Obviously, the word "fuelweb" is redundant here and doesn't reflect
> reality, because our repos contain not only fuel packages, but
> openstack.
>
> Moreover, fuel-upgrade script installs repos without that word
> ("fuelweb", I mean) so we have inconsistent file structure for repos,
> which may lead to problems in future.
>
> So I propose to do it now, while we can do it without risks and
> safety. I prepared a set of patches
>
> https://review.openstack.org/#/c/126885/
> https://review.openstack.org/#/c/126886/
> https://review.openstack.org/#/c/126887/
>
> and built an ISO #508 [1] - both master node and centos cluster was
> deployed successfully.
>
> Folks, please, take a look over patches above and let's merge it.
>
> Thanks,
> Igor
>
>
> [1]:
> http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Let's remove "fuelweb" from repo paths

[Matthew Mosesohn]

+1. It was a legacy item and it should go away. I'll review the patches.

On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky  wrote:
> Hi fuelers,
>
> I'm going to propose you remove "fuelweb" word from repos' paths. What
> am I talking about? Let me show you.
>
> Currently we have the following paths to repos:
>
> /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/
> /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/
>
> Obviously, the word "fuelweb" is redundant here and doesn't reflect
> reality, because our repos contain not only fuel packages, but
> openstack.
>
> Moreover, fuel-upgrade script installs repos without that word
> ("fuelweb", I mean) so we have inconsistent file structure for repos,
> which may lead to problems in future.
>
> So I propose to do it now, while we can do it without risks and
> safety. I prepared a set of patches
>
> https://review.openstack.org/#/c/126885/
> https://review.openstack.org/#/c/126886/
> https://review.openstack.org/#/c/126887/
>
> and built an ISO #508 [1] - both master node and centos cluster was
> deployed successfully.
>
> Folks, please, take a look over patches above and let's merge it.
>
> Thanks,
> Igor
>
>
> [1]: 
> http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/
>
> ___
> 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] [Fuel] Let's remove "fuelweb" from repo paths

[Mike Scherbakov]

I have no objections, and essentially I'm for such initiatives at the
beginning of development cycle, when risks are lower.
If we ensure tests coverage, and do it carefully (for instance, building
custom ISO with changes and making sure it passes BVTs), then let's do it.

On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky 
wrote:

> Hi fuelers,
>
> I'm going to propose you remove "fuelweb" word from repos' paths. What
> am I talking about? Let me show you.
>
> Currently we have the following paths to repos:
>
> /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/
> /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/
>
> Obviously, the word "fuelweb" is redundant here and doesn't reflect
> reality, because our repos contain not only fuel packages, but
> openstack.
>
> Moreover, fuel-upgrade script installs repos without that word
> ("fuelweb", I mean) so we have inconsistent file structure for repos,
> which may lead to problems in future.
>
> So I propose to do it now, while we can do it without risks and
> safety. I prepared a set of patches
>
> https://review.openstack.org/#/c/126885/
> https://review.openstack.org/#/c/126886/
> https://review.openstack.org/#/c/126887/
>
> and built an ISO #508 [1] - both master node and centos cluster was
> deployed successfully.
>
> Folks, please, take a look over patches above and let's merge it.
>
> Thanks,
> Igor
>
>
> [1]:
> http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Vladimir Kuklin]

Hi, Fuelers

As you may have noticed our project is growing continuously. And this
imposes a requirement of increasing amount of core reviewers. I would like
to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core
reviewers. As you know, they have been participating actively in
development, design and code review of the majority of project components
as long as being our topmost reviewers and contributors (#2 and #3) [1 and
2] (not to mention being just brilliant engineers and nice people).

Please, reply to my message if you agree or disagree separately for Bogdan
and Sergii (this is mandatory for existing core-reviewers).

[1] http://stackalytics.com/report/contribution/fuel-library/90

[2] http://stackalytics.com/report/contribution/fuel-library/180


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Generic descriptive format for deployment tasks

[Vladimir Kuklin]

Hi, Dmitry

1) In my opinion, we should not have any hardcoded stages in task list.
These should be virtual roles, that you can use as a vertex in dependency
graph to aggregate and group tasks. Just like it is done in puppet with
anchors.

Also, we may need to look into some meta-data related approach, e.g. using
tagging of tasks, nodes and roles. For example, we could mark rabbitmq,
pacemaker and galera installation with "ha" tags and then use this tag when
specifying dependency for other tasks.

2) Also, we need to use generic approach for dependencies specification:
"before" and "after" for tasks. There is no need to use integer values for
priorities, as all we need to do is just provide an ordered set of tasks -
there is no need for particular numeric values.

3) Regarding roles - role is just an aggregational entity that combines
several tasks

4) Regarding dependency and role keywords: I think, we need to look into
some kind of query language that can satisfy our requirements. E.g., I can
easily imagine a usecase when we need to do some dynamical calculation of
nodes on which to execute the particular task. I think, we could look into
Mistral and Murano projects doing some of the similar stuff and decide
whether their approach fits our needs.  As an example, we may need to
exclude the node being added from a particular set of tasks. Imagine, we
just added a controller. After we deployed it, all we need is to just
update several configs on the nodes and restart/reload particular services,
e.g. haproxy on controllers and nova-compute services on the computes. In
this case, you will need to tag a node with, let's say "new-node" tag and
then exclude it from execution list by using something like
"!tags.include("new-node")"



On Fri, Oct 10, 2014 at 10:21 AM, Dmitriy Shulyak 
wrote:

>
> Hi team,
> After several discussions i want to propose generic format
> for describing deployment tasks, this format is expected to cover
> all tasks (e.g pre-deployment and post-deployment), also it should cover
> different actions like upgrade/patching
>
> action: upload_file
> id: upload_astute
> roles: *
> parameters:
> input: $.data - this is internal mistral thing
> timeout: 50
>
> action: tasklib
> id: generate_keys
> stages: [pre-deployment]
> roles: master
> parameters:
> timeout: 60
> command: generate/keys
> type: puppet
> manifest: /etc/puppet/manifests/key_generator.pp
>
> action: tasklib
> id: rsync_puppet
> stages: [pre-node]
> requires: [upload_astute]
> parameters:
> timeout: 100
> command: rsync/stuff
> type: shell
> cmd: python rsync.py
>
> action: tasklib
> id: ceph
> roles: [ceph-osd, ceph-mon]
> requires: [rsync_puppet]
> parameters:
> timeout: 100
> command: deployment/ceph
> type: puppet
> manifest: /etc/puppet/manifests/ceph.pp
>
> action: tasklib
> id: glance/image
> roles: [controller, primary-controller]
> stages: [post-deployment]
> parameters:
> timeout: 100
> command: deployment/glance/image
> type: shell
> cmd: python upload_image.py
>
> Let me provide some clarifications:
> 1. As example, we want to generate keys strictly before deployment, and
> the 1st way to solve
> it is to introduce concept of stages, e.g pre-deployment, main, upgrade,
> post-deployment.
> Another one would be to use virtual roles and/or virtual tasks like
> deployment_started, deployment_ended.
> We need to consider both, but stages it is what we are using now, and i am
> just trying to generalize and make it data-driven.
> 2. Another internal thing is roles. As you can see in this configs there
> is 2
> specific keywords for roles:
> * - means task should be executed on all roles
> master - task should be only executed on fuel master node
> All other roles should be entities from fuel. If you know other exceptions
> - lets discuss them.
>
> I would like to ask team for 2 things:
> 1. Examine approach and ask questions about any specific tasks, in order
> to test
> this approach for sanity.
> 2. If you think that some of the keywords in configuration is not
> appropriate, lets discuss it. For example we can not agree on term "stage",
> because it is too widely used and basically we need another one.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Murano] Juno RC2 available

[Ruslan Kamaldinov]

We had to release RC2 to address an issue blocking the inclusion of
Murano Dashboard in Debian experimental packages. Tarballs with RC2
are available at:

https://launchpad.net/murano/juno/juno-rc2

Thanks,
Ruslan

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

Re: [openstack-dev] [Fuel] Let's remove "fuelweb" from repo paths

[Igor Kalnitsky]

As I mentioned early, I already have an ISO with patches and it works
fine in my own deployment.

However, I ran the BVT tests on centos [1] and ubuntu [2].

[1]: 
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom.centos.bvt_1/198/
[2]: 
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom.ubuntu.bvt_2/170/

On Fri, Oct 10, 2014 at 12:25 PM, Mike Scherbakov
 wrote:
> I have no objections, and essentially I'm for such initiatives at the
> beginning of development cycle, when risks are lower.
> If we ensure tests coverage, and do it carefully (for instance, building
> custom ISO with changes and making sure it passes BVTs), then let's do it.
>
> On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky 
> wrote:
>>
>> Hi fuelers,
>>
>> I'm going to propose you remove "fuelweb" word from repos' paths. What
>> am I talking about? Let me show you.
>>
>> Currently we have the following paths to repos:
>>
>> /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/
>> /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/
>>
>> Obviously, the word "fuelweb" is redundant here and doesn't reflect
>> reality, because our repos contain not only fuel packages, but
>> openstack.
>>
>> Moreover, fuel-upgrade script installs repos without that word
>> ("fuelweb", I mean) so we have inconsistent file structure for repos,
>> which may lead to problems in future.
>>
>> So I propose to do it now, while we can do it without risks and
>> safety. I prepared a set of patches
>>
>> https://review.openstack.org/#/c/126885/
>> https://review.openstack.org/#/c/126886/
>> https://review.openstack.org/#/c/126887/
>>
>> and built an ISO #508 [1] - both master node and centos cluster was
>> deployed successfully.
>>
>> Folks, please, take a look over patches above and let's merge it.
>>
>> Thanks,
>> Igor
>>
>>
>> [1]:
>> http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Mike Scherbakov
> #mihgen
>
>
> ___
> 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] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Mike Scherbakov]

+1 for both.

On Fri, Oct 10, 2014 at 1:35 PM, Vladimir Kuklin 
wrote:

> Hi, Fuelers
>
> As you may have noticed our project is growing continuously. And this
> imposes a requirement of increasing amount of core reviewers. I would like
> to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core
> reviewers. As you know, they have been participating actively in
> development, design and code review of the majority of project components
> as long as being our topmost reviewers and contributors (#2 and #3) [1 and
> 2] (not to mention being just brilliant engineers and nice people).
>
> Please, reply to my message if you agree or disagree separately for Bogdan
> and Sergii (this is mandatory for existing core-reviewers).
>
> [1] http://stackalytics.com/report/contribution/fuel-library/90
> 
> [2] http://stackalytics.com/report/contribution/fuel-library/180
> 
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Nova][oslo] how to sync oslo.concurrency to nova?

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/10/14 10:32, Chen CH Ji wrote:
> There used to method in oslo-incubator like 
> https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator
> or '_https://review.openstack.org/#/c/78429/_ ' we can use
> 
> however, I was told to submit patch to oslo.concurrency instead of 
> oslo-incubator, so what's the method can be used now ? Thanks a
> lot

With oslo.concurrency, you don't copy-paste code, you just reuse it as
any other third-party library. So if your project is not yet using the
library, just port it to it first, and once a new version of
oslo.concurrency is released, you will get your change magically applied.

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUN69RAAoJEC5aWaUY1u57sEEH/0q2HxdZkMKNDT+99hZWyyP7
qgeV77UKQ8bHNHVvMVW8vwSqemJVbJwTLrZxPkm4GodwdpF4voXeN1QdA8srU9a2
2DiAdzyrZLlUINpezXKmqOIqNYBg4uxwVCBNgShCM1ViHZkBuViG9c1dNiKyl5e/
97AJSGV8NXa3mmlOpJJZ2KkfUCaMHo0KbBTSsdAa/td2a17IzpYl80BQB6zrtytB
Ou0hYyD/rCVdekcg9ZbyR0DDO6gZR7EGHMzLoM+pWgLQ6+JAlnsaxxUR1ACLO51+
w65IYIArBZpVFyJFnHy/WiPpqitUBiHceXcykdlBFFpTnRe2SN+Ks4U5x+9QnSM=
=/Y4a
-END PGP SIGNATURE-

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

Re: [openstack-dev] Can sqlalchemy-migrate-core just be oslo.db core?

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/10/14 23:44, Doug Hellmann wrote:
> 
> On Oct 9, 2014, at 4:30 PM, Matt Riedemann
>  wrote:
> 
>> The sqlalchemy-migrate project is basically maintenance mode and
>> the core team [1] is kind of a weird mix of people - all great
>> people I'm sure, but I think it's more a team of people that
>> stepped up when OpenStack took over the project and said they'd
>> babysit it but it's pretty idle.
>> 
>> Given we have oslo.db now, and sqlalchemy-migrate is all DB
>> goodies, can we just have the oslo.db core team [2] own
>> sqlalchemy-migrate now too?
>> 
>> Here are the sqlalchemy-migrate open reviews:
>> 
>> https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z
>>
>>
>> 
[1] https://review.openstack.org/#/admin/groups/186,members
>> [2] https://review.openstack.org/#/admin/groups/331,members
> 
> If the oslo.db team wants to participate, that’s obviously fine,
> but I don’t think we want to just add everyone in bulk. AIUI, the
> team’s goal is to get the migration stuff in oslo.db working with
> alembic so we can stop using sqlalchemy-migrate.

Till that time, we're left with the library used by multiple projects.
I feel it's hard to get any review in meaningful time for the library,
so if moving the library under the oslo.db tent will help it move, I'm
both hands for that.

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUN7B4AAoJEC5aWaUY1u57JLIH/jn9iREgmRhvfiZosiN9knxV
xrVFgEpZ35G5kGmWrnnnKvbWUIvIawwoA2OCOCMXScL5xwzLtn9+prvcujvGK3g1
/zk1aVKnKv90zR6j0ATgTq49tQQpVVe1KkaePzWRYIkU22f7KAPGmwjQlLfebV06
bWOS5HyUeueAIno67EVY3AM669JtKmS6ZqswIciEfMvsOmdDDrDje1qVUH9VVsoy
UkvOQ+CPCTqwjIpbkbDrfIXJpA5qm0cCwPx8wDoYnEUN7laGjTtV0JMwGKwjBti0
y4ubs0X5xOU2ayr7xJXbeHCSB5eZKVZesbDyOCCk+lIaldih3qN6AR+Snncwjy4=
=Ex7c
-END PGP SIGNATURE-

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

Re: [openstack-dev] [all] [oslo] Proposed database connectivity patterns

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/10/14 21:29, Mike Bayer wrote:
> So so far, everyone seems really positive and psyched about the
> proposal.
> 
> It looks like providing some options for how to use would be best,
> that is provide decorators and context managers.
> 
> Now the thing with the context manager, it can be as I stated:
> 
> with sql.reader() as session:
> 
> or we can even have that accept the “context”:
> 
> with sql.reader(context) as session:
> 
> The latter again avoids having to use thread locals.
> 
> But can I get a feel for how comfortable we are with using thread
> local storage to implement this feature?   I had anticipated people
> wouldn’t like it because it’s kind of a “global” object, even
> though it will be hidden behind this facade (of course CONF is
> global as is sys.modules, and I think it is fine). If I just
> use a tlocal, this whole thing is pretty simple.

Won't the approach conflict with eventlet consumers that for some
reason do not patch thread module, or do not patch it early enough? I
guess in that case we may end up with mixed contexts.

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUN7FeAAoJEC5aWaUY1u57sq0IANSM8gKCQZbgEY62uvyhZqzN
9gRDcFbTrH/yUNMv0tt3+e2vVEbn8VIatDWG4/OYghzuI1BerKzhP7JD5J+mV8yK
sB0fc6ybHmz14T962LhFkAxWKybPW3sJO/0GIy606ty0OEV8QAgPwaYvjW596MUa
BAp0IRAz4/MglT/M80OkT2jFdMV+a9SAFUKvnF/21KSGo/t4qcawA/+B0c3Ownle
eYt+Auk3hcgJnZAvCOwy7bcAb1b12gonk4nIwMl/Mik8IKNR5fnl1IqTiISUO2Jw
PV95/7muukSrt54lY+9u4SW9o/Zf/gaNCMmK3xfDmvMug6tk0SWzkzBZLva3wNc=
=04Wx
-END PGP SIGNATURE-

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

Re: [openstack-dev] [neutron] what happened to ModularL2Agent?

[Salvatore Orlando]

Comments inline.

Salvatore

On 10 October 2014 11:02, Wuhongning  wrote:

>  Hi,
>
>  In the Juno cycle there is proposal of ModularL2Agent [1,2], which is
> very useful to develop agent for new backend with much less redundant code.
> Without that, we have to either fork a new agent by copying large amount of
> existing l2agent code, or patch existing l2agent. However in the K pad [3]
> it seems that this feature disappeared?
>

The fact that the topic is not present in the Kilo summit discussion does
not mean that the related work item has been tabled.
It just means that it's not something we'll probably discuss at the summit,
mostly because the discussion can happen on the mailing list - as you're
doing now.
I think a summit session should be granted if the community still needs to
achieve consensus on the technical direction or if the topic is of such a
paramount importance that awareness needs to be raised.

The blueprint and spec for this topic are available ad [1] and [2], and
afaict are still active.


>
>  Now there are some interest on hybrid backend (e.g. Hierachical
> Binding), and some BPs are proposed to patch OVS agent. But it has two
> drawbacks: 1) tightly coupled with OVS; 2) OVS agent became unnecessarily
> heavier. With ML2agent we only need to add separated driver modules in the
> common L2agent framework, but not to patch the monolithic ovs agent.
>

The point of a modular L2 agent is to have a very efficient RPC interface
with the neutron server and a framework for detecting data plane
transitions, such as new ports, and apply the corresponding configurations.
And then have driver which will apply such configurations to different
backends.

I reckon the blueprints you are referring to are probably assuming the OVS
agent becomes modular - because otherwise it will be hardy able to target
backends which are not ovs.


>
>  Also if it is convenient  to write only modules but not the whole agent,
> backend providers may prefer to move out most of the logic from MD to agent
> side driver, for better stability for Neutron controller node and easier
> co-existing with other backend. Ofagent shows good compatibility of l2pop
> to build vxlan/gre tunnel network between itself and other ovs/linuxbridge
> agent.
>
>  Or are there any general consideration about Neutron agent side
> consolidation, either L2/L3/L4-7？
>

As far as I know there is no plan for a consolidate neutron agent which
does L2/L7 operations. Frankly I do not even think there is any need for it.


>
>  1.
> https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions
> 2. https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
> 3. https://etherpad.openstack.org/p/kilo-neutron-summit-topics
>
>  Best Regards
> Wu
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[1] https://blueprints.launchpad.net/neutron/+spec/modular-l2-agent
[2]
https://review.openstack.org/#/q/project:openstack/neutron-specs+branch:master+topic:bp/modular-L2-agent,n,z
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Let's remove "fuelweb" from repo paths

[Igor Kalnitsky]

Folks,

BVT tests are passed successfully.
What about merging?

Thanks,
Igor

On Fri, Oct 10, 2014 at 12:40 PM, Igor Kalnitsky
 wrote:
> As I mentioned early, I already have an ISO with patches and it works
> fine in my own deployment.
>
> However, I ran the BVT tests on centos [1] and ubuntu [2].
>
> [1]: 
> http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom.centos.bvt_1/198/
> [2]: 
> http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom.ubuntu.bvt_2/170/
>
> On Fri, Oct 10, 2014 at 12:25 PM, Mike Scherbakov
>  wrote:
>> I have no objections, and essentially I'm for such initiatives at the
>> beginning of development cycle, when risks are lower.
>> If we ensure tests coverage, and do it carefully (for instance, building
>> custom ISO with changes and making sure it passes BVTs), then let's do it.
>>
>> On Wed, Oct 8, 2014 at 9:08 PM, Igor Kalnitsky 
>> wrote:
>>>
>>> Hi fuelers,
>>>
>>> I'm going to propose you remove "fuelweb" word from repos' paths. What
>>> am I talking about? Let me show you.
>>>
>>> Currently we have the following paths to repos:
>>>
>>> /var/www/nailgun/2014.2-6.0/centos/fuelweb/x86_64/
>>> /var/www/nailgun/2014.2-6.0/ubuntu/fuelweb/x86_64/
>>>
>>> Obviously, the word "fuelweb" is redundant here and doesn't reflect
>>> reality, because our repos contain not only fuel packages, but
>>> openstack.
>>>
>>> Moreover, fuel-upgrade script installs repos without that word
>>> ("fuelweb", I mean) so we have inconsistent file structure for repos,
>>> which may lead to problems in future.
>>>
>>> So I propose to do it now, while we can do it without risks and
>>> safety. I prepared a set of patches
>>>
>>> https://review.openstack.org/#/c/126885/
>>> https://review.openstack.org/#/c/126886/
>>> https://review.openstack.org/#/c/126887/
>>>
>>> and built an ISO #508 [1] - both master node and centos cluster was
>>> deployed successfully.
>>>
>>> Folks, please, take a look over patches above and let's merge it.
>>>
>>> Thanks,
>>> Igor
>>>
>>>
>>> [1]:
>>> http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/508/
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>

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

[openstack-dev] [Neutron] Juno RC2 available

[Thierry Carrez]

Hello everyone,

Due to various issues discovered in the published Neutron 2014.2 RC1, we
generated a new Juno release candidate. You can find the list of
bugfixes in this RC and a link to a source tarball at:

https://launchpad.net/neutron/juno/juno-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as Neutron 2014.2
on October 16. You are therefore strongly encouraged to test and
validate this tarball !

Alternatively, you can directly test the proposed/juno branch at:
https://github.com/openstack/neutron/tree/proposed/juno

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/neutron/+filebug

and tag it *juno-rc-potential* to bring it to the release crew's attention.

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [neutron] what happened to ModularL2Agent?

[Hly]

在 2014-10-10，下午7:16，Salvatore Orlando  写道：

> Comments inline.
> 
> Salvatore
> 
> On 10 October 2014 11:02, Wuhongning  wrote:
> Hi,
> 
> In the Juno cycle there is proposal of ModularL2Agent [1,2], which is very 
> useful to develop agent for new backend with much less redundant code. 
> Without that, we have to either fork a new agent by copying large amount of 
> existing l2agent code, or patch existing l2agent. However in the K pad [3] it 
> seems that this feature disappeared?
> 
> The fact that the topic is not present in the Kilo summit discussion does not 
> mean that the related work item has been tabled.
> It just means that it's not something we'll probably discuss at the summit, 
> mostly because the discussion can happen on the mailing list - as you're 
> doing now.
> I think a summit session should be granted if the community still needs to 
> achieve consensus on the technical direction or if the topic is of such a 
> paramount importance that awareness needs to be raised.
> 
> The blueprint and spec for this topic are available ad [1] and [2], and 
> afaict are still active.
>  
> 
> Now there are some interest on hybrid backend (e.g. Hierachical Binding), and 
> some BPs are proposed to patch OVS agent. But it has two drawbacks: 1) 
> tightly coupled with OVS; 2) OVS agent became unnecessarily heavier. With 
> ML2agent we only need to add separated driver modules in the common L2agent 
> framework, but not to patch the monolithic ovs agent.
> 
> The point of a modular L2 agent is to have a very efficient RPC interface 
> with the neutron server and a framework for detecting data plane transitions, 
> such as new ports, and apply the corresponding configurations. And then have 
> driver which will apply such configurations to different backends.
> 
> I reckon the blueprints you are referring to are probably assuming the OVS 
> agent becomes modular - because otherwise it will be hardy able to target 
> backends which are not ovs.
>  
> 
> Also if it is convenient  to write only modules but not the whole agent, 
> backend providers may prefer to move out most of the logic from MD to agent 
> side driver, for better stability for Neutron controller node and easier 
> co-existing with other backend. Ofagent shows good compatibility of l2pop to 
> build vxlan/gre tunnel network between itself and other ovs/linuxbridge agent.
> 
> Or are there any general consideration about Neutron agent side 
> consolidation, either L2/L3/L4-7？
> 
> As far as I know there is no plan for a consolidate neutron agent which does 
> L2/L7 operations. Frankly I do not even think there is any need for it.
>  

No necessary consolidation of L2-7, but L2 agent consolidation, L3 agent 
consolidation, advanced service agent consolidation by each, but all have 
framework with modular drivers

> 
> 1. https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions
> 2. https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
> 3. https://etherpad.openstack.org/p/kilo-neutron-summit-topics
> 
> Best Regards
> Wu
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> [1] https://blueprints.launchpad.net/neutron/+spec/modular-l2-agent
> [2] 
> https://review.openstack.org/#/q/project:openstack/neutron-specs+branch:master+topic:bp/modular-L2-agent,n,z
> 
> ___
> 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] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Aleksey Kasatkin]

Agree for Bogdan and Sergii

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

Re: [openstack-dev] [Fuel] [Rally] Using fuelclient as a library - battle report

[Ilya Kharin]

Hi guys,

I agree with some of the issues Lukasz mentioned. All of them require some
workaround to make it possible to use the client as a library. I can
summarize some of the problems I encountered while working with fuelclient:

- The distribution of the package is absent. The client cannot be specified
as a dependency because it is not presented on PyPI and cannot be installed
by pip (that is so for the current releases but not for the development
branch).

- The client cannot be initialized properly because it's designed as a
singleton which is initialized on the import of a module. Initialization
parameters can be specified either in a configuration file with a hardcoded
filename (which can potentially be absent on the client-side host because
of its location at /etc/fuel/client/config.yaml) or in environment
variables. These limitations force us to specify the environment variables
and then use inline imports.

In my team we are thinking about our own implementation of the client as a
solution.

Best regards,
Ilya


On Mon, Oct 6, 2014 at 6:09 PM, Igor Kalnitsky 
wrote:

> Hi Lukasz,
>
> I have the same thoughts - we have to design a good Python library for
> dealing with Nailgun and this library has to be used by:
>
> * Fuel CLI
> * System Tests
> * Fuel Upgrade
> * OSTF
> * other scripts
>
> But it's a big deal and we definetely should have a separate blueprint
> for this task. Moreover, we have to carefully consider its
> architecture to be convenient not only for CLI usage.
>
> Thanks,
> Igor
>
> On Mon, Oct 6, 2014 at 4:49 PM, Lukasz Oles  wrote:
> > Hello all,
> >
> > I'm researching if we can use Rally project for some Fuel testing.
> > It's part of 100-nodes blueprint[1].
> > To write some Rally scenario I used our Fuelclient "library".
> > In it's current state it's really painful to use and it's not usable
> > as production tool.
> >
> > Here is the list of the biggest issues:
> >
> > 1. If API returns code other than 20x it exits. Literally it calls
> > sys.exit(). It should just rise Exception.
> > 2. Using API Client as a Singleton. In theory we can have more than
> > one connection, but all new objects will use default connection.
> > 3. Can not use  keystone token. It requires user and password.
> >  Server address and all credentials can be given via config file or
> > environment variables. There is no way to set it during client
> > initialization.
> >
> > All this issues show that library was designed only with CLI in mind.
> > Especially issue nr 1.
> > Now I know why ostf doesn't use fuelcient, why Rally wrote their own
> > client. And I can bet that MOX team is also using their own version.
> >
> > I'm aware of Fuelclient refactoring blueprint[1] I reviewed it and
> > gave +1 to most of the reviews. Unfortunately it focuses on CLI usage.
> > Move to Cliff is very good idea,
> > but for library it actually makes things worse [2] like moving data
> > validation to CLI or initializing object using single dictionary
> > instead of normal arguments.
> >
> > I think instead of focusing on CLI usage we should focus on a library
> > part. To make it easier to use by other programs. After that we can
> > focus on CLI. It's very important now when we are planning to support
> > 100 nodes and more in future because more and more users will start
> > use Fuel via API instead of UI.
> >
> > What do you think about this?
> >
> > Regards,
> >
> > [1]
> https://blueprints.launchpad.net/fuel/+spec/refactoring-for-fuelclient
> > [2] https://review.openstack.org/#/c/117294/
> >
> >
> >
> >
> > Regards,
> >
> > --
> > Łukasz Oleś
> >
> > ___
> > 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] Fwd: Unable to install devstack

[Shruti Sharma]

Hello All,

I am new to Openstack and trying to setup Devstack.
I am using ubuntu desktop 14.04 as os. I have cloned devstack sucessfully
from github.But while installing I am facing error :

It gives http error 407 and finally gives unable to download get-pip.py
failed.

which i found is error due to proxy authentication and all.
So I changed my local.config file to give proxy variables. I have already
set my apt.conf and environment files. I am attaching my local.config for
better understanding. Then i copied both local.config and local.sh from
sample to devstack folder as well still no success.
I have made changes according to the link:
http://www.rushiagr.com/blog/2014/08/05/devstack-behind-proxy/

Here is my terminal output when it fails:
http://pastebin.com/hj7Bhmzk

Suggestion Please



*Shruti Sharma, Final Year, Computer Engineering*
*Malaviya National Institute of Technology*


local.conf
Description: Binary data
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Igor Kalnitsky]

+1.

On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin  wrote:
> Hi, Fuelers
>
> As you may have noticed our project is growing continuously. And this
> imposes a requirement of increasing amount of core reviewers. I would like
> to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core
> reviewers. As you know, they have been participating actively in
> development, design and code review of the majority of project components as
> long as being our topmost reviewers and contributors (#2 and #3) [1 and 2]
> (not to mention being just brilliant engineers and nice people).
>
> Please, reply to my message if you agree or disagree separately for Bogdan
> and Sergii (this is mandatory for existing core-reviewers).
>
> [1] http://stackalytics.com/report/contribution/fuel-library/90
> [2] http://stackalytics.com/report/contribution/fuel-library/180
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuk...@mirantis.com
>
> ___
> OpenStack-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][oslo] how to sync oslo.concurrency to nova?

[Ben Nemec]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/10/2014 05:05 AM, Ihar Hrachyshka wrote:
> On 10/10/14 10:32, Chen CH Ji wrote:
>> There used to method in oslo-incubator like 
>> https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator 
>> or '_https://review.openstack.org/#/c/78429/_ ' we can use
> 
>> however, I was told to submit patch to oslo.concurrency instead
>> of oslo-incubator, so what's the method can be used now ? Thanks
>> a lot
> 
> With oslo.concurrency, you don't copy-paste code, you just reuse it
> as any other third-party library. So if your project is not yet
> using the library, just port it to it first, and once a new version
> of oslo.concurrency is released, you will get your change magically
> applied.

At this point oslo.concurrency hasn't been released yet so it won't be
possible to switch any projects to use it.  I think we're on track for
a first release early next week and once that has happened this will
be possible.

Note that we do have a stable branch of the incubator code that can be
used for important changes in projects that haven't yet ported to use
new libs, but when possible we'd rather just make the changes in the lib.

- -Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUN+bgAAoJEDehGd0Fy7uqjhMIANBPX4sTbVSnewoquF3Ih29z
Adxq6KpDymonhpnJuOqM1gKYsd/oyqa6q92WTt9F9c8XwALB1x9IzgUBRRixhts5
p4fDzNTMGJzlT9slnGjyNVD0i3AJ1UuO5+mZADDk3jXqqERmbeCo+BgYqJr7q08r
MmkPuo0EAZtWrY1+Isl1Eg3lz7P2DFC9kEmY8iUj5wObiqINU7L5MNCzCi7V+c8g
uxacoCSXcyTR7nnXcs9cPywthBTLOOqkY1IzEYk38vbnQSmvqKbbovqVB0ZCTueF
8g/WO2+jOhETsyFGY7d3HuOQDxJSx/JeXlpPfriOsxdcrDtmP3YMEgh2kpK0e7k=
=Puy/
-END PGP SIGNATURE-

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

[openstack-dev] Unable to install devstack

[Shruti Sharma]

Hello All,

I am new to Openstack and trying to setup Devstack.
I am using ubuntu desktop 14.04 as os. I have cloned devstack sucessfully
from github.But while installing I am facing error :

It gives http error 407 and finally gives unable to download get-pip.py
failed.

which i found is error due to proxy authentication and all.
So I changed my local.config file to give proxy variables. I have already
set my apt.conf and environment files. I am attaching my local.config for
better understanding. Then i copied both local.config and local.sh from
sample to devstack folder as well still no success.
I have made changes according to the link:
http://www.rushiagr.com/blog/2014/08/05/devstack-behind-proxy/

Here is my terminal output when it fails:
http://pastebin.com/hj7Bhmzk

Suggestion Please



*Shruti Sharma, Final Year, Computer Engineering*
*Malaviya National Institute of Technology*
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Can sqlalchemy-migrate-core just be oslo.db core?

[Doug Hellmann]

On Oct 10, 2014, at 6:10 AM, Ihar Hrachyshka  wrote:

> Signed PGP part
> On 09/10/14 23:44, Doug Hellmann wrote:
> >
> > On Oct 9, 2014, at 4:30 PM, Matt Riedemann
> >  wrote:
> >
> >> The sqlalchemy-migrate project is basically maintenance mode and
> >> the core team [1] is kind of a weird mix of people - all great
> >> people I'm sure, but I think it's more a team of people that
> >> stepped up when OpenStack took over the project and said they'd
> >> babysit it but it's pretty idle.
> >>
> >> Given we have oslo.db now, and sqlalchemy-migrate is all DB
> >> goodies, can we just have the oslo.db core team [2] own
> >> sqlalchemy-migrate now too?
> >>
> >> Here are the sqlalchemy-migrate open reviews:
> >>
> >> https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z
> >>
> >>
> >>
> [1] https://review.openstack.org/#/admin/groups/186,members
> >> [2] https://review.openstack.org/#/admin/groups/331,members
> >
> > If the oslo.db team wants to participate, that’s obviously fine,
> > but I don’t think we want to just add everyone in bulk. AIUI, the
> > team’s goal is to get the migration stuff in oslo.db working with
> > alembic so we can stop using sqlalchemy-migrate.
> 
> Till that time, we're left with the library used by multiple projects.
> I feel it's hard to get any review in meaningful time for the library,
> so if moving the library under the oslo.db tent will help it move, I'm
> both hands for that.

It is not generally our community’s practice to assign core responsibility for 
a code base to anyone, especially without asking. Invite anyone to join the 
reviewer team, but please do not assume that just because there is a team 
working on database related code they are also interested in working on this 
code.

Doug

> 
> /Ihar
> 
> 
> ___
> 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] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Aleksandr Didenko]

+1 for both.

On Fri, Oct 10, 2014 at 5:01 PM, Igor Kalnitsky 
wrote:

> +1.
>
> On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin 
> wrote:
> > Hi, Fuelers
> >
> > As you may have noticed our project is growing continuously. And this
> > imposes a requirement of increasing amount of core reviewers. I would
> like
> > to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as
> core
> > reviewers. As you know, they have been participating actively in
> > development, design and code review of the majority of project
> components as
> > long as being our topmost reviewers and contributors (#2 and #3) [1 and
> 2]
> > (not to mention being just brilliant engineers and nice people).
> >
> > Please, reply to my message if you agree or disagree separately for
> Bogdan
> > and Sergii (this is mandatory for existing core-reviewers).
> >
> > [1] http://stackalytics.com/report/contribution/fuel-library/90
> > [2] http://stackalytics.com/report/contribution/fuel-library/180
> >
> > --
> > Yours Faithfully,
> > Vladimir Kuklin,
> > Fuel Library Tech Lead,
> > Mirantis, Inc.
> > +7 (495) 640-49-04
> > +7 (926) 702-39-68
> > Skype kuklinvv
> > 45bk3, Vorontsovskaya Str.
> > Moscow, Russia,
> > www.mirantis.com
> > www.mirantis.ru
> > vkuk...@mirantis.com
> >
> > ___
> > OpenStack-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] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Evgeniy L]

+1

On Fri, Oct 10, 2014 at 6:09 PM, Aleksandr Didenko 
wrote:

> +1 for both.
>
> On Fri, Oct 10, 2014 at 5:01 PM, Igor Kalnitsky 
> wrote:
>
>> +1.
>>
>> On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin 
>> wrote:
>> > Hi, Fuelers
>> >
>> > As you may have noticed our project is growing continuously. And this
>> > imposes a requirement of increasing amount of core reviewers. I would
>> like
>> > to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as
>> core
>> > reviewers. As you know, they have been participating actively in
>> > development, design and code review of the majority of project
>> components as
>> > long as being our topmost reviewers and contributors (#2 and #3) [1 and
>> 2]
>> > (not to mention being just brilliant engineers and nice people).
>> >
>> > Please, reply to my message if you agree or disagree separately for
>> Bogdan
>> > and Sergii (this is mandatory for existing core-reviewers).
>> >
>> > [1] http://stackalytics.com/report/contribution/fuel-library/90
>> > [2] http://stackalytics.com/report/contribution/fuel-library/180
>> >
>> > --
>> > Yours Faithfully,
>> > Vladimir Kuklin,
>> > Fuel Library Tech Lead,
>> > Mirantis, Inc.
>> > +7 (495) 640-49-04
>> > +7 (926) 702-39-68
>> > Skype kuklinvv
>> > 45bk3, Vorontsovskaya Str.
>> > Moscow, Russia,
>> > www.mirantis.com
>> > www.mirantis.ru
>> > vkuk...@mirantis.com
>> >
>> > ___
>> > OpenStack-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] Unable to install devstack

[Paul Michali (pcm)]

I’m assuming you’ve verified that your proxy server settings are correct. Try 
setting GIT_BASE to https://github.com

You should be able to manually try the commands. For example, set your proxy 
env variables and then do:

curl -o /home/shruti/devstack/files/get-pip.py 
https://bootstrap.pypa.io/get-pip.py

For my setup (behind a proxy), I set both the upper and lower case proxy env 
variables:

export PROXY_HOST=:80
export http_proxy=http://$PROXY_HOST/
export https_proxy=http://$PROXY_HOST/
export ftp_proxy=http://$PROXY_HOST/
export no_proxy="14.0.3.30,..."
export HTTP_PROXY=http://$PROXY_HOST/
export HTTPS_PROXY=http://$PROXY_HOST/
export FTP_PROXY=http://$PROXY_HOST/

Maybe overkill..

Regards,

PCM (Paul Michali)

MAIL …..…. p...@cisco.com
IRC ……..… pcm_ (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



On Oct 10, 2014, at 9:54 AM, Shruti Sharma  wrote:

> 
> 
> Hello All,
> 
> I am new to Openstack and trying to setup Devstack.
> I am using ubuntu desktop 14.04 as os. I have cloned devstack sucessfully 
> from github.But while installing I am facing error :
> 
> It gives http error 407 and finally gives unable to download get-pip.py 
> failed.
> 
> which i found is error due to proxy authentication and all.
> So I changed my local.config file to give proxy variables. I have already set 
> my apt.conf and environment files. I am attaching my local.config for better 
> understanding. Then i copied both local.config and local.sh from sample to 
> devstack folder as well still no success.
> I have made changes according to the link:
> http://www.rushiagr.com/blog/2014/08/05/devstack-behind-proxy/
> 
> Here is my terminal output when it fails:
> http://pastebin.com/hj7Bhmzk
> 
> Suggestion Please
> 
> 
> Shruti Sharma, Final Year, Computer Engineering
> Malaviya National Institute of Technology
> 
> ___
> 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] [all] [oslo] Proposed database connectivity patterns

[Mike Bayer]

On Oct 10, 2014, at 6:13 AM, Ihar Hrachyshka  wrote:

> Signed PGP part
> On 09/10/14 21:29, Mike Bayer wrote:
> > So so far, everyone seems really positive and psyched about the
> > proposal.
> >
> > It looks like providing some options for how to use would be best,
> > that is provide decorators and context managers.
> >
> > Now the thing with the context manager, it can be as I stated:
> >
> > with sql.reader() as session:
> >
> > or we can even have that accept the “context”:
> >
> > with sql.reader(context) as session:
> >
> > The latter again avoids having to use thread locals.
> >
> > But can I get a feel for how comfortable we are with using thread
> > local storage to implement this feature?   I had anticipated people
> > wouldn’t like it because it’s kind of a “global” object, even
> > though it will be hidden behind this facade (of course CONF is
> > global as is sys.modules, and I think it is fine). If I just
> > use a tlocal, this whole thing is pretty simple.
> 
> Won't the approach conflict with eventlet consumers that for some
> reason do not patch thread module, or do not patch it early enough? I
> guess in that case we may end up with mixed contexts.

I’ve been asking a lot about “hey are people cool with thread locals?” and have 
been waiting for what the concerns are.

Since I wrote that email I’ve shifted, and I’ve been considering only:

@sql.reader
def my_api_method(context, …):
   context.session

def my_api_method(context, …):
  with sql.using_reader(context) as session:
session , context.session

because in fact, if you *want* to use a thread local context, you can, 
explicitly with the above:

GLOBAL_CONTEXT = threading.local()

def my_api_method(…):
  with sql.using_reader(GLOBAL_CONTEXT) as session:
session 

I like that one the best.  But again, Keystone folks would need to accept this 
explicitness.

The challenge on my end is not technical in any way.  It’s getting every 
project to agree on a single approach and not getting bogged down with 
idealistics (like, “let’s build a dependency injection framework!”).Because 
this “everyone does it their own way” thing is crazy and has to stop.





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

Re: [openstack-dev] Can sqlalchemy-migrate-core just be oslo.db core?

[Thomas Goirand]

On 10/10/2014 06:10 PM, Ihar Hrachyshka wrote:
> On 09/10/14 23:44, Doug Hellmann wrote:
> 
>> On Oct 9, 2014, at 4:30 PM, Matt Riedemann
>>  wrote:
> 
>>> The sqlalchemy-migrate project is basically maintenance mode and
>>> the core team [1] is kind of a weird mix of people - all great
>>> people I'm sure, but I think it's more a team of people that
>>> stepped up when OpenStack took over the project and said they'd
>>> babysit it but it's pretty idle.
>>>
>>> Given we have oslo.db now, and sqlalchemy-migrate is all DB
>>> goodies, can we just have the oslo.db core team [2] own
>>> sqlalchemy-migrate now too?
>>>
>>> Here are the sqlalchemy-migrate open reviews:
>>>
>>> https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z
>>>
>>>
>>>
> [1] https://review.openstack.org/#/admin/groups/186,members
>>> [2] https://review.openstack.org/#/admin/groups/331,members
> 
>> If the oslo.db team wants to participate, that’s obviously fine,
>> but I don’t think we want to just add everyone in bulk. AIUI, the
>> team’s goal is to get the migration stuff in oslo.db working with
>> alembic so we can stop using sqlalchemy-migrate.
> 
> Till that time, we're left with the library used by multiple projects.
> I feel it's hard to get any review in meaningful time for the library,
> so if moving the library under the oslo.db tent will help it move, I'm
> both hands for that.
> 
> /Ihar

I'm not sure adding core reviewers would help, but I agree we have a
maintenance issue with sqlalchemy-migrate. I've seen useful patches
staging without core reviewer answers. I'm myself a core there, but I
don't think I have the needed level to do good reviews.

Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Dmitry Borodaenko]

+1 for both

On Fri, Oct 10, 2014 at 2:35 AM, Vladimir Kuklin 
wrote:

> Hi, Fuelers
>
> As you may have noticed our project is growing continuously. And this
> imposes a requirement of increasing amount of core reviewers. I would like
> to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core
> reviewers. As you know, they have been participating actively in
> development, design and code review of the majority of project components
> as long as being our topmost reviewers and contributors (#2 and #3) [1 and
> 2] (not to mention being just brilliant engineers and nice people).
>
> Please, reply to my message if you agree or disagree separately for Bogdan
> and Sergii (this is mandatory for existing core-reviewers).
>
> [1] http://stackalytics.com/report/contribution/fuel-library/90
> 
> [2] http://stackalytics.com/report/contribution/fuel-library/180
> 
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Vitaly Kramskikh]

+1

2014-10-10 16:35 GMT+07:00 Vladimir Kuklin :

> Hi, Fuelers
>
> As you may have noticed our project is growing continuously. And this
> imposes a requirement of increasing amount of core reviewers. I would like
> to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core
> reviewers. As you know, they have been participating actively in
> development, design and code review of the majority of project components
> as long as being our topmost reviewers and contributors (#2 and #3) [1 and
> 2] (not to mention being just brilliant engineers and nice people).
>
> Please, reply to my message if you agree or disagree separately for Bogdan
> and Sergii (this is mandatory for existing core-reviewers).
>
> [1] http://stackalytics.com/report/contribution/fuel-library/90
> 
> [2] http://stackalytics.com/report/contribution/fuel-library/180
> 
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Anastasia Urlapova]

+1 for both

On Fri, Oct 10, 2014 at 8:05 PM, Vitaly Kramskikh 
wrote:

> +1
>
> 2014-10-10 16:35 GMT+07:00 Vladimir Kuklin :
>
>> Hi, Fuelers
>>
>> As you may have noticed our project is growing continuously. And this
>> imposes a requirement of increasing amount of core reviewers. I would like
>> to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core
>> reviewers. As you know, they have been participating actively in
>> development, design and code review of the majority of project components
>> as long as being our topmost reviewers and contributors (#2 and #3) [1 and
>> 2] (not to mention being just brilliant engineers and nice people).
>>
>> Please, reply to my message if you agree or disagree separately for
>> Bogdan and Sergii (this is mandatory for existing core-reviewers).
>>
>> [1] http://stackalytics.com/report/contribution/fuel-library/90
>> 
>> [2] http://stackalytics.com/report/contribution/fuel-library/180
>> 
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 45bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Software Engineer,
> Mirantis, Inc.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] object field naming question

[Murray, Paul (HP Cloud)]

I think the hyphen question is settled – we can go with hv_type and vm_mode to 
be in line with the rest of nova.

Now for the other bit…

After this email thread and discussion in the IRC with those who expressed 
interest I have come to the following:

I will use the name supported_hv_specs instead of supported_instances in the 
ComputeNode object and HVSpec for the new object. So the field type of 
supported_hv_specs will be ListOfObjectsField(‘HVSpec’).

The supported_instances field in the compute_nodes table will be left as it is. 
This means that supported_hv_specs in ComputeNodes will map to the 
supported_instances field in the compute_nodes table.

Thanks for helping,
Paul




From: Paul Murray [mailto:ptma...@gmail.com]
Sent: 10 October 2014 13:00
To: Murray, Paul (HP Cloud)
Subject: Fwd: [openstack-dev] [Nova] object field naming question


-- Forwarded message --
From: Dan Smith mailto:d...@danplanet.com>>
Date: 9 October 2014 17:40
Subject: Re: [openstack-dev] [Nova] object field naming question
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>


> The value it adds (and that an underscore would add in hvtype ->
> hv_type) is that the name would match the naming style for the vast
> majority of everything else in OpenStack. See, for examples:

Agreed.

> As mentioned in the review, I disagree on this point, since "doing a
> cleanup afterwards" would mean having to increment the
> nova.objects.SupportedInstance model VERSION as soon as it went into
> master. I say let's make the quick change now and avoid having to write
> code like this in the next patchset:
>
>  if client_version <= (1,0):
> # We renamed hvtype to hv_type in 1.1
> self.hv_type = fields.get('hvtype')

Right, this becomes RPC debt if we think we might change it later. We
definitely want to get it right the first time whenever possible.

--Dan


___
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] [all] [oslo] Proposed database connectivity patterns

[Mike Bayer]

On Oct 10, 2014, at 11:41 AM, Mike Bayer  wrote:

> I’ve been asking a lot about “hey are people cool with thread locals?” and 
> have been waiting for what the concerns are.
> 
> Since I wrote that email I’ve shifted, and I’ve been considering only:
> 
> @sql.reader
> def my_api_method(context, …):
>   context.session
> 
> def my_api_method(context, …):
>  with sql.using_reader(context) as session:
>session , context.session
> 
> because in fact, if you *want* to use a thread local context, you can, 
> explicitly with the above:
> 
> GLOBAL_CONTEXT = threading.local()
> 
> def my_api_method(…):
>  with sql.using_reader(GLOBAL_CONTEXT) as session:
>session 
> 
> I like that one the best.  But again, Keystone folks would need to accept 
> this explicitness.
> 
> The challenge on my end is not technical in any way.  It’s getting every 
> project to agree on a single approach and not getting bogged down with 
> idealistics (like, “let’s build a dependency injection framework!”).
> Because this “everyone does it their own way” thing is crazy and has to stop.

I’ve now pushed these changes, as well as a summation of all the alternatives 
so far, to the latest release.  See https://review.openstack.org/#/c/125181/.



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

Re: [openstack-dev] [Nova][oslo] how to sync oslo.concurrency to nova?

[Chen CH Ji]

Thanks a lot for the info,

So, my understanding is I need to wait for its released then someone need
to change the code in
projects (e.g. nova) to switch from its original method
(nova/openstack/common/) to oslo.concurrency
just like we did for oslo.utils and other components nowadays?

thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Ben Nemec 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   10/10/2014 09:59 PM
Subject:Re: [openstack-dev] [Nova][oslo] how to sync oslo.concurrency
to nova?



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/10/2014 05:05 AM, Ihar Hrachyshka wrote:
> On 10/10/14 10:32, Chen CH Ji wrote:
>> There used to method in oslo-incubator like
>> https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator
>> or '_https://review.openstack.org/#/c/78429/_ ' we can use
>
>> however, I was told to submit patch to oslo.concurrency instead
>> of oslo-incubator, so what's the method can be used now ? Thanks
>> a lot
>
> With oslo.concurrency, you don't copy-paste code, you just reuse it
> as any other third-party library. So if your project is not yet
> using the library, just port it to it first, and once a new version
> of oslo.concurrency is released, you will get your change magically
> applied.

At this point oslo.concurrency hasn't been released yet so it won't be
possible to switch any projects to use it.  I think we're on track for
a first release early next week and once that has happened this will
be possible.

Note that we do have a stable branch of the incubator code that can be
used for important changes in projects that haven't yet ported to use
new libs, but when possible we'd rather just make the changes in the lib.

- -Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUN+bgAAoJEDehGd0Fy7uqjhMIANBPX4sTbVSnewoquF3Ih29z
Adxq6KpDymonhpnJuOqM1gKYsd/oyqa6q92WTt9F9c8XwALB1x9IzgUBRRixhts5
p4fDzNTMGJzlT9slnGjyNVD0i3AJ1UuO5+mZADDk3jXqqERmbeCo+BgYqJr7q08r
MmkPuo0EAZtWrY1+Isl1Eg3lz7P2DFC9kEmY8iUj5wObiqINU7L5MNCzCi7V+c8g
uxacoCSXcyTR7nnXcs9cPywthBTLOOqkY1IzEYk38vbnQSmvqKbbovqVB0ZCTueF
8g/WO2+jOhETsyFGY7d3HuOQDxJSx/JeXlpPfriOsxdcrDtmP3YMEgh2kpK0e7k=
=Puy/
-END PGP SIGNATURE-

___
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] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Vladimir Sharshov]

+1 for both

On Fri, Oct 10, 2014 at 8:09 PM, Anastasia Urlapova 
wrote:

> +1 for both
>
> On Fri, Oct 10, 2014 at 8:05 PM, Vitaly Kramskikh  > wrote:
>
>> +1
>>
>> 2014-10-10 16:35 GMT+07:00 Vladimir Kuklin :
>>
>>> Hi, Fuelers
>>>
>>> As you may have noticed our project is growing continuously. And this
>>> imposes a requirement of increasing amount of core reviewers. I would like
>>> to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as core
>>> reviewers. As you know, they have been participating actively in
>>> development, design and code review of the majority of project components
>>> as long as being our topmost reviewers and contributors (#2 and #3) [1 and
>>> 2] (not to mention being just brilliant engineers and nice people).
>>>
>>> Please, reply to my message if you agree or disagree separately for
>>> Bogdan and Sergii (this is mandatory for existing core-reviewers).
>>>
>>> [1] http://stackalytics.com/report/contribution/fuel-library/90
>>> 
>>> [2] http://stackalytics.com/report/contribution/fuel-library/180
>>> 
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 45bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Vitaly Kramskikh,
>> Software Engineer,
>> Mirantis, Inc.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Using 'admin_token' option as token to create keystone client.

[Nader Lahouti]

Thanks Lei.

On Thu, Oct 9, 2014 at 6:52 PM, Lei Zhang  wrote:

> Yes. That will be more safer.
>
> On Fri, Oct 10, 2014 at 12:00 AM, Nader Lahouti 
> wrote:
> > Thanks Lei for the reply and clarification.
> > So, instead of that we can use the following:
> >
> >
> > from keystone client.v2_0 import Client
> >
> > keystone = Client(username=user, password=password, tenant_name=tenant,
> > auth_url=url)
> >
> >
> > with user, password, tenant and url can be obtained from cfg.CONF.
> >
> >
> > Thanks,
> >
> > Nader.
> >
> >
> > On Wed, Oct 8, 2014 at 11:54 PM, Lei Zhang 
> wrote:
> >>
> >> it should works but it is not safe to use admin_token. Because
> >> * It is a admin token which has the full privilege for the keystone
> >> service
> >> * The token will be always valid till the admin_token in the conf file
> >> is changed.
> >>   It is dangerous when the token leak.
> >>
> >> Suggest that the admin_token is only used for the initial of admin
> >> account.
> >>
> >> On Thu, Oct 9, 2014 at 2:29 PM, Nader Lahouti 
> >> wrote:
> >> > Hi,
> >> >
> >> > Is it acceptable to use 'admin_token' option from keystone.conf,  when
> >> > creating a keystone client? something like this:
> >> >
> >> > kc = client.Client(token=cfg.CONF.admin_token,
> >> >
> >> >endpoint='http://localhost:35357/v2.0/')
> >> >
> >> >
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Nader.
> >> >
> >> >
> >> >
> >> > ___
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev@lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >>
> >>
> >> --
> >> Lei Zhang
> >> Blog: http://xcodest.me
> >> twitter/weibo: @jeffrey4l
> >>
> >> ___
> >> 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
> >
>
>
>
> --
> Lei Zhang
> Blog: http://xcodest.me
> twitter/weibo: @jeffrey4l
>
> ___
> 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] RSS feeds for gerrit projects

[Christian Berendt]

Is it possible to directly access RSS feeds for gerrit projects or is
the only way to do this to use a wrapper like openstackwatch in jeepyb?

Christian.

-- 
Christian Berendt
Cloud Solution Architect
Mail: bere...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

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

Re: [openstack-dev] [Glance] Granularity of policies

[Nikhil Komawar]

Eddie,

+1 on glance-spec

We might want to define the scope. How far are we diverging from Openstack 
policy structure? Are there any other use cases which need policy changes? - 
some questions which come to my mind.

Thanks,
-Nikhil

From: Eddie Sheffield [eddie.sheffi...@rackspace.com]
Sent: Monday, October 06, 2014 3:35 PM
To: OpenStack Dev List
Subject: [openstack-dev] [Glance] Granularity of policies

I encountered an interesting situation with Glance policies. Basically we have 
a situation where users in certain roles are not allowed to make certain calls 
at all. In this specific case, we don't want users in those roles listing or 
viewing members. When listing members, these users receive a 403 (Forbidden) 
but when showing an individual member the users receive 404 (Not Found).

So the problem is that there are a couple of situations here and we don't 
(can't?) distinguish the exact intent:

1) A user IS allowed to make the call but isn't allowed to see a particular 
member - in that case 404 makes sense because a 403 could imply the user 
actually is there, you just can't look see them directly.

2) A user IS NOT allowed to make the call at all. In this case a 403 makes more 
sense because the user is forbidden at the call level.

At this point I'm mainly trying to spark some conversation on this. This feels 
a bit inconsistent if users get 403 for a whole set of calls they are barred 
from but 404 for others which are "sub" calls of the others (e.g. listing 
members vs. showing a specific one.) But I don't have a specific proposals at 
this time - first I'm trying to find out if others feel this is a problem which 
should be addressed. If so I'm willing to work on a blueprint and 
implementation.

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

Re: [openstack-dev] [all] [oslo] Proposed database connectivity patterns

[Joshua Harlow]

On Oct 10, 2014, at 3:13 AM, Ihar Hrachyshka  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 09/10/14 21:29, Mike Bayer wrote:
>> So so far, everyone seems really positive and psyched about the
>> proposal.
>> 
>> It looks like providing some options for how to use would be best,
>> that is provide decorators and context managers.
>> 
>> Now the thing with the context manager, it can be as I stated:
>> 
>> with sql.reader() as session:
>> 
>> or we can even have that accept the “context”:
>> 
>> with sql.reader(context) as session:
>> 
>> The latter again avoids having to use thread locals.
>> 
>> But can I get a feel for how comfortable we are with using thread
>> local storage to implement this feature?   I had anticipated people
>> wouldn’t like it because it’s kind of a “global” object, even
>> though it will be hidden behind this facade (of course CONF is
>> global as is sys.modules, and I think it is fine). If I just
>> use a tlocal, this whole thing is pretty simple.
> 
> Won't the approach conflict with eventlet consumers that for some
> reason do not patch thread module, or do not patch it early enough? I
> guess in that case we may end up with mixed contexts.

Eck, this is not something people should be doing (not patching the thread 
module).

Example for why @ https://gist.github.com/harlowja/9c35e443dfa136a4f965 (run 
that and see your program lock up).

Once you accept/use eventlet, u shouldn't really be accepted half of it, 
otherwise there be dragons there; especially since openstack doesn't control 
what external library code does inside those libraries (and rightfully so it 
shouldn't), and if any library does anything like that gist code, the whole 
application will lock up...

> 
> /Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> 
> iQEcBAEBCgAGBQJUN7FeAAoJEC5aWaUY1u57sq0IANSM8gKCQZbgEY62uvyhZqzN
> 9gRDcFbTrH/yUNMv0tt3+e2vVEbn8VIatDWG4/OYghzuI1BerKzhP7JD5J+mV8yK
> sB0fc6ybHmz14T962LhFkAxWKybPW3sJO/0GIy606ty0OEV8QAgPwaYvjW596MUa
> BAp0IRAz4/MglT/M80OkT2jFdMV+a9SAFUKvnF/21KSGo/t4qcawA/+B0c3Ownle
> eYt+Auk3hcgJnZAvCOwy7bcAb1b12gonk4nIwMl/Mik8IKNR5fnl1IqTiISUO2Jw
> PV95/7muukSrt54lY+9u4SW9o/Zf/gaNCMmK3xfDmvMug6tk0SWzkzBZLva3wNc=
> =04Wx
> -END PGP SIGNATURE-
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?

[Vadivel Poonathan]

Hi,

How to include a new vendor plug-in (aka mechanism_driver in ML2 framework)
into the Openstack documentation?.. In other words, is it possible to
include a new plug-in in the Openstack documentation page without having
the actual plug-in code as part of the Openstack neutron repository?... The
actual plug-in is posted and available for the public to download as Ubuntu
package. But i need to mention somewhere in the Openstack documentation
that this new plugin is available for the public to use along with its
documentation.

Pls. provide some insights into whether it is possible?.. and any further
info on this?..

Thanks,

Vad

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

Re: [openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?

[Anne Gentle]

On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan <
vadivel.openst...@gmail.com> wrote:

> Hi,
>
> How to include a new vendor plug-in (aka mechanism_driver in ML2
> framework) into the Openstack documentation?.. In other words, is it
> possible to include a new plug-in in the Openstack documentation page
> without having the actual plug-in code as part of the Openstack neutron
> repository?... The actual plug-in is posted and available for the public to
> download as Ubuntu package. But i need to mention somewhere in the
> Openstack documentation that this new plugin is available for the public to
> use along with its documentation.
>

We definitely want you to include pointers to vendor documentation in the
OpenStack docs, but I'd prefer make sure they're gate tested before they
get listed on docs.openstack.org. Drivers change enough release-to-release
that it's difficult to keep up maintenance.

Lately I've been talking to driver contributors (hypervisor, storage,
networking) about the out-of-tree changes possible. I'd like to encourage
even out-of-tree drivers to get listed, but to store their main documents
outside of docs.openstack.org, if they are gate-tested.

Anyone have other ideas here?

Looping in the OpenStack-docs mailing list also.
Anne



> Pls. provide some insights into whether it is possible?.. and any further
> info on this?..
>
> Thanks,
>
> Vad
>
> --
>
> ___
> 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] [all] [oslo] Proposed database connectivity patterns

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/10/14 20:21, Joshua Harlow wrote:
> On Oct 10, 2014, at 3:13 AM, Ihar Hrachyshka 
> wrote:
> 
> On 09/10/14 21:29, Mike Bayer wrote:
 So so far, everyone seems really positive and psyched about
 the proposal.
 
 It looks like providing some options for how to use would be
 best, that is provide decorators and context managers.
 
 Now the thing with the context manager, it can be as I
 stated:
 
 with sql.reader() as session:
 
 or we can even have that accept the “context”:
 
 with sql.reader(context) as session:
 
 The latter again avoids having to use thread locals.
 
 But can I get a feel for how comfortable we are with using
 thread local storage to implement this feature?   I had
 anticipated people wouldn’t like it because it’s kind of a
 “global” object, even though it will be hidden behind this
 facade (of course CONF is global as is sys.modules, and I
 think it is fine). If I just use a tlocal, this whole
 thing is pretty simple.
> 
> Won't the approach conflict with eventlet consumers that for some 
> reason do not patch thread module, or do not patch it early enough?
> I guess in that case we may end up with mixed contexts.
> 
>> Eck, this is not something people should be doing (not patching
>> the thread module).
> 
>> Example for why @
>> https://gist.github.com/harlowja/9c35e443dfa136a4f965 (run that
>> and see your program lock up).
> 
>> Once you accept/use eventlet, u shouldn't really be accepted half
>> of it, otherwise there be dragons there; especially since
>> openstack doesn't control what external library code does inside
>> those libraries (and rightfully so it shouldn't), and if any
>> library does anything like that gist code, the whole application
>> will lock up...

Real life sucks. In Neutron, we have at least two files that patch
only some modules (though all of them patch threading). [Not that I
mean that those files should not patch the whole library set; I have
no defined view on the matter.]

Though I agree that consumers with some modules unpatched are not
something that should be seriosly considered, we're still left with
consumers that do not patch their libraries early enough. We had an
issue with tlocal when porting Neutron to oslo.messaging that resulted
in the following patch: https://review.openstack.org/#/c/96791/ The
issue showed up in very weird way hard to debug, so if possible, I
would try to avoid similar situations with oslo.db.

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUODkZAAoJEC5aWaUY1u57QrcIANLtMi1jRrfHnwV2xnwYGPOl
QwZWDG6i/cdnzqrwGz+0chqRxu4KWZB5gAfMR4/ralHvGGbaa1vGp9wtzsfIJTB1
RuyE7XKXUX4rU3WoAOB7F3uF1WzFpI8ourunBG4OCE0t0YT89z9mCLfOTZNNKGxH
OE89n4pnyMd3GXGtoxVINyA6pqQotYuHKG6o6LbhmTZ1UoL3P3rO+Onb1Ma2BF6Z
VO84smdMnOC3yVtv4TGwrW5iBoU3RwOqxooOg4g5Jam6D++kzCKrPT9wdY7TNe+C
A6IvMlad0RbygkhrLyWIWXaqCAg5VzzDvk4z6dywVkmoWS7V861mjiV4unbr0X8=
=5ovh
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Nova][oslo] how to sync oslo.concurrency to nova?

[Doug Hellmann]

On Oct 10, 2014, at 12:36 PM, Chen CH Ji  wrote:

> Thanks a lot for the info, 
> 
> So, my understanding is I need to wait for its released then someone need to 
> change the code in 
> projects (e.g. nova) to switch from its original method 
> (nova/openstack/common/) to oslo.concurrency 
> just like we did for oslo.utils and other components nowadays?
> 

Yes, that’s correct.

Doug

> 
> thanks 
> 
> Best Regards! 
> 
> Kevin (Chen) Ji 纪 晨
> 
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
> Phone: +86-10-82454158
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, 
> Beijing 100193, PRC 
> 
> Ben Nemec ---10/10/2014 09:59:16 PMBEGIN PGP SIGNED 
> MESSAGE- Hash: SHA1
> 
> From: Ben Nemec 
> To:   "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 10/10/2014 09:59 PM
> Subject:  Re: [openstack-dev] [Nova][oslo] how to sync oslo.concurrency 
> to nova?
> 
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/10/2014 05:05 AM, Ihar Hrachyshka wrote:
> > On 10/10/14 10:32, Chen CH Ji wrote:
> >> There used to method in oslo-incubator like 
> >> https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator 
> >> or '_https://review.openstack.org/#/c/78429/_ ' we can use
> > 
> >> however, I was told to submit patch to oslo.concurrency instead
> >> of oslo-incubator, so what's the method can be used now ? Thanks
> >> a lot
> > 
> > With oslo.concurrency, you don't copy-paste code, you just reuse it
> > as any other third-party library. So if your project is not yet
> > using the library, just port it to it first, and once a new version
> > of oslo.concurrency is released, you will get your change magically
> > applied.
> 
> At this point oslo.concurrency hasn't been released yet so it won't be
> possible to switch any projects to use it.  I think we're on track for
> a first release early next week and once that has happened this will
> be possible.
> 
> Note that we do have a stable branch of the incubator code that can be
> used for important changes in projects that haven't yet ported to use
> new libs, but when possible we'd rather just make the changes in the lib.
> 
> - -Ben
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJUN+bgAAoJEDehGd0Fy7uqjhMIANBPX4sTbVSnewoquF3Ih29z
> Adxq6KpDymonhpnJuOqM1gKYsd/oyqa6q92WTt9F9c8XwALB1x9IzgUBRRixhts5
> p4fDzNTMGJzlT9slnGjyNVD0i3AJ1UuO5+mZADDk3jXqqERmbeCo+BgYqJr7q08r
> MmkPuo0EAZtWrY1+Isl1Eg3lz7P2DFC9kEmY8iUj5wObiqINU7L5MNCzCi7V+c8g
> uxacoCSXcyTR7nnXcs9cPywthBTLOOqkY1IzEYk38vbnQSmvqKbbovqVB0ZCTueF
> 8g/WO2+jOhETsyFGY7d3HuOQDxJSx/JeXlpPfriOsxdcrDtmP3YMEgh2kpK0e7k=
> =Puy/
> -END PGP SIGNATURE-
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?

[Vadivel Poonathan]

Hi Anne,

Thanks for your immediate response!...

Just to clarify... I have developed and maintaining a Neutron plug-in (ML2
mechanism_driver) since Grizzly and now it is up-to-date with Icehouse. But
it was never listed nor part of the main Openstack releases. Now i would
like to have my plugin mentioned as "supported plugin/mechanism_driver for
so and so vendor equipments" in the docs.openstack.org, but without having
the actual plugin code to be posted in the main Openstack GIT repository.

Reason is that I dont have plan/bandwidth to go thru the entire process of
new plugin blue-print/development/review/testing etc as required by the
Openstack development community. Bcos this is already developed, tested and
released to some customers directly. Now I just want to get it to the
official Openstack documentation, so that more people can get this and use.

The plugin package is made available to public from Ubuntu repository along
with necessary documentation. So people can directly get it from Ubuntu
repository and use it. All i need is to get listed in the docs.openstack.org
so that people knows that it exists and can be used with any Openstack.

Pls. confrim whether this is something possible?...

Thanks again!..

Vad
--

On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle  wrote:

>
>
> On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan <
> vadivel.openst...@gmail.com> wrote:
>
>> Hi,
>>
>> How to include a new vendor plug-in (aka mechanism_driver in ML2
>> framework) into the Openstack documentation?.. In other words, is it
>> possible to include a new plug-in in the Openstack documentation page
>> without having the actual plug-in code as part of the Openstack neutron
>> repository?... The actual plug-in is posted and available for the public to
>> download as Ubuntu package. But i need to mention somewhere in the
>> Openstack documentation that this new plugin is available for the public to
>> use along with its documentation.
>>
>
> We definitely want you to include pointers to vendor documentation in the
> OpenStack docs, but I'd prefer make sure they're gate tested before they
> get listed on docs.openstack.org. Drivers change enough
> release-to-release that it's difficult to keep up maintenance.
>
> Lately I've been talking to driver contributors (hypervisor, storage,
> networking) about the out-of-tree changes possible. I'd like to encourage
> even out-of-tree drivers to get listed, but to store their main documents
> outside of docs.openstack.org, if they are gate-tested.
>
> Anyone have other ideas here?
>
> Looping in the OpenStack-docs mailing list also.
> Anne
>
>
>
>> Pls. provide some insights into whether it is possible?.. and any further
>> info on this?..
>>
>> Thanks,
>>
>> Vad
>>
>> --
>>
>> ___
>> 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] [oslo] Meeting time

[Doug Hellmann]

On Oct 8, 2014, at 10:19 AM, Doug Hellmann  wrote:

> 
> On Oct 8, 2014, at 5:20 AM, Julien Danjou  wrote:
> 
>> On Tue, Oct 07 2014, Roman Podoliaka wrote:
>> 
>>> - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3
>>> - Thursdays at 1600 UTC [2]: #openstack-meeting-3
>> 
>> One of these would be cool.
>> 
>> -- 
>> Julien Danjou
>> -- Free Software hacker
>> -- http://julien.danjou.info
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> I think we’re converging, but let’s do this with doodle instead of spamming 
> the dev list.
> 
> Please vote here: http://doodle.com/zv8izg7ymxcank34
> 
> Doug

The survey results indicate a clear preference for the Monday 16:00 UTC time 
slot, so I’ve updated 
https://wiki.openstack.org/wiki/Meetings#Oslo_Team_meeting to reflect that.

We will skip meeting the Monday right after the summit on the assumption we 
will have nothing new to say to one another after spending a week together. :-)

The first date for the new meeting time will be Monday 17 Nov 2014. We will 
keep the same meeting room, #openstack-meeting-alt.

Until then let's continue to meet on Fridays.

Doug


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

Re: [openstack-dev] RSS feeds for gerrit projects

[Jeremy Stanley]

On 2014-10-10 19:15:33 +0200 (+0200), Christian Berendt wrote:
> Is it possible to directly access RSS feeds for gerrit projects or
> is the only way to do this to use a wrapper like openstackwatch in
> jeepyb?

As far as I can tell, Gerrit has no RSS feature yet[1].

An OSW instance was added to review.openstack.org mainly as a
proof-of-concept[2], but the RSS files[3] seem to have ceased
updating roughly 6 months ago so probably broken by the Gerrit
upgrade. Clearly nobody was using it in that time, but if there's
renewed interest then I doubt the infra team would refuse patches to
get it back into working order.

[1] http://code.google.com/p/gerrit/issues/detail?id=561
[2] 
http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/manifests/gerrit.pp#n78
[3] http://rss.cdn.openstack.org/nova.xml
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Group-based Policy] Database migration chain

[Robert Kukura]

On 10/7/14 6:36 PM, Ivar Lazzaro wrote:
I posted a patch that implements the "Different DB Different Chain" 
approach [0].
That does not mean that this approach is the chosen one! It's just to 
have a grasp of what the change looks like.


The "Same DB different chain" solution is much simpler to implement 
(basically you just specify a different version table in the alembic 
environment) so I haven't posted anything for that.


One thing I'm particularly interested about is to hear packagers 
opinions about which approach would be the preferred one: Same DB or 
Different?
It seems to me that deployment tools such as puppet scripts would also 
be simpler if the GBP service plugin used the neutron DB, as there would 
be no need to create a separate DB, set its permissions, put its URL 
into neutron's config file, etc.. All that would be needed at deployment 
time is to run the additional gbp-db-manage tool to perform the GBP DB 
migrations. Am I missing anything?


With dependencies only in one direction, and the foreign keys GBP 
depends on (neutron resource IDs) unlikely to be changed by neutron 
migrations during Kilo, I don't think we need to worry about 
interleaving GBP migrations with neutron migrations. On initial 
deployments or version upgrades, it should be sufficient to run 
gbp-db-manage after neutron-db-manage. On downgrades, some situations 
might require running gbp-db-manage before neutron-db-manage. This seems 
not to be effected by whether the two migration chains are in the same 
DB/schema or different ones.
Also, on the line of Bob's comment in my patch, is there any kind of 
compatibility or performance issue anyone is aware of about in using 
cross schema FKs?
In addition to compatibility and performance, I'm also concerned about 
DB connection management when the same server is using multiple 
connection URLs. I'm not convinced the approach in the patch is 
sufficient. At least with some DBs, wouldn't we we need a separate 
sqlalchemy.create_engine() call with each DB's connection URL, which 
might require using separate context and session objects rather than the 
ones neutron uses?


-Bob


Thanks,
Ivar.

[0] https://review.openstack.org/#/c/126383/

On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro > wrote:


I believe Group-based Policy (which this thread is about) will
use the Neutron
database configuration for its dependent database.

If Neutron is configured for:
connection = mysql://user:pass@locationX:3306/neutron
then GBP would use:
connection = mysql://user:pass@locationX:3306/neutron_gbp


That's correct, that would be the likely approach if we go with
the "different schema" route.

if you can get the “other database” to be accessible from the
target database via “otherdatabase.sometable”, then you’re in.
from SQLAlchemy’s perspective, it’s just a name with a dot.  
It’s the database itself that has to support the foreign key

at the scope you are shooting for.


I'm experimenting this approach with our code and it seems to be
the case. '
I feel that having the constraint of pointing the same database
connection with a different schema is pretty acceptable given how
tight is GBP to Neutron.

On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau mailto:ges...@cisco.com>> wrote:

Clint Byrum mailto:cl...@fewbar.com>> wrote:
>
> Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:
>>
>> On Oct 4, 2014, at 1:10 AM, Kevin Benton mailto:blak...@gmail.com>> wrote:
>>
>>> Does sqlalchemy have good support for cross-database
foreign keys? I was under the impression that they cannot be
implemented with the normal syntax and semantics of an
intra-database foreign-key constraint.
>>
>> cross “database” is not typically portable, but cross
“schema” is.
>>
>> different database vendors have different notions of
“databases” or “schemas”.
>>
>> if you can get the “other database” to be accessible from
the target database via “otherdatabase.sometable”, then you’re in.
>>
>> from SQLAlchemy’s perspective, it’s just a name with a
dot.   It’s the database itself that has to support the
foreign key at the scope you are shooting for.
>>
>
> All true, however, there are zero guarantees that databases
will be
> hosted on the same server, and typically permissions are
setup to prevent
> cross-schema joins.

I believe Group-based Policy (which this thread is about) will
use the Neutron
database configuration for its dependent database.

If Neutron is configured for:
  connection = mysql://user:pass@locationX:3306/neutron
then GBP would use:
  connecti

Re: [openstack-dev] [Group-based Policy] Database migration chain

[Ivar Lazzaro]

>
> It seems to me that deployment tools such as puppet scripts would also be
> simpler if the GBP service plugin used the neutron DB, as there would be no
> need to create a separate DB, set its permissions, put its URL into
> neutron's config file, etc.. All that would be needed at deployment time is
> to run the additional gbp-db-manage tool to perform the GBP DB migrations.
> Am I missing anything?
>
>
That's correct, being a new schema it needs to be created, the access
granted, and the connection URL configured in neutron.conf (doable also
with devstack in the extra-conf option).


> With dependencies only in one direction, and the foreign keys GBP depends
> on (neutron resource IDs) unlikely to be changed by neutron migrations
> during Kilo, I don't think we need to worry about interleaving GBP
> migrations with neutron migrations. On initial deployments or version
> upgrades, it should be sufficient to run gbp-db-manage after
> neutron-db-manage. On downgrades, some situations might require running
> gbp-db-manage before neutron-db-manage. This seems not to be effected by
> whether the two migration chains are in the same DB/schema or different
> ones.
>

That's correct too. Also, this is true for the downgrade even with a
different schema.


> In addition to compatibility and performance, I'm also concerned about DB
> connection management when the same server is using multiple connection
> URLs. I'm not convinced the approach in the patch is sufficient. At least
> with some DBs, wouldn't we we need a separate sqlalchemy.create_engine()
> call with each DB's connection URL, which might require using separate
> context and session objects rather than the ones neutron uses?


That should not be the case. We are not using a separate DB connection. The
connection is in fact the same, the only thing that changes is the schema.
For the sql engine this  should be only a matter of namespacing (different
schema -> different namespace), therefore I don't see any relevant
performance/connection/greenthread issue.
However I'm no DBMS expert, any additional feedback on this matter is
welcome.

Ivar.

On Fri, Oct 10, 2014 at 2:59 PM, Robert Kukura 
wrote:

>
> On 10/7/14 6:36 PM, Ivar Lazzaro wrote:
>
> I posted a patch that implements the "Different DB Different Chain"
> approach [0].
> That does not mean that this approach is the chosen one! It's just to have
> a grasp of what the change looks like.
>
>  The "Same DB different chain" solution is much simpler to implement
> (basically you just specify a different version table in the alembic
> environment) so I haven't posted anything for that.
>
>  One thing I'm particularly interested about is to hear packagers
> opinions about which approach would be the preferred one: Same DB or
> Different?
>
> It seems to me that deployment tools such as puppet scripts would also be
> simpler if the GBP service plugin used the neutron DB, as there would be no
> need to create a separate DB, set its permissions, put its URL into
> neutron's config file, etc.. All that would be needed at deployment time is
> to run the additional gbp-db-manage tool to perform the GBP DB migrations.
> Am I missing anything?
>
> With dependencies only in one direction, and the foreign keys GBP depends
> on (neutron resource IDs) unlikely to be changed by neutron migrations
> during Kilo, I don't think we need to worry about interleaving GBP
> migrations with neutron migrations. On initial deployments or version
> upgrades, it should be sufficient to run gbp-db-manage after
> neutron-db-manage. On downgrades, some situations might require running
> gbp-db-manage before neutron-db-manage. This seems not to be effected by
> whether the two migration chains are in the same DB/schema or different
> ones.
>
>  Also, on the line of Bob's comment in my patch, is there any kind of
> compatibility or performance issue anyone is aware of about in using cross
> schema FKs?
>
> In addition to compatibility and performance, I'm also concerned about DB
> connection management when the same server is using multiple connection
> URLs. I'm not convinced the approach in the patch is sufficient. At least
> with some DBs, wouldn't we we need a separate sqlalchemy.create_engine()
> call with each DB's connection URL, which might require using separate
> context and session objects rather than the ones neutron uses?
>
> -Bob
>
>
>  Thanks,
> Ivar.
>
>  [0] https://review.openstack.org/#/c/126383/
>
> On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro 
> wrote:
>
>>  I believe Group-based Policy (which this thread is about) will use the
>>> Neutron
>>> database configuration for its dependent database.
>>>
>>> If Neutron is configured for:
>>>   connection = mysql://user:pass@locationX:3306/neutron
>>> then GBP would use:
>>>   connection = mysql://user:pass@locationX:3306/neutron_gbp
>>
>>
>>  That's correct, that would be the likely approach if we go with the
>> "different schema" route.
>>
>>  if you can get the “oth

Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!

[Nick Chase]

On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli 
wrote:

>
> >  4. Send e-mail to reviewers network...@openstacknow.com.
>
> Why not use the docs mailing list or other facilities on @openstack.org?


We've now switched over to use the [networking] topic on the openstack-docs
list.  So anybody who's interested in following the discussions, please
feel free to join us.

Thanks!

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

Re: [openstack-dev] Neutron documentation to update about new vendor plugin, but without code in repository?

[Kevin Benton]

I think you will probably have to wait until after the summit so we can see
the direction that will be taken with the rest of the in-tree
drivers/plugins. It seems like we are moving towards removing all of them
so we would definitely need a solution to documenting out-of-tree drivers
as you suggested.

However, I think the minimum requirements for having a driver being
documented should be third-party testing of Neutron patches. Otherwise the
docs will become littered with a bunch of links to drivers/plugins with no
indication of what actually works, which ultimately makes Neutron look bad.

On Fri, Oct 10, 2014 at 1:28 PM, Vadivel Poonathan <
vadivel.openst...@gmail.com> wrote:

> Hi Anne,
>
> Thanks for your immediate response!...
>
> Just to clarify... I have developed and maintaining a Neutron plug-in (ML2
> mechanism_driver) since Grizzly and now it is up-to-date with Icehouse. But
> it was never listed nor part of the main Openstack releases. Now i would
> like to have my plugin mentioned as "supported plugin/mechanism_driver for
> so and so vendor equipments" in the docs.openstack.org, but without
> having the actual plugin code to be posted in the main Openstack GIT
> repository.
>
> Reason is that I dont have plan/bandwidth to go thru the entire process of
> new plugin blue-print/development/review/testing etc as required by the
> Openstack development community. Bcos this is already developed, tested and
> released to some customers directly. Now I just want to get it to the
> official Openstack documentation, so that more people can get this and use.
>
> The plugin package is made available to public from Ubuntu repository
> along with necessary documentation. So people can directly get it from
> Ubuntu repository and use it. All i need is to get listed in the
> docs.openstack.org so that people knows that it exists and can be used
> with any Openstack.
>
> Pls. confrim whether this is something possible?...
>
> Thanks again!..
>
> Vad
> --
>
> On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle  wrote:
>
>>
>>
>> On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan <
>> vadivel.openst...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> How to include a new vendor plug-in (aka mechanism_driver in ML2
>>> framework) into the Openstack documentation?.. In other words, is it
>>> possible to include a new plug-in in the Openstack documentation page
>>> without having the actual plug-in code as part of the Openstack neutron
>>> repository?... The actual plug-in is posted and available for the public to
>>> download as Ubuntu package. But i need to mention somewhere in the
>>> Openstack documentation that this new plugin is available for the public to
>>> use along with its documentation.
>>>
>>
>> We definitely want you to include pointers to vendor documentation in the
>> OpenStack docs, but I'd prefer make sure they're gate tested before they
>> get listed on docs.openstack.org. Drivers change enough
>> release-to-release that it's difficult to keep up maintenance.
>>
>> Lately I've been talking to driver contributors (hypervisor, storage,
>> networking) about the out-of-tree changes possible. I'd like to encourage
>> even out-of-tree drivers to get listed, but to store their main documents
>> outside of docs.openstack.org, if they are gate-tested.
>>
>> Anyone have other ideas here?
>>
>> Looping in the OpenStack-docs mailing list also.
>> Anne
>>
>>
>>
>>> Pls. provide some insights into whether it is possible?.. and any
>>> further info on this?..
>>>
>>> Thanks,
>>>
>>> Vad
>>>
>>> --
>>>
>>> ___
>>> 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
>
>


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

[openstack-dev] Any ideas on why nova-novncproxy is failing to start on devstack?

[Paul Michali (pcm)]

I had a system with devstack, which I restack with reclone, with the intention 
of then patching in my review diffs to update and test. Well, the stack is 
failing in n-nonvc, with this message:

openstack@devstack-33:~/devstack$ /usr/local/bin/nova-novncproxy --config-file 
/etc/nova/nova.conf --web /opt/stack/noVNC & echo $! 
>/opt/stack/status/stack/n-novnc.pid; fg || echo "n-novnc failed to start" | 
tee "/opt/stack/status/stack/n-novnc.failure"
[1] 826
/usr/local/bin/nova-novncproxy --config-file /etc/nova/nova.conf --web 
/opt/stack/noVNC
Traceback (most recent call last):
  File "/usr/local/bin/nova-novncproxy", line 6, in 
from nova.cmd.novncproxy import main
  File "/opt/stack/nova/nova/cmd/novncproxy.py", line 29, in 
from nova.console import websocketproxy
  File "/opt/stack/nova/nova/console/websocketproxy.py", line 110, in 
websockify.ProxyRequestHandler):
AttributeError: 'module' object has no attribute 'ProxyRequestHandler'
n-novnc failed to start

The websockify package is installed:

openstack@devstack-33:~/devstack$ pip show websockify
---
Name: websockify
Version: 0.5.1
Location: /usr/local/lib/python2.7/dist-packages
Requires: numpy

However, the version required is:

openstack@devstack-33:/opt/stack/nova$ grep websockify requirements.txt
websockify>=0.6.0,<0.7

Any ideas why is does not have the right version and how to best correct?

Thanks!


PCM (Paul Michali)

MAIL …..…. p...@cisco.com
IRC ……..… pcm_ (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83





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] [OpenStack-docs] Neutron documentation to update about new vendor plugin, but without code in repository?

[Edgar Magana]

Hi,

IMHO we should have a proper way to reference external vendor specific 
plugins/drivers mostly because at least in Neutron we are considering to move 
ALL vendor specific code out-of-tree, again it is just a consideration not a 
fact.

So, having a place holder for that will make sense.

Thanks,

Edgar

From: Anne Gentle mailto:a...@openstack.org>>
Date: Friday, October 10, 2014 at 12:18 PM
To: 
"OpenStack-dev@lists.openstack.org" 
mailto:OpenStack-dev@lists.openstack.org>>
Cc: 
"openstack-d...@lists.openstack.org" 
mailto:openstack-d...@lists.openstack.org>>
Subject: Re: [OpenStack-docs] [openstack-dev] Neutron documentation to update 
about new vendor plugin, but without code in repository?



On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan 
mailto:vadivel.openst...@gmail.com>> wrote:

Hi,

How to include a new vendor plug-in (aka mechanism_driver in ML2 framework) 
into the Openstack documentation?.. In other words, is it possible to include a 
new plug-in in the Openstack documentation page without having the actual 
plug-in code as part of the Openstack neutron repository?... The actual plug-in 
is posted and available for the public to download as Ubuntu package. But i 
need to mention somewhere in the Openstack documentation that this new plugin 
is available for the public to use along with its documentation.

We definitely want you to include pointers to vendor documentation in the 
OpenStack docs, but I'd prefer make sure they're gate tested before they get 
listed on docs.openstack.org. Drivers change enough 
release-to-release that it's difficult to keep up maintenance.

Lately I've been talking to driver contributors (hypervisor, storage, 
networking) about the out-of-tree changes possible. I'd like to encourage even 
out-of-tree drivers to get listed, but to store their main documents outside of 
docs.openstack.org, if they are gate-tested.

Anyone have other ideas here?

Looping in the OpenStack-docs mailing list also.
Anne



Pls. provide some insights into whether it is possible?.. and any further info 
on this?..

Thanks,

Vad

--

___
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] Any ideas on why nova-novncproxy is failing to start on devstack?

[Paul Michali (pcm)]

Well, I deleted /usr/local/lib/python2.7/dist-packages/websockify* and then 
stacked and it worked!


PCM (Paul Michali)

MAIL …..…. p...@cisco.com
IRC ……..… pcm_ (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



On Oct 10, 2014, at 8:46 PM, Paul Michali (pcm)  wrote:

> I had a system with devstack, which I restack with reclone, with the 
> intention of then patching in my review diffs to update and test. Well, the 
> stack is failing in n-nonvc, with this message:
> 
> openstack@devstack-33:~/devstack$ /usr/local/bin/nova-novncproxy 
> --config-file /etc/nova/nova.conf --web /opt/stack/noVNC & echo $! 
> >/opt/stack/status/stack/n-novnc.pid; fg || echo "n-novnc failed to start" | 
> tee "/opt/stack/status/stack/n-novnc.failure"
> [1] 826
> /usr/local/bin/nova-novncproxy --config-file /etc/nova/nova.conf --web 
> /opt/stack/noVNC
> Traceback (most recent call last):
>  File "/usr/local/bin/nova-novncproxy", line 6, in 
>from nova.cmd.novncproxy import main
>  File "/opt/stack/nova/nova/cmd/novncproxy.py", line 29, in 
>from nova.console import websocketproxy
>  File "/opt/stack/nova/nova/console/websocketproxy.py", line 110, in 
>websockify.ProxyRequestHandler):
> AttributeError: 'module' object has no attribute 'ProxyRequestHandler'
> n-novnc failed to start
> 
> The websockify package is installed:
> 
> openstack@devstack-33:~/devstack$ pip show websockify
> ---
> Name: websockify
> Version: 0.5.1
> Location: /usr/local/lib/python2.7/dist-packages
> Requires: numpy
> 
> However, the version required is:
> 
> openstack@devstack-33:/opt/stack/nova$ grep websockify requirements.txt
> websockify>=0.6.0,<0.7
> 
> Any ideas why is does not have the right version and how to best correct?
> 
> Thanks!
> 
> 
> PCM (Paul Michali)
> 
> MAIL …..…. p...@cisco.com
> IRC ……..… pcm_ (irc.freenode.com)
> TW ………... @pmichali
> GPG Key … 4525ECC253E31A83
> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
> 
> 
> 



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] [oslo] Proposed database connectivity patterns

[Joshua Harlow]

On Oct 10, 2014, at 12:52 PM, Ihar Hrachyshka  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 10/10/14 20:21, Joshua Harlow wrote:
>> On Oct 10, 2014, at 3:13 AM, Ihar Hrachyshka 
>> wrote:
>> 
>> On 09/10/14 21:29, Mike Bayer wrote:
> So so far, everyone seems really positive and psyched about
> the proposal.
> 
> It looks like providing some options for how to use would be
> best, that is provide decorators and context managers.
> 
> Now the thing with the context manager, it can be as I
> stated:
> 
> with sql.reader() as session:
> 
> or we can even have that accept the “context”:
> 
> with sql.reader(context) as session:
> 
> The latter again avoids having to use thread locals.
> 
> But can I get a feel for how comfortable we are with using
> thread local storage to implement this feature?   I had
> anticipated people wouldn’t like it because it’s kind of a
> “global” object, even though it will be hidden behind this
> facade (of course CONF is global as is sys.modules, and I
> think it is fine). If I just use a tlocal, this whole
> thing is pretty simple.
>> 
>> Won't the approach conflict with eventlet consumers that for some 
>> reason do not patch thread module, or do not patch it early enough?
>> I guess in that case we may end up with mixed contexts.
>> 
>>> Eck, this is not something people should be doing (not patching
>>> the thread module).
>> 
>>> Example for why @
>>> https://gist.github.com/harlowja/9c35e443dfa136a4f965 (run that
>>> and see your program lock up).
>> 
>>> Once you accept/use eventlet, u shouldn't really be accepted half
>>> of it, otherwise there be dragons there; especially since
>>> openstack doesn't control what external library code does inside
>>> those libraries (and rightfully so it shouldn't), and if any
>>> library does anything like that gist code, the whole application
>>> will lock up...
> 
> Real life sucks. In Neutron, we have at least two files that patch
> only some modules (though all of them patch threading). [Not that I
> mean that those files should not patch the whole library set; I have
> no defined view on the matter.]
> 

Yup it does, and once u accept eventlet it starts to become hard to get off 
it...

It's 'viral', and for better or worse openstack has got the virus... So that 
means everything that openstack touches/uses also needs to be compatible with 
that virus... It's to bad guido just didn't accept eventlet/greenlet into 
mainline python, that would of made our job easier (and then added a python 
option or something like `python -g` that turns on greenthreading by default 
when the interpreter is started up)...

Thats the crappy part with anything that monkey patches all the things, its not 
so easy to accept half of a monkey...

> Though I agree that consumers with some modules unpatched are not
> something that should be seriosly considered, we're still left with
> consumers that do not patch their libraries early enough. We had an
> issue with tlocal when porting Neutron to oslo.messaging that resulted
> in the following patch: https://review.openstack.org/#/c/96791/ The
> issue showed up in very weird way hard to debug, so if possible, I
> would try to avoid similar situations with oslo.db.

I'm unsure on this one, I don't think we should be making oslo.* that succumbs 
to the same eventlet virus just because openstack projects aren't correctly 
using eventlet. The same bug that was found in oslo.messaging could of been any 
third part library that wasn't imported in the right order in all honesty. So 
it seems like we should fix the projects (as in that review) instead of making 
the oslo.* libraries less future compatible... If eventlet/greenlet got merged 
into mainline python then I'd say probably say the reverse, but it didn't.

> 
> /Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> 
> iQEcBAEBCgAGBQJUODkZAAoJEC5aWaUY1u57QrcIANLtMi1jRrfHnwV2xnwYGPOl
> QwZWDG6i/cdnzqrwGz+0chqRxu4KWZB5gAfMR4/ralHvGGbaa1vGp9wtzsfIJTB1
> RuyE7XKXUX4rU3WoAOB7F3uF1WzFpI8ourunBG4OCE0t0YT89z9mCLfOTZNNKGxH
> OE89n4pnyMd3GXGtoxVINyA6pqQotYuHKG6o6LbhmTZ1UoL3P3rO+Onb1Ma2BF6Z
> VO84smdMnOC3yVtv4TGwrW5iBoU3RwOqxooOg4g5Jam6D++kzCKrPT9wdY7TNe+C
> A6IvMlad0RbygkhrLyWIWXaqCAg5VzzDvk4z6dywVkmoWS7V861mjiV4unbr0X8=
> =5ovh
> -END PGP SIGNATURE-
> 
> ___
> 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 documentation to update about new vendor plugin, but without code in repository?

[Anne Gentle]

On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton  wrote:

> I think you will probably have to wait until after the summit so we can
> see the direction that will be taken with the rest of the in-tree
> drivers/plugins. It seems like we are moving towards removing all of them
> so we would definitely need a solution to documenting out-of-tree drivers
> as you suggested.
>
> However, I think the minimum requirements for having a driver being
> documented should be third-party testing of Neutron patches. Otherwise the
> docs will become littered with a bunch of links to drivers/plugins with no
> indication of what actually works, which ultimately makes Neutron look bad.
>

This is my line of thinking as well, expanded to "ultimately makes
OpenStack docs look bad" -- a perception I want to avoid.

Keep the viewpoints coming. We have a crucial balancing act ahead: users
need to trust docs and trust the drivers. Ultimately the responsibility for
the docs is in the hands of the driver contributors so it seems those
should be on a domain name where drivers control publishing and OpenStack
docs are not a gatekeeper, quality checker, reviewer, or publisher.

We have documented the status of hypervisor drivers on an OpenStack wiki
page. [1] To me, that type of list could be maintained on the wiki page
better than in the docs themselves. Thoughts? Feelings? More discussion,
please. And thank you for the responses so far.
Anne

[1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix


>
> On Fri, Oct 10, 2014 at 1:28 PM, Vadivel Poonathan <
> vadivel.openst...@gmail.com> wrote:
>
>> Hi Anne,
>>
>> Thanks for your immediate response!...
>>
>> Just to clarify... I have developed and maintaining a Neutron plug-in
>> (ML2 mechanism_driver) since Grizzly and now it is up-to-date with
>> Icehouse. But it was never listed nor part of the main Openstack releases.
>> Now i would like to have my plugin mentioned as "supported
>> plugin/mechanism_driver for so and so vendor equipments" in the
>> docs.openstack.org, but without having the actual plugin code to be
>> posted in the main Openstack GIT repository.
>>
>> Reason is that I dont have plan/bandwidth to go thru the entire process
>> of new plugin blue-print/development/review/testing etc as required by the
>> Openstack development community. Bcos this is already developed, tested and
>> released to some customers directly. Now I just want to get it to the
>> official Openstack documentation, so that more people can get this and use.
>>
>> The plugin package is made available to public from Ubuntu repository
>> along with necessary documentation. So people can directly get it from
>> Ubuntu repository and use it. All i need is to get listed in the
>> docs.openstack.org so that people knows that it exists and can be used
>> with any Openstack.
>>
>> Pls. confrim whether this is something possible?...
>>
>> Thanks again!..
>>
>> Vad
>> --
>>
>> On Fri, Oct 10, 2014 at 12:18 PM, Anne Gentle  wrote:
>>
>>>
>>>
>>> On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan <
>>> vadivel.openst...@gmail.com> wrote:
>>>
 Hi,

 How to include a new vendor plug-in (aka mechanism_driver in ML2
 framework) into the Openstack documentation?.. In other words, is it
 possible to include a new plug-in in the Openstack documentation page
 without having the actual plug-in code as part of the Openstack neutron
 repository?... The actual plug-in is posted and available for the public to
 download as Ubuntu package. But i need to mention somewhere in the
 Openstack documentation that this new plugin is available for the public to
 use along with its documentation.

>>>
>>> We definitely want you to include pointers to vendor documentation in
>>> the OpenStack docs, but I'd prefer make sure they're gate tested before
>>> they get listed on docs.openstack.org. Drivers change enough
>>> release-to-release that it's difficult to keep up maintenance.
>>>
>>> Lately I've been talking to driver contributors (hypervisor, storage,
>>> networking) about the out-of-tree changes possible. I'd like to encourage
>>> even out-of-tree drivers to get listed, but to store their main documents
>>> outside of docs.openstack.org, if they are gate-tested.
>>>
>>> Anyone have other ideas here?
>>>
>>> Looping in the OpenStack-docs mailing list also.
>>> Anne
>>>
>>>
>>>
 Pls. provide some insights into whether it is possible?.. and any
 further info on this?..

 Thanks,

 Vad

 --

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

[openstack-dev] [OpenStack-Dev] [libvirt] Block Devices and the "discard" option

[John Griffith]

Hi,

So I've been beating on this for a good part of the day and I'm not having
much luck so I thought I'd ask on the ML if anybody has had any success
with the following.

We have some applications that have been migrated off of our physical
machines and into our OpenStack Cloud.  The trouble is that these apps and
our storage take advantage of fstrim which returns the error:

  "fstrim: /: FITRIM ioctl failed: Operation not supported"

I thought... oh, easy I'll work up a quick patch to add this to Cinder and
Nova; but I don't seem to be having any luck getting this to work.

I also cam across the Nova patch to add this to Local Disk here: [1]
and I seem to get the same error there as well.

Testing fstrim on the devices from the compute node works fine, just not
the device passed in to the instance.

The XML I'm sending looks like this [2]

I'm running on 14.04 with RC1 builds.

I'm not sure what I'm missing, or if anybody has been able to make this
work, or if it should work.  Any insight would be greatly appreciated.

Thanks,
John


[1]: https://review.openstack.org/#/c/112977/12
[2]: https://gist.github.com/j-griffith/3341ad287c5d684f02b5
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Dev] [libvirt] Block Devices and the "discard" option

[Josh Durgin]

On 10/10/2014 08:44 PM, John Griffith wrote:

Hi,

So I've been beating on this for a good part of the day and I'm not
having much luck so I thought I'd ask on the ML if anybody has had any
success with the following.

We have some applications that have been migrated off of our physical
machines and into our OpenStack Cloud.  The trouble is that these apps
and our storage take advantage of fstrim which returns the error:

   "fstrim: /: FITRIM ioctl failed: Operation not supported"

I thought... oh, easy I'll work up a quick patch to add this to Cinder
and Nova; but I don't seem to be having any luck getting this to work.

I also cam across the Nova patch to add this to Local Disk here: [1]
and I seem to get the same error there as well.

Testing fstrim on the devices from the compute node works fine, just not
the device passed in to the instance.

The XML I'm sending looks like this [2]

I'm running on 14.04 with RC1 builds.

I'm not sure what I'm missing, or if anybody has been able to make this
work, or if it should work.  Any insight would be greatly appreciated.

Thanks,
John


[1]: https://review.openstack.org/#/c/112977/12
[2]: https://gist.github.com/j-griffith/3341ad287c5d684f02b5


Hey John,

I'm not sure if it's the only issue, but the virtio bus doesn't support
discard. You need to use virtio-scsi, scsi, or ide.

Josh

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