date:20170404

On Tue, Apr 4, 2017 at 9:36 PM, Emilien Macchi  wrote:
> adding [all] for more visibility... See comments inline:
>
> On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi  wrote:
>> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
>>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
 In the past we addressed this by automatically merging the release
 tag back into master, but we stopped doing that a cycle ago because
 it complicated release note generation.
>>>
>>> Also this was including RC >= 2 and final tags so as soon as the first
>>> stable maintenance version was released, master was again lower
>>> version.
>>
>> topic sounds staled.
>> Alan,  do we have an ETA on the RDO workaround?
>
> Without progress on RDO tooling and the difficulty of implementing it,
> I went ahead and proposed a semver bump for some projects:
>
> https://review.openstack.org/#/q/topic:sem-ver/pike
>
> Except for Swift where I don't know if they'll bump X, I proposed to bump Y.
> For all other projects, I bumped X as they did from Newton to Ocata.
> (where version is X.Y.Z).
>
> Please give any feedback on the reviews if you prefer another kind of bump.
> Thanks for reviewing that asap, so TripleO CI can test upgrades from
> Ocata to Pike soon.
>
> Thanks,

I forgot to mention that I didn't update Oslo yet, because I have no
clue which type of bump would be the best now.
Please use this url for review:
https://review.openstack.org/#/q/topic:sem-ver/pike+status:open

Thanks,

>> Thanks,
>>
>>> Cheers,
>>> Alan
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

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

Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

adding [all] for more visibility... See comments inline:

On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi  wrote:
> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
>>> In the past we addressed this by automatically merging the release
>>> tag back into master, but we stopped doing that a cycle ago because
>>> it complicated release note generation.
>>
>> Also this was including RC >= 2 and final tags so as soon as the first
>> stable maintenance version was released, master was again lower
>> version.
>
> topic sounds staled.
> Alan,  do we have an ETA on the RDO workaround?

Without progress on RDO tooling and the difficulty of implementing it,
I went ahead and proposed a semver bump for some projects:

https://review.openstack.org/#/q/topic:sem-ver/pike

Except for Swift where I don't know if they'll bump X, I proposed to bump Y.
For all other projects, I bumped X as they did from Newton to Ocata.
(where version is X.Y.Z).

Please give any feedback on the reviews if you prefer another kind of bump.
Thanks for reviewing that asap, so TripleO CI can test upgrades from
Ocata to Pike soon.

Thanks,

> Thanks,
>
>> Cheers,
>> Alan
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Emilien Macchi

-- 
Emilien Macchi

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

Re: [openstack-dev] [puppet] stepping down from puppet-openstack core

On Tue, Apr 4, 2017 at 5:23 PM, Matt Fischer  wrote:
> I am stepping down as core in the puppet openstack project. This is the
> culmination of a long and slow refocus of my work efforts into other areas.
> Additionally I'm not sure what the future holds for me at this point, and
> although it's possible that I will be doing puppet again but it's not fair
> for me to hold this role when I'm not active.
>
> I am very proud of what we, the community, accomplished with these modules
> since I started hacking on them in 2014. The modules went from needing lots
> of work to being very stable and mostly bug free. It took a lot of work and
> some tough decisions from the community to get us to this point and I was
> honored to be a part of it.
>
> Thanks

Thank *you* !

I'll miss the time where you gave strong operator feedback and when we
got issue / solution / patch merged the same day :-)
Anyway, enjoy the next things and thanks for your work here.

PS: I remain available on IRC anytime if you want to continue to
practice your french ;-)

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



-- 
Emilien Macchi

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

Re: [Openstack] Fuel 11 deployment fails

2017-04-04 Thread Konstantin Raskoshnyi

Hm, that's weird...There's no 192.168.0.4 host in the network, after I
added it on the router and added msqr from network 192.168.0.0/24 - all
network checks passed, but ctrl failed on All nodes are finished. Failed
tasks: Task[conntrackd/11] Stopping the deployment process!

On Tue, Apr 4, 2017 at 4:26 PM Dmitry Sutyagin 
wrote:

> Konstantin,
>
> No, you should not need to do this, I believe something else is wrong with
> your configuration. There potentially may be a bug in Fuel 11 though, I
> have not tried this release, all my knowledge comes from Fuel 9 and below.
> I'd recommend trying 9.0 release to see if the same problem shows up - if
> not then you should file a bug here, https://bugs.launchpad.net/fuel, if
> you get the same issue on 9.0 then it is most likely a problem with your
> configuration for either Fuel during it's installation or for the
> environment. Also, if your deployment got stuck at some point, then you've
> changed some configurations and you try to continue - sometimes the state
> of the deployment can be incorrect for continuation and you may need to
> reset the environment before proceeding.
>
> On Tue, Apr 4, 2017 at 3:27 PM, Konstantin Raskoshnyi 
> wrote:
>
> Hi Dmitry,
> 192.168.0.4 is inaccessible, because none of member has this Ip address,
> that means I need to set up this ip on my router under mgmt Vlan?
>
> Thanks
>
> On Tue, Apr 4, 2017 at 3:22 PM, Dmitry Sutyagin 
> wrote:
>
> Hi Konstantin,
>
> - Anyone knows why fuel slaves during deployment get 192.168.0.4 as def gw?
>
> AFAIK this is by design - by default after deployment all nodes which have
> public IP will use public GW to access internet; all nodes without a public
> IP (which is the case when "Assign public network to all nodes"is not
> selected in Networks -> Other) will use management "virtual" gateway which
> is in turn hosted on one of the controllers as a vrouter namespace, and
> controlled via pacemaker. So at some point during deployment the gateway on
> the nodes changes. Controllers can have either public ip gw or Fuel as
> their gateway, but other nodes are supposed to access internet through
> controllers. This was introduced around MOS 6.1 or 7.0 I believe.
>
> - So should I manually attach interfaces in ubuntu to each node or just
> allow internet traffic on routers from management network for example?
> No. The error you've encountered may indicate that there is no network
> connectivity via management network between these nodes and controllers,
> but I'm not 100% sure, I don't remember exactly through which interface the
> nodes try to access internet during pre-deployment network checks, but
> logically it should be the same as when nodes are completely deployed.
>
> On Mon, Apr 3, 2017 at 12:15 AM, Konstantin Raskoshnyi  > wrote:
>
> Hi Vidal,
>
> Yes, eventually I found the problem. But that's weird, actually my def
> route to fuel server. But, at some point default gw becomes mgmt
> 192.168.0.4 - I don't know why. So if I manually change def gw to fuel
> master - everything works fine.
>
> Anyone knows why fuel slaves during deployment get 192.168.0.4 as def gw?
>
> Thanks
>
> On Mon, Apr 3, 2017 at 12:01 AM Vimal Kumar  wrote:
>
> Hi,
>
> I faced the same issue few weeks ago while setting up a similar
> environment. The issue then was that during the installation Fuel master
> node ( https://docs.openstack.org/developer/fuel-docs/userdocs/
> fuel-install-guide/install/install_set_up_fuel.html ), I had incorrectly
> set up DHCP Gateway to the actual network gateway (see option 'c' in the
> table in that url). It should in fact be the IP address (in PXE network) of
> Fuel Master so that Fuel Master can forward traffic to the Internet.
>
> Long story short, had to reinstall Fuel Master again, and this time set
> the DHCP Gateway correctly to the Fuel Master and this step was successful.
>
> On Mon, Apr 3, 2017 at 7:47 AM, Konstantin Raskoshnyi 
> wrote:
>
> Hi, Guys, I'm pretty new for OpenStack but,
>
> I set up a simple 3 node OS, Fuel tells me that I can't attach public
> interface to Nova & Cider nodes, but after the first stage of deployment
> Fuel just hangs up with error:
>
>
> *Repo availability verification failed on following nodes Untitled
> (dc:f6), Untitled (e4:43).*
>
> Of course, Nova & Cider nodes don't have any internet access since Fuel
> explicitly denied me to attach public interfaces to my nodes
>
> So should I manually attach interfaces in ubuntu to each node or just
> allow internet traffic on routers from management network for example?
>
> All hosts can communicate with each other via management and storage
> networks.
>
> Thanks
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :

Re: [openstack-dev] [tc] version document for project navigator

2017-04-04 Thread Jimmy McArthur


Hooray! Thanks Monty :)


Monty Taylor 
April 4, 2017 at 5:47 PM
Hey all,

As per our discussion in today's TC meeting, I have made a document 
format for reporting versions to the project navigator. I stuck it in 
the releases repo:


  https://review.openstack.org/453361

Because there was already per-release information there, and the 
governance repo did not have that structure.


I've included pseudo-code and a human explanation of how to get from a 
service's version discovery document to the data in this document, but 
also how it can be maintained- which is likely to be easier by hand 
than by automation - but who knows, maybe we decide we want to make a 
devstack job for each service that runs on tag events that submits a 
patch to the releases repo. That sounds like WAY more work than once a 
cycle someone adding a few lines of json to a repo - but *shrug*.


Basing it on the version discovery docs show a few things:

* "As a user, I want to consume an OpenStack Service's Discovery 
Document" is a thing people might want to do and want to do 
consistently across services.


* We're not that far off from being able to do that today.

* Still, like we are in many places, we're randomly different in a few 
minor ways that do not actually matter but make life harder for our 
users.


Thoughts and feedback more than welcome!
Monty

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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


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

[openstack-dev] [election][tc] TC candidacy

2017-04-04 Thread Matthew Treinish

Hi Everyone,

I'd like to submit my candidacy for another term on the OpenStack Technical
Committee.

In my candidacy platform last year I outlined that if elected to the TC I wanted
to bring more technical oversight to the TC, and also to work on improving the
messaging around OpenStack, to make it clearer. I think in the past year we've
made lots of progress on both fronts, but there is still more work to do. Over
the next year I'd like to see the TC continue to make progress on both fronts.

The introduction of community wide goals was a good start in having the TC
setting a more concrete technical direction for projects. I see a lot of
potential with it and am eager to see it grow it over time. It was also just a
start and long term I'd like to see the TC take on more difficult technical
discussions and making decisions. For example, the recent discussion about
being opinionated about our RDBMS is an example of the kind of discussions I'd
like to see the TC have more of in the future.

For making the messaging around OpenStack clearer I think we've also been
making improvements. Over the last year, we've added and improved a few tags,
added the OpenStack principles document, and more recently we've worked on a TC
vision for the next 2 years. Over the past year we've also started taking
a more aggressive stance towards removing projects. Moving into the future I'd
like to see more progress on clearly documenting what OpenStack is and how it
can be used. I'm optimistic some of the efforts we're working on will continue
to make this better over time.

For the next year in addition to continuing progress on the items I outlined
before the other priority I see for the TC is working on improving the health
of the contributor base in the community. It's no secret that there has been
a recent contraction in the community and a lot of long time contributors and
community leaders are no longer actively contributing. I think we need to take
more proactive steps about this if we want OpenStack to continue to thrive.

I think there are 2 key areas we'll need to address on this front. The first
is I'd like to see the TC taking a more hands on approach for both building up
the mentorship pipeline to enable growing the contributor base and leadership in
the community. Most of of existing efforts in this area tend to be concentrated
on on-boarding new contributors which is good, but there isn't anything to
help bridge the gap into becoming a community leader. This is somewhere I can
see the TC taking a more active role to help people work towards taking
on leadership roles in the community.

The other aspect is I think we need to working towards making our community
more accessible for casual and/or part time contributors. Right now our
community process for contribution is heavily weighted towards full time and
corporate sponsored contribution. Over the next year I'd like to work towards
easing this burden and growing the number of casual and/or independent
contributors.

I think this will take 2 forms, the first is decreasing the barrier to entry on
our tooling. Things like the CLA and the multi-step process involving creating
multiple account just to get access to pushing proposed changes is very
off-putting, especially if you're not familiar with the systems. The other
aspect I think is more social. To a certain degree a lot of processes around
contribution or interaction assume that people are constant contributors and
always active (or connected). For example, how often do people push a patch
up for review and then bug a bunch of cores on IRC about it. That's not really
an option if you only can contribute for an 1 hr or 2 on the weekends. This is
an area where I'd like to see the TC start driving more active change to improve
the situation so we can hopefully start to grow the number of casual
contributors we have to the project.

Thanks for reading, I hope this outlines where my focus and priorities would be
if I'm lucky enough to be elected for another term.

Thanks,

Matthew Treinish

IRC: mtreinish
Review history: 
https://review.openstack.org/#/q/reviewer:mtreinish%2540kortar.org
Commit history: https://review.openstack.org/#/q/owner:mtreinish%2540kortar.org
Blog: http://blog.kortar.org/


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

Re: [Openstack] Fuel 11 deployment fails

2017-04-04 Thread Dmitry Sutyagin

Konstantin,

No, you should not need to do this, I believe something else is wrong with
your configuration. There potentially may be a bug in Fuel 11 though, I
have not tried this release, all my knowledge comes from Fuel 9 and below.
I'd recommend trying 9.0 release to see if the same problem shows up - if
not then you should file a bug here, https://bugs.launchpad.net/fuel, if
you get the same issue on 9.0 then it is most likely a problem with your
configuration for either Fuel during it's installation or for the
environment. Also, if your deployment got stuck at some point, then you've
changed some configurations and you try to continue - sometimes the state
of the deployment can be incorrect for continuation and you may need to
reset the environment before proceeding.

On Tue, Apr 4, 2017 at 3:27 PM, Konstantin Raskoshnyi 
wrote:

> Hi Dmitry,
> 192.168.0.4 is inaccessible, because none of member has this Ip address,
> that means I need to set up this ip on my router under mgmt Vlan?
>
> Thanks
>
> On Tue, Apr 4, 2017 at 3:22 PM, Dmitry Sutyagin 
> wrote:
>
>> Hi Konstantin,
>>
>> - Anyone knows why fuel slaves during deployment get 192.168.0.4 as def
>> gw?
>>
>> AFAIK this is by design - by default after deployment all nodes which
>> have public IP will use public GW to access internet; all nodes without a
>> public IP (which is the case when "Assign public network to all nodes"is
>> not selected in Networks -> Other) will use management "virtual" gateway
>> which is in turn hosted on one of the controllers as a vrouter namespace,
>> and controlled via pacemaker. So at some point during deployment the
>> gateway on the nodes changes. Controllers can have either public ip gw or
>> Fuel as their gateway, but other nodes are supposed to access internet
>> through controllers. This was introduced around MOS 6.1 or 7.0 I believe.
>>
>> - So should I manually attach interfaces in ubuntu to each node or just
>> allow internet traffic on routers from management network for example?
>> No. The error you've encountered may indicate that there is no network
>> connectivity via management network between these nodes and controllers,
>> but I'm not 100% sure, I don't remember exactly through which interface the
>> nodes try to access internet during pre-deployment network checks, but
>> logically it should be the same as when nodes are completely deployed.
>>
>> On Mon, Apr 3, 2017 at 12:15 AM, Konstantin Raskoshnyi <
>> konra...@gmail.com> wrote:
>>
>>> Hi Vidal,
>>>
>>> Yes, eventually I found the problem. But that's weird, actually my def
>>> route to fuel server. But, at some point default gw becomes mgmt
>>> 192.168.0.4 - I don't know why. So if I manually change def gw to fuel
>>> master - everything works fine.
>>>
>>> Anyone knows why fuel slaves during deployment get 192.168.0.4 as def
>>> gw?
>>>
>>> Thanks
>>>
>>> On Mon, Apr 3, 2017 at 12:01 AM Vimal Kumar  wrote:
>>>
 Hi,

 I faced the same issue few weeks ago while setting up a similar
 environment. The issue then was that during the installation Fuel master
 node ( https://docs.openstack.org/developer/fuel-docs/userdocs/fuel
 -install-guide/install/install_set_up_fuel.html ), I had incorrectly
 set up DHCP Gateway to the actual network gateway (see option 'c' in the
 table in that url). It should in fact be the IP address (in PXE network) of
 Fuel Master so that Fuel Master can forward traffic to the Internet.

 Long story short, had to reinstall Fuel Master again, and this time set
 the DHCP Gateway correctly to the Fuel Master and this step was successful.

 On Mon, Apr 3, 2017 at 7:47 AM, Konstantin Raskoshnyi <
 konra...@gmail.com> wrote:

 Hi, Guys, I'm pretty new for OpenStack but,

 I set up a simple 3 node OS, Fuel tells me that I can't attach public
 interface to Nova & Cider nodes, but after the first stage of deployment
 Fuel just hangs up with error:


 *Repo availability verification failed on following nodes Untitled
 (dc:f6), Untitled (e4:43).*

 Of course, Nova & Cider nodes don't have any internet access since Fuel
 explicitly denied me to attach public interfaces to my nodes

 So should I manually attach interfaces in ubuntu to each node or just
 allow internet traffic on routers from management network for example?

 All hosts can communicate with each other via management and storage
 networks.

 Thanks

 ___
 Mailing list: http://lists.openstack.org/cgi
 -bin/mailman/listinfo/openstack
 Post to : openstack@lists.openstack.org
 Unsubscribe : http://lists.openstack.org/cgi
 -bin/mailman/listinfo/openstack



>>> ___
>>> Mailing list: http://lists.openstack.org/cgi
>>>

Re: [openstack-dev] [puppet] stepping down from puppet-openstack core

2017-04-04 Thread Alex Schultz

On Tue, Apr 4, 2017 at 3:23 PM, Matt Fischer  wrote:
> I am stepping down as core in the puppet openstack project. This is the
> culmination of a long and slow refocus of my work efforts into other areas.
> Additionally I'm not sure what the future holds for me at this point, and
> although it's possible that I will be doing puppet again but it's not fair
> for me to hold this role when I'm not active.
>
> I am very proud of what we, the community, accomplished with these modules
> since I started hacking on them in 2014. The modules went from needing lots
> of work to being very stable and mostly bug free. It took a lot of work and
> some tough decisions from the community to get us to this point and I was
> honored to be a part of it.
>

Thanks for all your hard work Matt. Good luck on your next adventures.

Thanks,
-Alex

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

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

[openstack-dev] [tc] version document for project navigator


Hey all,

As per our discussion in today's TC meeting, I have made a document 
format for reporting versions to the project navigator. I stuck it in 
the releases repo:


  https://review.openstack.org/453361

Because there was already per-release information there, and the 
governance repo did not have that structure.


I've included pseudo-code and a human explanation of how to get from a 
service's version discovery document to the data in this document, but 
also how it can be maintained- which is likely to be easier by hand than 
by automation - but who knows, maybe we decide we want to make a 
devstack job for each service that runs on tag events that submits a 
patch to the releases repo. That sounds like WAY more work than once a 
cycle someone adding a few lines of json to a repo - but *shrug*.


Basing it on the version discovery docs show a few things:

* "As a user, I want to consume an OpenStack Service's Discovery 
Document" is a thing people might want to do and want to do consistently 
across services.


* We're not that far off from being able to do that today.

* Still, like we are in many places, we're randomly different in a few 
minor ways that do not actually matter but make life harder for our users.


Thoughts and feedback more than welcome!
Monty

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

Re: [Openstack] Fuel 11 deployment fails

2017-04-04 Thread Dmitry Sutyagin

Hi Konstantin,

- Anyone knows why fuel slaves during deployment get 192.168.0.4 as def gw?

AFAIK this is by design - by default after deployment all nodes which have
public IP will use public GW to access internet; all nodes without a public
IP (which is the case when "Assign public network to all nodes"is not
selected in Networks -> Other) will use management "virtual" gateway which
is in turn hosted on one of the controllers as a vrouter namespace, and
controlled via pacemaker. So at some point during deployment the gateway on
the nodes changes. Controllers can have either public ip gw or Fuel as
their gateway, but other nodes are supposed to access internet through
controllers. This was introduced around MOS 6.1 or 7.0 I believe.

- So should I manually attach interfaces in ubuntu to each node or just
allow internet traffic on routers from management network for example?
No. The error you've encountered may indicate that there is no network
connectivity via management network between these nodes and controllers,
but I'm not 100% sure, I don't remember exactly through which interface the
nodes try to access internet during pre-deployment network checks, but
logically it should be the same as when nodes are completely deployed.

On Mon, Apr 3, 2017 at 12:15 AM, Konstantin Raskoshnyi 
wrote:

> Hi Vidal,
>
> Yes, eventually I found the problem. But that's weird, actually my def
> route to fuel server. But, at some point default gw becomes mgmt
> 192.168.0.4 - I don't know why. So if I manually change def gw to fuel
> master - everything works fine.
>
> Anyone knows why fuel slaves during deployment get 192.168.0.4 as def gw?
>
> Thanks
>
> On Mon, Apr 3, 2017 at 12:01 AM Vimal Kumar  wrote:
>
>> Hi,
>>
>> I faced the same issue few weeks ago while setting up a similar
>> environment. The issue then was that during the installation Fuel master
>> node ( https://docs.openstack.org/developer/fuel-docs/userdocs/
>> fuel-install-guide/install/install_set_up_fuel.html ), I had incorrectly
>> set up DHCP Gateway to the actual network gateway (see option 'c' in the
>> table in that url). It should in fact be the IP address (in PXE network) of
>> Fuel Master so that Fuel Master can forward traffic to the Internet.
>>
>> Long story short, had to reinstall Fuel Master again, and this time set
>> the DHCP Gateway correctly to the Fuel Master and this step was successful.
>>
>> On Mon, Apr 3, 2017 at 7:47 AM, Konstantin Raskoshnyi > > wrote:
>>
>> Hi, Guys, I'm pretty new for OpenStack but,
>>
>> I set up a simple 3 node OS, Fuel tells me that I can't attach public
>> interface to Nova & Cider nodes, but after the first stage of deployment
>> Fuel just hangs up with error:
>>
>>
>> *Repo availability verification failed on following nodes Untitled
>> (dc:f6), Untitled (e4:43).*
>>
>> Of course, Nova & Cider nodes don't have any internet access since Fuel
>> explicitly denied me to attach public interfaces to my nodes
>>
>> So should I manually attach interfaces in ubuntu to each node or just
>> allow internet traffic on routers from management network for example?
>>
>> All hosts can communicate with each other via management and storage
>> networks.
>>
>> Thanks
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>>
>>
>>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>


-- 
Yours sincerely,
Dmitry Sutyagin
OpenStack Escalations Engineer
Mirantis, Inc.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [nova] Removing BDM devices from POST requests

2017-04-04 Thread Matt Riedemann


On 4/2/2017 10:10 PM, Matt Riedemann wrote:

On 4/2/2017 8:08 PM, Feodor Tersin wrote:

Can you give some more details? How does this actually "merge" or



replace BDMs defined in the image metadata? Is this because we use
device name as part of a hack for a primary key in the database [1]? I
assume it is. The lack of unique constraint in the BDM data model has
also always been a source of bugs, especially with cells v1 and why we
talk about adding a uuid column to that table every few months.


Right. This is not pure merging, but replacing, based on device names as
a primary key. Important point is that it is a user defined, human
readable key.


I've never actually heard of this use case but it looks like it's been
baked in since the legacy BDM behavior in the code, which is itself a
bunch of technical debt that I'd love to remove at some point.


A couple of years ago when Dipanov accidentally broke the merging, we
asked him to fix it here in ML, and he did it. If it's important, i'll
find these reviews and ML thread.


The history isn't as important to me. What's frustrating is this is
something people care about, and has been regressed before, and we don't
have good enough test coverage or documentation to know it's something
people do care about. I think before we move forward with any of this,
we'll want a test added to Tempest that validates this use case so we
avoid regressing it again.




I guess what I'm trying to get at is, is this just important for EC2
compatibility? Or do non-AWS OpenStack users care about this use case,
because we definitely don't advertise this anywhere in our
documentation, or test it in any of our integrated testing (Tempest). So
just because it happens to work by chance of a poor data model doesn't
make me want to bend over backward to keep this working.


Well, i cannot estimate the importance in absolute measurement, but in
comparison with OpenStack this use case is more important in AWS. Volume
backed images (EBS images) are used in AWS much more widely than in
OpenStack. There are some difficulties in Nova and Cinder because that
users try to avoid using volume backed images in favor of disk based
(instance-store) ones. This  explain why this use case is less important
for pure OpenStack users.


If we wanted to support updating/overriding a specific image BDM during
server create, I'd think we could do something more straight-forward in
the compute API, like add an "image_bdm_override=True" field to
block_device_mapping_v2, something like that. What do you think about
that alternative?


Since you want to delete the only natural key from bdm, how to refer on
a certain bdm in parameters? Honestly, without real merging implemented
in Nova, such workarounds fused into bdm structure do not look good for
me. It looks like a crutch for something unfinished. Another
disadvantages is that this new field may be added into DB, etc., because
all other bdm fields are. Perhaps more appropriate way is to add a new
'ignore_image_bdms' parameter to  run instance method. This brings
another questions, but does not directly affect bdms at least.


I'm not sure what the best design is for maintaining this in the API
without using the device name. I rattled off a few options in the spec
review, but they aren't great options, and some simply won't work for
older BDM or image resources, so are non-starters. I'm hoping some
others with a fresh perspective on this can chime in with ideas,
otherwise I'll bring it up in the nova API subteam meeting this week so
we can talk about the best way forward.

Thanks again Feodor.



mdbooth raised a good point in the spec about the device just being a 
convenient tag essentially for correlating the values for the image bdm 
override during server create. I was thinking, since we have tags for 
BDMs now as of the 2.32 microversion, couldn't we rely on those for the 
image bdm override at some point?


Granted, we need to do two other things first:

1. Allow tagging BDMs during volume attach (Artom has a series for that 
in Pike already).


2. Expose BDM tags out of the REST API (I have a spec for this but it's 
getting caught up in also exposing VIF tags, which depends on what we 
decide to do with os-virtual-interfaces and the os-interface APIs).


--

I raised the question though, could we move forward with removing the 
device field from the "POST /servers/{server_id}/os-volume_attachments" 
API since that doesn't do anything with image BDM overrides.


--

Thanks,

Matt

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

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-04-04 Thread Clint Byrum

Excerpts from Chris Hoge's message of 2017-04-04 17:09:11 -0400:
> 
> > On Apr 2, 2017, at 4:29 PM, Monty Taylor  wrote:
> > 
> > On 03/29/2017 03:39 PM, Steve Gordon wrote:
> >> - Original Message -
> >>> From: "Davanum Srinivas" 
> >>> To: "Chris Hoge" 
> >>> Cc: "OpenStack Development Mailing List (not for usage questions)" 
> >>> ,
> >>> "kubernetes-sig-openstack" 
> >>> Sent: Wednesday, March 29, 2017 2:28:29 PM
> >>> Subject: Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud 
> >>> Provider for Kubernetes
> >>> 
> >>> Team,
> >>> 
> >>> Repo is ready:
> >>> http://git.openstack.org/cgit/openstack/k8s-cloud-provider
> >>> 
> >>> I've taken the liberty of updating it with the latest changes in the
> >>> kubernetes/kubernetes repo:
> >>> https://review.openstack.org/#/q/project:openstack/k8s-cloud-provider is
> >>> ready
> >>> 
> >>> So logical next step would be to add CI jobs to test in OpenStack
> >>> Infra. Anyone interested?
> >> 
> >> One question I have around this - do we have a shared view of what the 
> >> ideal matrix of tested combinations would like? E.g. kubernetes master on 
> >> openstack project's master, kubernetes master on openstack project's 
> >> stable branches (where available), do we also need/want to test kubernetes 
> >> stable milestones, etc.
> >> 
> >> At a high level my goal would be the same as Chris's "k8s gating on 
> >> OpenStack in the same ways that it does on AWS and GCE." which would imply 
> >> reporting results on PRs proposed to K8S master *before* they merge but 
> >> not sure we all agree on what that actually means testing against in 
> >> practice on the OpenStack side of the equation?
> > 
> > I think we want to have jobs that have the ability to test:
> > 
> > 1) A proposed change to k8s-openstack-provider against current master of
> > OpenStack
> > 2) A proposed change to k8s-openstack-provider against a stable release
> > of OpenStack
> > 3) A proposed change to OpenStack against current master of
> > k8s-openstack-provider
> > 4) A proposed change to OpenStack against stable release of
> > k8s-openstack-provider
> > 
> > Those are all easy now that the code is in gerrit, and it's well defined
> > what triggers and where it reports.
> > 
> > Additionally, we need to test the surface area between
> > k8s-openstack-provider and k8s itself. (if we wind up needing to test
> > k8s against proposed changes to OpenStack then we've likely done
> > something wrong in life)
> > 
> > 5) A proposed change to k8s-openstack-provider against current master of k8s
> > 6) A proposed change to k8s-openstack-provider against a stable release
> > of k8s
> > 7) A proposed change to k8s against current master of k8s-openstack-provider
> > 8) A proposed change to k8s against stable release of k8s-openstack-provider
> > 
> > 5 and 6 are things we can do right now. 7 and 8 will have to wait for GH
> > support to land in zuul (without which we can neither trigger test jobs
> > on proposed changes to k8s nor can we report the results back to anyone)
> 
> 7 and 8 are going to be pretty important for integrating into the K8S
> release process. At the risk of having a work item thrown at me,
> is there a target for when that feature will land?
> 

Hi! Github support is happening basically as "zuulv3+1". We're working
on it in parallel with the v3 effort, so it should be a relatively quick
+1, but I'd expect infra will need a couple months of shaking out v3
bugs and getting everything ported before we can start talking about
hooking infra's zuul up to Github.

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

Re: [openstack-dev] [barbican] How to update cert in the secret

2017-04-04 Thread Andrey Grebennikov

Hi Michael,
Thanks for that, it is right that it is supposed to be Neutron's
responsibility. Moreover, I just found out that I can actually use Neutron
CLI for the update too - I just have to specify
"--default-tls-container_ref" option with the new container (it looks kind
of weird but it didn't complaint), and it makes the magic.

I really appreciate your help, thank you!

On Tue, Apr 4, 2017 at 3:10 PM, Michael Johnson  wrote:

> Hi Andrey,
>
>
>
> As we discussed on IRC, the listeners in LBaaS v2 allow you to update the
> barbican container IDs.  This will start the certificate update process on
> the load balancers with the new content from barbican.
>
>
>
> The neutron client, as you noted, does not appear to have this capability,
> but the API supports this as the primary means to update certificate
> content for LBaaS.  This will be included in the octavia OpenStack client.
>
>
>
> Michael
>
>
>
> *From:* Andrey Grebennikov [mailto:agrebenni...@mirantis.com]
> *Sent:* Monday, April 3, 2017 12:14 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [barbican] How to update cert in the secret
>
>
>
> Hey Barbican folks, I have a question regarding the functionality of the
> secrets containers please.
>
>
>
> If I got my secret created is there a way to update it down the road with
> another cert?
>
> The usecase is pretty common - using barbican with neutron lbaas.
>
> When the load balance from the lbaas backend gets the cert from barbican
> there is no way to update the neutron load balancer with the new secret
> seems so.
>
> The only way to update the cert within the balancer is to update the
> barbican secret and trigger the balancer to re-request the cert (while
> adding the pool member for example).
>
>
>
> Any help is greatly appreciated!
>
>
>
> --
>
> Andrey Grebennikov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Andrey Grebennikov
Principal Deployment Engineer
Mirantis Inc, Austin TX
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-odl][qa] What's the recommended behavior for SG Rules with ethertype='IPv6' and protocol='icmp' ?

2017-04-04 Thread Brian Haley

On 04/03/2017 09:23 PM, Ghanshyam Mann wrote:

On Sun, Mar 26, 2017 at 9:31 PM, Sridhar Gaddam > wrote:

On Fri, Mar 24, 2017 at 7:27 PM, Brian Haley > wrote:

On 03/24/2017 06:41 AM, Ghanshyam Mann wrote:

Hi All,

Tempest is testing SG rule creation and pinging scenario
tests with
ethertype='IPv6' and protocol='icmp' [0].
In case of ethertype='IPv6', currently neutron accept
protocol type
as 'icmp', 'icmpv6' and 'ipv6-icmp' which again seems like
duplication
of SG rules bug on neutron side but not sure [1]

But it seems like some driver does not work with 'icmp' on
IPv6, at
least ODL as mentioned in bug [2]. Where few others like ML2/OVS
iptables driver convert 'icmp' to 'icmpv6' when
ethertype='IPv6' and had
no issue with 'icmp'.

IMO neutron should keep accepting 'icmp' for IPv6 for backward
compatibility and legacy usage and tempest should test
'icmp' also along
with other protocol type.
But we need more feedback on that what is right way (as per
backward
compatibility pov) and recommended way for having best
behaviour for SG
rules on IPv6. What best can work for all plugins also?

Thanks for raising this issue. Let me just restate it a little
so it's clear.

1. One can create an IPv6 rule using protocol value "icmp"
today, and the base security group code does the right thing
changing the rule to be correct for the underlying
implementation, for example, "ipv6-icmp" for iptables. It
doesn't look like all other drivers handle this properly.

Well, let the Neutron API accept multiple values like
"icmp/icmpv6/ipv6-icmp", but IMO it should store a single Security
Group rule in the DB and raise "Duplicate error when similar rule is
configured once again".
Currently, Neutron treats each of them as a different Security Group
rule and stores them as separate entries in the DB.
However, IPtables Firewall driver in Neutron is converting[1] the
"ethertype=IPv6 and protocol=icmp" as a request to ICMPv6 and
applying the necessary ip-table rule.

https://github.com/openstack/neutron/blob/stable/newton/neutron/agent/linux/iptables_firewall.py#L373

Since this is not a documented behavior, other firewall drivers
(which I guess could be an issue even with OVS firewall driver) may
be missing this info.

++ for this, documentation could have helped this better way.

2. The neutron API will accept multiple values - "icmp",
"ipv6-icmp" and "icmpv6" for an IPv6 rule, but it will create
unique database entries for each (I just verified that). While
that shouldn't create multiple entries in the base iptables
code, it will probably generate a warning in the logs about a
duplicate being suppressed.

So there are a few things that could be done:

1. Drivers need to accept "icmp" in order to be
backwards-compatible with the current code.

2. Duplicates should be detected and generate 409 (?) errors.

3. We should add a migration (IMO) where any duplicates are
squashed.

Agree with your points.

I just created https://review.openstack.org/453346 as a start at #2,
will try and add code to squash existing duplicates too (#3).

-Brian

Yes, 409 on same type again make sense. And it can be documented
properly that 'icmp' will be treated same as other protocol type for

Ethertype=IPv6 and user will get 409 if they try to create and expect 2
different SG rules with those different protocol_type.
This is something change in current behavior where both requests('icmp'
and 'icmpv6') are treated as 2 separate rules. And so this new Tempest
tests will fail [1] which can be modified later.

With those points and current situation, I feel Tempest should tests the
current behavior proposed in [1] which will discover the drivers for
point 1. Later based on bug [2] consensus we can change the tests
accordingly.
I want to merge Tempest changes so that while changing anything on
neutron side, we know exactly what behavior we are going to change and
its impact etc.
Please leave comment on patch if any more feedback.

The open question is, do we want to change the DB to have a
different value here, like "icmpv6" ? We could obviously add a
migration where we update the value. The problem is that flag
day could pose a problem if out-of-tree drivers don't support
the new

[openstack-dev] [puppet] stepping down from puppet-openstack core

2017-04-04 Thread Matt Fischer

I am stepping down as core in the puppet openstack project. This is the
culmination of a long and slow refocus of my work efforts into other areas.
Additionally I'm not sure what the future holds for me at this point, and
although it's possible that I will be doing puppet again but it's not fair
for me to hold this role when I'm not active.

I am very proud of what we, the community, accomplished with these modules
since I started hacking on them in 2014. The modules went from needing lots
of work to being very stable and mostly bug free. It took a lot of work and
some tough decisions from the community to get us to this point and I was
honored to be a part of it.

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

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-04-04 Thread Chris Hoge


> On Apr 2, 2017, at 4:29 PM, Monty Taylor  wrote:
> 
> On 03/29/2017 03:39 PM, Steve Gordon wrote:
>> - Original Message -
>>> From: "Davanum Srinivas" 
>>> To: "Chris Hoge" 
>>> Cc: "OpenStack Development Mailing List (not for usage questions)" 
>>> ,
>>> "kubernetes-sig-openstack" 
>>> Sent: Wednesday, March 29, 2017 2:28:29 PM
>>> Subject: Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud 
>>> Provider for Kubernetes
>>> 
>>> Team,
>>> 
>>> Repo is ready:
>>> http://git.openstack.org/cgit/openstack/k8s-cloud-provider
>>> 
>>> I've taken the liberty of updating it with the latest changes in the
>>> kubernetes/kubernetes repo:
>>> https://review.openstack.org/#/q/project:openstack/k8s-cloud-provider is
>>> ready
>>> 
>>> So logical next step would be to add CI jobs to test in OpenStack
>>> Infra. Anyone interested?
>> 
>> One question I have around this - do we have a shared view of what the ideal 
>> matrix of tested combinations would like? E.g. kubernetes master on 
>> openstack project's master, kubernetes master on openstack project's stable 
>> branches (where available), do we also need/want to test kubernetes stable 
>> milestones, etc.
>> 
>> At a high level my goal would be the same as Chris's "k8s gating on 
>> OpenStack in the same ways that it does on AWS and GCE." which would imply 
>> reporting results on PRs proposed to K8S master *before* they merge but not 
>> sure we all agree on what that actually means testing against in practice on 
>> the OpenStack side of the equation?
> 
> I think we want to have jobs that have the ability to test:
> 
> 1) A proposed change to k8s-openstack-provider against current master of
> OpenStack
> 2) A proposed change to k8s-openstack-provider against a stable release
> of OpenStack
> 3) A proposed change to OpenStack against current master of
> k8s-openstack-provider
> 4) A proposed change to OpenStack against stable release of
> k8s-openstack-provider
> 
> Those are all easy now that the code is in gerrit, and it's well defined
> what triggers and where it reports.
> 
> Additionally, we need to test the surface area between
> k8s-openstack-provider and k8s itself. (if we wind up needing to test
> k8s against proposed changes to OpenStack then we've likely done
> something wrong in life)
> 
> 5) A proposed change to k8s-openstack-provider against current master of k8s
> 6) A proposed change to k8s-openstack-provider against a stable release
> of k8s
> 7) A proposed change to k8s against current master of k8s-openstack-provider
> 8) A proposed change to k8s against stable release of k8s-openstack-provider
> 
> 5 and 6 are things we can do right now. 7 and 8 will have to wait for GH
> support to land in zuul (without which we can neither trigger test jobs
> on proposed changes to k8s nor can we report the results back to anyone)

7 and 8 are going to be pretty important for integrating into the K8S
release process. At the risk of having a work item thrown at me,
is there a target for when that feature will land?

It's not critical though, sorting out every other item is a pretty
cool set of initial tests.

Of note, e2e tests have some unreliability because of things like
hard sleeps[1]. It sounds like the K8S community is trying to address
these issues, but initially we should be expecting quite a few false
negatives (where negative means test failure).

[1] https://groups.google.com/forum/#!topic/kubernetes-sig-testing/a3XUvUVmxWU

> 
> I would recommend that we make 5 and 6 non-voting until such a time as
> we are reporting on 7 and 8 back to k8s and have a reasonable
> expectation someone will pay attention to failures - otherwise k8s will
> be able to wedge the k8s-openstack-provider gate.
> 
>>> On Sat, Mar 25, 2017 at 12:10 PM, Chris Hoge  wrote:
 
 
 On Friday, March 24, 2017 at 8:46:42 AM UTC-7, Antoni Segura Puimedon
 wrote:
> 
> 
> 
> On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:
>> 
>> On 24/03/17 10:27 -0400, Davanum Srinivas wrote:
>>> Folks,
>>> 
>>> As discussed in the etherpad:
>>> https://etherpad.openstack.org/p/go-and-containers
>>> 
>>> Here's a request for a repo in OpenStack:
>>> https://review.openstack.org/#/c/449641/
>>> 
>>> This request pulls in the existing code from kubernetes/kubernetes
>>> repo and preserves the git history too
>>> https://github.com/dims/k8s-cloud-provider
>>> 
>>> Anyone interested? please ping me on Slack or IRC and we can continue
>>> this work.
>> 
>> Yeah - I would love to continue the provider work on gerrit :)
>> 
>> Is there a way for us to make sure changes in the k8 master don't
>> break our plugin? Or do we need to periodic jobs on the provider repo
>> to catch breakages in the

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

2017-04-04 Thread Chris Hoge


> On Apr 2, 2017, at 4:16 PM, Monty Taylor  wrote:
> 
> On 04/02/2017 02:53 PM, Chris Hoge wrote:
>> Now that the provider has a repository in the OpenStack project
>> namespace, we need to move over the existing set of issues and pull
>> requests and create an initial work list for migrating patches and
>> fixing existing issues.
>> 
>> I've started up an etherpad where we can track that work[1]. In the longer
>> run we should migrate over to Launchpad or Storyboard. One question,
>> to help preserve continuity with the K8S community workflow: do we want
>> to investigate ways to allow for issue creation in the OpenStack
>> namespace on GitHub?
> 
> I do not think this is a thing we want to do. While I understand the
> urge, a project needs to live somewhere (in this case we've chosen
> OpenStack) and should behave as projects do in that location. When I
> work on Ansible, I do issues on github. When I deal with tox, I file
> issues on bitbucket. Back when I dealt with Jenkins I filed issues in
> their Jira. I do not think that filing an issue in the issue tracker for
> a project is too onerous of a request to make of someone.

Sounds reasonable.

I still want to think about how to communicate efficiently across
projects. This thread, for example, was cross posted across communities,
and has now forked as a result.

I’m personally not thrilled with cross posting. My proposal would be to
consider the openstack-dev mailing list to be the source for development
related discussions, and I can feed highlights of discussions to the
sig-k8s-openstack, and relay and relevant discussions from there back
to this list.

> We have issues turned off in all of our github mirrors, so it's highly
> unlikely someone will accidentally attempt to file an issue like the.
> (it's too bad we can't similarly turn off pull requests, but oh well)
> 
> 
>> [1] https://etherpad.openstack.org/p/k8s-provider-issue-migration
>> 
>> On Friday, March 24, 2017 at 7:27:09 AM UTC-7, Davanum Srinivas wrote:
>> 
>>Folks,
>> 
>>As discussed in the etherpad:
>>https://etherpad.openstack.org/p/go-and-containers
>>
>> 
>>Here's a request for a repo in OpenStack:
>>https://review.openstack.org/#/c/449641/
>>
>> 
>>This request pulls in the existing code from kubernetes/kubernetes
>>repo and preserves the git history too
>>https://github.com/dims/k8s-cloud-provider
>>
>> 
>>Anyone interested? please ping me on Slack or IRC and we can
>>continue this work.
>> 
>>Thanks,
>>Dims
>> 
>>-- 
>>Davanum Srinivas :: https://twitter.com/dims
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [infra] Stop enabling EPEL mirror by default

2017-04-04 Thread Ian Wienand

On 04/05/2017 03:02 AM, Paul Belanger wrote:
> Recently we've been running into some issues keeping our EPEL mirror
> properly sync'd. We are working to fix this, however we'd also like
> to do the following:

>   Stop enabling EPEL mirror by default
>   https://review.openstack.org/#/c/453222/

> For the most part, we enable EPEL for our image build process, this
> to install haveged.  However, it is also likely the majority of
> centos-7 projects don't actually need EPEL.  I know specifically
> both RDO and TripleO avoid using the EPEL repository because of how
> unstable it is.

I agree this is the step to turn it off in our gate, but I've been
trying to excise this so we move to a white-list method during builds,
which is more complicated.  This needs to be done, however, so that
3rd party CI who don't use our mirror scripts don't get EPEL hanging
around from the build too.

I'd appreciate reviews

Firstly, we need to ensure the image build EPEL dependencies we have
are flexible to changes in default status.

 * https://review.openstack.org/439294 : don't install ccache
 * https://review.openstack.org/439911 : allow "--enablerepo" options
 for haveged install
 * https://review.openstack.org/439917 : install haveged from EPEL

Then we need a way to install EPEL, but disabled, during image builds

 * https://review.openstack.org/439926 : Add flag to disable EPEL

Then stop installing EPEL as part of the puppet install, and switch to
installing it from dib in disabled state

 * https://review.openstack.org/453322 : Add epel element (with disabled flag)
 * https://review.openstack.org/439248 : Don't install EPEL during puppet

At this point, our base images should be coming up with only
whitelisted EPEL packages (haveged, unless I find anything else I've
missed) and the repo disabled.

-i

p.s. tangential; but related is

 *  https://review.openstack.org/453325 : use Centos openstack repos, not RDO

This could probably be also moved into DIB as an element, if
we feel strongly about it (or infra-package-needs ... but I wasn't
100% sure that's early enough yet)

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

Re: [Openstack-operators] [Openstack] Slow internet speed - Instances with floating IP

2017-04-04 Thread Kevin Benton

I recommend filing an issue against that speedtest-cli script. I noticed
the timer seems to be started before the DNS lookup occurs (before call to
urlopen). This means any DNS issues impact the measurement of what is
supposed to be network throughput.

On Apr 4, 2017 13:19, "John Petrini"  wrote:

> Hi All,
>
> Turns out this was a DNS issue. The speedtest-cli script does a lot of
> lookups and these lookups were hanging due to parallel A and  requests
> resulting in the unexpected results. I added the following to
> /etc/resolv.conf and the issue seems to be resolved.
>
> options single-request-reopen
>
> Thanks,
>
> ___
>
> John Petrini
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [tripleo][kolla] extended start and hostpath persistent dirs (was: kolla_bootstrap for non-openstack services)

2017-04-04 Thread Dan Prince

On Tue, 2017-04-04 at 18:03 +0200, Bogdan Dobrelya wrote:
> On 03.04.2017 21:01, Dan Prince wrote:
> > On Mon, 2017-04-03 at 16:15 +0200, Bogdan Dobrelya wrote:
> > > Let's please re-evaluate configuration of containerized non-
> > > openstack,
> > > like database, message queue, key value, web, services for
> > > tripleo
> > > heat
> > > templates and Kolla. Here is an example containerized etcd patch
> > > [0].
> > > 
> > > tl;dr use kolla images and bootsrap OR upstream images with
> > > direct
> > > commands:
> > > 
> > > .. code-block:: yaml
> > > kolla_config:
> > > /var/lib/kolla/config_files/foo.json
> > >   command: /usr/bin/foo
> > > 
> > > vs
> > > 
> > > .. code-block:: yaml
> > > foo:
> > > image: upstream/foo:latest
> > > command: /usr/bin/foo
> > > 
> > > Note, tht already doesn't use configs [1] copied into the images
> > > by
> > > kolla build time. The next and logical step might be to omit
> > > kolla's
> > > bootstrap, where applicable, as well.
> > 
> > The kolla config file copying proved to be a bit pedantic. So we
> > removed it. A good example of this would be how this played out for
> > the
> > keystone service:
> > 
> > http://git.openstack.org/cgit/openstack/tripleo-heat-templates/comm
> > it/?
> > id=332e8ec10345ad5c8bf10a532f6f6003da682b68
> > 
> > > 
> > > There is a two options:
> > > * use kolla images and bootstrap as t-h-t does now for all
> > > services
> > > being containerized
> > 
> > We do not use KOLLA_BOOTSTRAP for all services now. Only 4 services
> > use
> > it currently I think. I think the general consensus is we should
> > not be
> > using it unless there is a functional requirement to do so.
> > Services
> > like Mysql and Rabbitmq have some extra initialization that needs
> > to
> > execute in-container before the services startup. We could
> > duplicate
> > this in tripleo-heat-templates, run it with docker-cmd perhaps and
> > do
> > it that way but we initially made exception for just a few
> > services.
> > 
> > Other services like Glance are using it, but that is just
> > historical.
> > There is already a patch to remove the use of KOLLA_BOOTSTRAP for
> > this
> > service:
> > 
> > https://review.openstack.org/#/c/440884/1
> > 
> > So in summary the consensus is we'd prefer not to be using the
> > KOLLA_BOOTSTRAP environment variables because in some cases there
> > is a
> > 'Kolla' flavor to these things that don't match how TripleO deploys
> > things.
> > 
> > It is worth pointing out that while we aren't using KOLLA_BOOTSTRAP
> > we
> > are using the kolla startup systems in many cases. This gives some
> > features around file permissions, extra sudoers files, etc. We may
> > be
> > able to stop using this for some services but I also think we are
> > getting value out of the interfaces today. They aren't nearly as
> > verbose as the Kolla config copying stuff so we could go either
> > way.
> 
> That's interesting, there is related topic with hostpath mounted
> persistent log dirs [0]. The issue is:
> 
> [tl;dr] kolla_config is a bad fit for logs, let's run containers'
> steps
> as 'user: root' in a user namespace remapped [1] for a
> tripleocontainers
> system user. Thoughts? And would that work for stock centos7/rhel7
> kernels?
> 
> 
> So, the issue is when log/data dirs created by host_prep_tasks, we
> must
> configure host permissions in a simple non-opinionated way.
> What I can see for t-h-t to cover it on its own:
> * Custom entrypoints for containers adds complexity and head ache.

Good point. But the entry points Kolla uses for many containers don't
match what our systemd services already use on baremetal. As we are
striving for update path that does not break end users upgrading from
baremetal to containers we have to have a mechanism that gives us
configuration parity across the implementions. Controlling the entry
point either by injecting it into the container (via something like
Kolla's template overrides mechanism) or via tripleo-heat-templates
direction (much more hackable) is where we ended up.

In general we like Kolla images at the moment for what they provide.
But there are some cases where we need to control things that have too
much of a "kolla flavor" and would potentially break upgrades/features
if we used them directly.

> * Mount logs world writable is a non starter.

I don't think we advocating we make log directories world writable
anywhere. One idea is that use jistr's host_prep_tasks to create
directories on the host and then log there. Another idea would be to
use 'init tasks' via docker-cmd to do the same thing.

The nice thing about either of these approaches is that it allows us to
integrate with TripleO's existing fluentd integration which uses host
logging. I think this is a nice first step in a world where we are
temporarily supporting both baremetal and containers deployment with
the same architecture. In the future perhaps we could move towards
stdout logging for services in containers and then

Re: [openstack-dev] [neutron][networking-l2gw] openstack vtep setup missing docs

2017-04-04 Thread Armando M.

On 4 April 2017 at 07:53, Saverio Proto  wrote:

> Hello Armando,
>
> I managed to implement the L2GW setup purely in software, without an
> hardware appliance.
>
> I documented in the README file, please look at this review
> https://review.openstack.org/453209


Nice job!


>
>
> I have a question: do we have a name for this node where the actually
> bridging happens between a VXLAN tenant network and a physical L2 network ?
> Is it okay to call it the l2gw agent ?
>

Historically this was called l2gw agent (node). You can find references in
[1,2]


>
> The l2gw plugin it self runs on the controller, so also the
> neutron-l2gw-plugin agent runs on the controller.
>
> I think it necessary to clarify this naming, because before trying the
> software I did the mistake of thinking that the neutron-l2gw-agent had
> to run on the switch where the actual briding happens.
>

The l2gw agent uses solely OVSDB to interact to the server and as such it
can run anywhere. In fact, in Arista's POC video [3] (credit to Sukhdev),
the demo setup shows this in more details.

Cheers,
Armando

[1]
https://github.com/openstack/networking-l2gw/blob/master/doc/source/images/L2GW_deployment.png
[2]
https://github.com/openstack/networking-l2gw/blob/master/specs/kilo/l2-gateway-api-implementation.rst
[3] https://www.youtube.com/watch?v=WpilpgPnYrE


>
> thank you
>
> Saverio
>
>
>
>
> On 30/03/17 18:40, Armando M. wrote:
> >
> >
> > On 30 March 2017 at 08:47, Saverio Proto  > > wrote:
> >
> > Hello,
> >
> > I am trying to use the neutron l2gw plugin, but I am not using a bare
> > metal switch to bridge.
> >
> > I am using a server with Openvswitch.
> >
> >
> > I am not aware of any effort to implement L2GW purely in software, in
> > fact this was one key missing pieces that prevented the project to have
> > CI solely dealt with the upstream infra resources. Perhaps OVN may come
> > to the rescue here, I recall at some point the team was looking at the
> > L2GW API.
> >
> > Thanks,
> > Armando
> >
> >
> >
> > Following this documentation:
> >
> > http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
> > 
> >
> > At one point there is this command:
> >
> > sudo vtep-bootstrap L5 10.0.0.5 192.168.91.21 --no_encryption
> >
> > This vtep-bootstrap is specific for Cumulux Linux
> >
> > Anybody has documentation with normal vtep-ctl commands ?
> >
> > So far on the Ubuntu server I did the following:
> >
> > apt-get install openvswitch-vtep
> > ovsdb-tool create /etc/openvswitch/vtep.db
> > /usr/share/openvswitch/vtep.ovsschema
> >
> > Anyone has more complete documentation ?
> >
> > I did not understand if the vtep-openvswitch controlled by the l2gw
> > plugin will make vxlan tunnels to all the compute nodes, to bridge
> the
> > tenant network with a physical l2 network ? Or all this traffic has
> to
> > pass to the network node also because the vtep openvswitch is not
> able
> > to talk to the compute nodes ?
> >
> > thank you
> >
> > Saverio
> >
> >
> > --
> > SWITCH
> > Saverio Proto, Peta Solutions
> > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> > phone +41 44 268 15 15, direct +41 44 268 1573
> > saverio.pr...@switch.ch ,
> > http://www.switch.ch
> >
> > http://www.switch.ch/stories
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >  unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [tripleo] Roadmap for Container CI work

2017-04-04 Thread Dan Prince

On Tue, 2017-04-04 at 16:01 -0400, Emilien Macchi wrote:
> After our weekly meeting of today, I found useful to share and
> discuss
> our roadmap for Container CI jobs in TripleO.
> They are ordered by priority from the highest to lowest:
> 
> 1. Swap ovb-nonha job with ovb-containers, enable introspection on
> the
> container job and shuffle other coverage (e.g ssl) to other jobs
> (HA?). It will help us to get coverage for ovb-containers scenario
> again, without consuming more rh1 resources and keep existing
> coverage.

The existing containers job already had introspection enabled I think.
So this is largely a swap (containers for nonha). We may move some of
the SSL features into the existing HA job if that makes more sense to
keep coverage on par with what the nonha job was already covering.

> 2. Get multinode coverage of deployments - this should integrate with
> the scenarios we already have defined for non-container deployment.
> This is super important to cover all overcloud services, like we did
> with classic deployments. It should be non voting to start and then
> voting once it works. We should find a way to keep the same templates
> as we have now, and just include the docker environment. In other
> words, find a way to keep using:
> https://github.com/openstack/tripleo-heat-templates/blob/master/ci/en
> vironments/scenario001-multinode.yaml
> so we don't duplicate scenario environments.
> 3. Implement container upgrade job, which for Pike will be deploy a
> baremetal overcloud, then migrate on upgrade to containers. Use
> multinode jobs for this task. Start with a non-voting job and move to
> the gate once it work. I also suggest to use scenarios framework, so
> we keep good coverage.

Using multinode here is a great start. We might also at some point
decide to swap out the existing OVB job to be a baremetal -> containers
version so we have end to end coverage there as well.

> 4. After we implement the workflow for minor updates, have a job with
> tests container-to-container updates for minor (rolling) updates,
> this
> ideally should add some coverage to ensure no downtime of APIs and
> possibly checks for service restarts (ref recent bugs about bouncing
> services on minor updates)
> 5. Once Pike is released and Queens starts, let's work on container
> to
> containers upgrade job.
> 
> Any feedback or question is highly welcome,
> 
> Note: The proposal comes from shardy's notes on
> https://etherpad.openstack.org/p/tripleo-container-ci - feel free to
> contribute to the etherpad or mailing list.
> 
> Thanks,

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

[openstack-dev] [election] TC non-candidacy

2017-04-04 Thread Mike Perez

Hi all,

Thanks for letting me serve as a TC member. I will not be running this time
around since fungi is serving from the OpenStack Foundation on the
committee and ttx is more deserving for re-election.

-- 
Mike Perez


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

Re: [openstack-dev] [neutron][networking-l2gw] openstack vtep setup missing docs

2017-04-04 Thread Curtis

On Tue, Apr 4, 2017 at 8:53 AM, Saverio Proto  wrote:
> Hello Armando,
>
> I managed to implement the L2GW setup purely in software, without an
> hardware appliance.

Nice! That is very interesting. I will take a look at the work you've done here.

Thanks,
Curtis.

>
> I documented in the README file, please look at this review
> https://review.openstack.org/453209
>
> I have a question: do we have a name for this node where the actually
> bridging happens between a VXLAN tenant network and a physical L2 network ?
> Is it okay to call it the l2gw node ?
>
> The l2gw plugin it self runs on the controller, so also the
> neutron-l2gw-plugin agent runs on the controller.
>
> I think it necessary to clarify this naming, because before trying the
> software I did the mistake of thinking that the neutron-l2gw-agent had
> to run on the switch where the actual briding happens.
>
> thank you
>
> Saverio
>
>
>
>
> On 30/03/17 18:40, Armando M. wrote:
>>
>>
>> On 30 March 2017 at 08:47, Saverio Proto > > wrote:
>>
>> Hello,
>>
>> I am trying to use the neutron l2gw plugin, but I am not using a bare
>> metal switch to bridge.
>>
>> I am using a server with Openvswitch.
>>
>>
>> I am not aware of any effort to implement L2GW purely in software, in
>> fact this was one key missing pieces that prevented the project to have
>> CI solely dealt with the upstream infra resources. Perhaps OVN may come
>> to the rescue here, I recall at some point the team was looking at the
>> L2GW API.
>>
>> Thanks,
>> Armando
>>
>>
>>
>> Following this documentation:
>>
>> http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
>> 
>>
>> At one point there is this command:
>>
>> sudo vtep-bootstrap L5 10.0.0.5 192.168.91.21 --no_encryption
>>
>> This vtep-bootstrap is specific for Cumulux Linux
>>
>> Anybody has documentation with normal vtep-ctl commands ?
>>
>> So far on the Ubuntu server I did the following:
>>
>> apt-get install openvswitch-vtep
>> ovsdb-tool create /etc/openvswitch/vtep.db
>> /usr/share/openvswitch/vtep.ovsschema
>>
>> Anyone has more complete documentation ?
>>
>> I did not understand if the vtep-openvswitch controlled by the l2gw
>> plugin will make vxlan tunnels to all the compute nodes, to bridge the
>> tenant network with a physical l2 network ? Or all this traffic has to
>> pass to the network node also because the vtep openvswitch is not able
>> to talk to the compute nodes ?
>>
>> thank you
>>
>> Saverio
>>
>>
>> --
>> SWITCH
>> Saverio Proto, Peta Solutions
>> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
>> phone +41 44 268 15 15, direct +41 44 268 1573
>> saverio.pr...@switch.ch ,
>> http://www.switch.ch
>>
>> http://www.switch.ch/stories
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Blog: serverascode.com

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

Re: [Openstack-operators] [Openstack] Slow internet speed - Instances with floating IP

Hi All,

Turns out this was a DNS issue. The speedtest-cli script does a lot of
lookups and these lookups were hanging due to parallel A and  requests
resulting in the unexpected results. I added the following to
/etc/resolv.conf and the issue seems to be resolved.

options single-request-reopen

Thanks,

___

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

Re: [openstack-dev] [barbican] How to update cert in the secret

2017-04-04 Thread Michael Johnson

Hi Andrey,

 

As we discussed on IRC, the listeners in LBaaS v2 allow you to update the 
barbican container IDs.  This will start the certificate update process on the 
load balancers with the new content from barbican.

 

The neutron client, as you noted, does not appear to have this capability, but 
the API supports this as the primary means to update certificate content for 
LBaaS.  This will be included in the octavia OpenStack client.

 

Michael

 

From: Andrey Grebennikov [mailto:agrebenni...@mirantis.com] 
Sent: Monday, April 3, 2017 12:14 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [barbican] How to update cert in the secret

 

Hey Barbican folks, I have a question regarding the functionality of the 
secrets containers please.

 

If I got my secret created is there a way to update it down the road with 
another cert?

The usecase is pretty common - using barbican with neutron lbaas.

When the load balance from the lbaas backend gets the cert from barbican there 
is no way to update the neutron load balancer with the new secret seems so.

The only way to update the cert within the balancer is to update the barbican 
secret and trigger the balancer to re-request the cert (while adding the pool 
member for example).

 

Any help is greatly appreciated!

 

-- 

Andrey Grebennikov

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

[Openstack-operators] [telecom-nfv] Meeting #23 tomorrow!

2017-04-04 Thread Curtis

Hi All,

We will have our biweekly meeting tomorrow. [1] Feel free to add to the agenda.

The openstack summit will be upon us soon.

Hope to see you then. :)

Thanks,
Curtis.

[1]: 
http://eavesdrop.openstack.org/#OpenStack_Operators_Telco_and_NFV_Working_Group

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

[openstack-dev] [tripleo] Roadmap for Container CI work

After our weekly meeting of today, I found useful to share and discuss
our roadmap for Container CI jobs in TripleO.
They are ordered by priority from the highest to lowest:

1. Swap ovb-nonha job with ovb-containers, enable introspection on the
container job and shuffle other coverage (e.g ssl) to other jobs
(HA?). It will help us to get coverage for ovb-containers scenario
again, without consuming more rh1 resources and keep existing
coverage.
2. Get multinode coverage of deployments - this should integrate with
the scenarios we already have defined for non-container deployment.
This is super important to cover all overcloud services, like we did
with classic deployments. It should be non voting to start and then
voting once it works. We should find a way to keep the same templates
as we have now, and just include the docker environment. In other
words, find a way to keep using:
https://github.com/openstack/tripleo-heat-templates/blob/master/ci/environments/scenario001-multinode.yaml
so we don't duplicate scenario environments.
3. Implement container upgrade job, which for Pike will be deploy a
baremetal overcloud, then migrate on upgrade to containers. Use
multinode jobs for this task. Start with a non-voting job and move to
the gate once it work. I also suggest to use scenarios framework, so
we keep good coverage.
4. After we implement the workflow for minor updates, have a job with
tests container-to-container updates for minor (rolling) updates, this
ideally should add some coverage to ensure no downtime of APIs and
possibly checks for service restarts (ref recent bugs about bouncing
services on minor updates)
5. Once Pike is released and Queens starts, let's work on container to
containers upgrade job.

Any feedback or question is highly welcome,

Note: The proposal comes from shardy's notes on
https://etherpad.openstack.org/p/tripleo-container-ci - feel free to
contribute to the etherpad or mailing list.

Thanks,
--
Emilien Macchi

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

[Openstack] Launch instance on dashboard says not enough RAM

2017-04-04 Thread MARK





So under the dashboard if I try to launch an instance, when I get to the point 
of picking a flavor, under the memory/RAM column an orange warning triangle is 
shown, which I suppose indicates that there is not enough RAM available on the 
physical host. 




openstack host show  




shows over 100gb available ... 





Any clue? 




How are those warnings generated? 
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [storlets] Storlet meetings today and in the next two weeks

2017-04-04 Thread Eran Rom

Hi All,
As these are holidays in Israel i will not be able to make it today and in the 
next two weeks.
Feel free to hold the meetings without me. Just coordinate via the mailing list 
so that others can join.

If there is anything you would like to discuss. please ping on IRC in 
#openstack-storlets which I will be monitoring.
Thanks,
Eran
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] Request for documentation about Ocata on Ubuntu with Networking OVN

2017-04-04 Thread Martinx - ジェームズ

I'm also seeing the following errors on ovs-vswitchd.log:

http://paste.openstack.org/show/605441/

On 4 April 2017 at 15:19, Martinx - ジェームズ  wrote:

> There are more errors on Compute node as well, nova.log:
>
> http://paste.openstack.org/show/605439/
>
> On 4 April 2017 at 15:14, Martinx - ジェームズ 
> wrote:
>
>> Hello!
>>
>>  Currently, I'm trying to deploy Ocata with Networking OVN, so far, no
>> success.
>>
>>  I can easily deploy Ocata in a multi-node environment (1 Controller, 1
>> Network and 2 Computes), using regular "neutron-openvswitch-agent" and its
>> "ovs-firewall-driver".
>>
>>  However, when I try the following instructions:
>>
>>  https://docs.openstack.org/developer/networking-ovn/install.html
>>
>>  It just doesn't work.
>>
>>  From what I'm seeing, on Ubuntu, the package names are different, like
>> "ovn-central" for the controllers and "ovn-host" for the compute nodes.
>>
>>  All steps on the above guide, works, no errors on logs. But, when I try
>> to launch an Instance, it fails, with errors on neutron-server.log:
>>
>>  http://paste.openstack.org/show/605438/
>>
>>  Looks like that Ubuntu have all the required packages but, just the
>> documentation that is not available.
>>
>>  I really want to move to OVN, can't deal with Network Node and its
>> namespaces anymore. Also, we need DPDK, and OVN have a better support for
>> tunneled networks on top of DPDK.
>>
>>  In my deployment, first, I deployed it with neutron-openvswitch-agents,
>> later, I deleted all instances, all stacks and all networks, changed it to
>> OVN, and tried again but, it failed.
>>
>>  I really appreciate any help in this direction...
>>
>> Thanks!
>> Thiago
>>
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Request for documentation about Ocata on Ubuntu with Networking OVN

2017-04-04 Thread Martinx - ジェームズ

Hello!

 Currently, I'm trying to deploy Ocata with Networking OVN, so far, no
success.

 I can easily deploy Ocata in a multi-node environment (1 Controller, 1
Network and 2 Computes), using regular "neutron-openvswitch-agent" and its
"ovs-firewall-driver".

 However, when I try the following instructions:

 https://docs.openstack.org/developer/networking-ovn/install.html

 It just doesn't work.

 From what I'm seeing, on Ubuntu, the package names are different, like
"ovn-central" for the controllers and "ovn-host" for the compute nodes.

 All steps on the above guide, works, no errors on logs. But, when I try to
launch an Instance, it fails, with errors on neutron-server.log:

 http://paste.openstack.org/show/605438/

 Looks like that Ubuntu have all the required packages but, just the
documentation that is not available.

 I really want to move to OVN, can't deal with Network Node and its
namespaces anymore. Also, we need DPDK, and OVN have a better support for
tunneled networks on top of DPDK.

 In my deployment, first, I deployed it with neutron-openvswitch-agents,
later, I deleted all instances, all stacks and all networks, changed it to
OVN, and tried again but, it failed.

 I really appreciate any help in this direction...

Thanks!
Thiago
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Request for documentation about Ocata on Ubuntu with Networking OVN

2017-04-04 Thread Martinx - ジェームズ

There are more errors on Compute node as well, nova.log:

http://paste.openstack.org/show/605439/

On 4 April 2017 at 15:14, Martinx - ジェームズ  wrote:

> Hello!
>
>  Currently, I'm trying to deploy Ocata with Networking OVN, so far, no
> success.
>
>  I can easily deploy Ocata in a multi-node environment (1 Controller, 1
> Network and 2 Computes), using regular "neutron-openvswitch-agent" and its
> "ovs-firewall-driver".
>
>  However, when I try the following instructions:
>
>  https://docs.openstack.org/developer/networking-ovn/install.html
>
>  It just doesn't work.
>
>  From what I'm seeing, on Ubuntu, the package names are different, like
> "ovn-central" for the controllers and "ovn-host" for the compute nodes.
>
>  All steps on the above guide, works, no errors on logs. But, when I try
> to launch an Instance, it fails, with errors on neutron-server.log:
>
>  http://paste.openstack.org/show/605438/
>
>  Looks like that Ubuntu have all the required packages but, just the
> documentation that is not available.
>
>  I really want to move to OVN, can't deal with Network Node and its
> namespaces anymore. Also, we need DPDK, and OVN have a better support for
> tunneled networks on top of DPDK.
>
>  In my deployment, first, I deployed it with neutron-openvswitch-agents,
> later, I deleted all instances, all stacks and all networks, changed it to
> OVN, and tried again but, it failed.
>
>  I really appreciate any help in this direction...
>
> Thanks!
> Thiago
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [scientific] Resource reservation requirements (Blazar) - Forum session

2017-04-04 Thread Tim Bell

Some combination of spot/OPIE and Blazar would seem doable as long as the 
resource provider reserves capacity appropriately (i.e. spot resources>>blazar 
committed along with no non-spot requests for the same aggregate).

Is this feasible?

Tim

On 04.04.17, 19:21, "Jay Pipes"  wrote:

On 04/03/2017 06:07 PM, Blair Bethwaite wrote:
> Hi Jay,
>
> On 4 April 2017 at 00:20, Jay Pipes  wrote:
>> However, implementing the above in any useful fashion requires that 
Blazar
>> be placed *above* Nova and essentially that the cloud operator turns off
>> access to Nova's  POST /servers API call for regular users. Because if 
not,
>> the information that Blazar acts upon can be simply circumvented by any 
user
>> at any time.
>
> That's something of an oversimplification. A reservation system
> outside of Nova could manipulate Nova host-aggregates to "cordon off"
> infrastructure from on-demand access (I believe Blazar already uses
> this approach), and it's not much of a jump to imagine operators being
> able to twiddle the available reserved capacity in a finite cloud so
> that reserved capacity can be offered to the subset of users/projects
> that need (or perhaps have paid for) it.

Sure, I'm following you up until here.

> Such a reservation system would even be able to backfill capacity
> between reservations. At the end of the reservation the system
> cleans-up any remaining instances and preps for the next
> reservation.

By "backfill capacity between reservations", do you mean consume 
resources on the compute hosts that are "reserved" by this paying 
customer at some date in the future? i.e. Spot instances that can be 
killed off as necessary by the reservation system to free resources to 
meet its reservation schedule?

> The are a couple of problems with putting this outside of Nova though.
> The main issue is that pre-emptible/spot type instances can't be
> accommodated within the on-demand cloud capacity.

Correct. The reservation system needs complete control over a subset of 
resource providers to be used for these spot instances. It would be like 
a hotel reservation system being used for a motel where cars could 
simply pull up to a room with a vacant sign outside the door. The 
reservation system would never be able to work on accurate data unless 
some part of the motel's rooms were carved out for reservation system to 
use and cars to not pull up and take.

 >  You could have the
> reservation system implementing this feature, but that would then put
> other scheduling constraints on the cloud in order to be effective
> (e.g., there would need to be automation changing the size of the
> on-demand capacity so that the maximum pre-emptible capacity was
> always available). The other issue (admittedly minor, but still a
> consideration) is that it's another service - personally I'd love to
> see Nova support these advanced use-cases directly.

Welcome to the world of microservices. :)

-jay

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

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

Re: [OpenStack-Infra] New caching reverse proxies

2017-04-04 Thread Paul Belanger

On Tue, Apr 04, 2017 at 11:12:38AM -0700, Clark Boylan wrote:
> Hello,
> 
> Just a heads up that we are experimenting with new caching reverse
> proxies on our cloud region local mirror nodes. The idea here being that
> not every hosted resource is easily mirrorable but we can pretty easily
> cache them locally in regions to reduce errors and speed up downloads.
> More details can be found in https://review.openstack.org/#/c/453241/
> (reviews welcome). The config is all done in the existing mirror host
> apache configuration.
> 
> Currently testing it out with RDO (rsyncs are slow and updates frequent
> so not good AFS mirroring candidate until those items can be sorted out)
> and the puppet modules and tripleo are consuming RDO from here. Possible
> future work includes proxying dockerhub for container image downloads.
> 
> Clark
> 
Thanks for suggesting them! They appear to be working really well. Look forward
to testing hub.docker.com.

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

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive


On 04/04/2017 12:14 PM, Daniel P. Berrange wrote:

On Tue, Apr 04, 2017 at 09:21:27AM -0700, Clark Boylan wrote:

On Tue, Apr 4, 2017, at 06:36 AM, Daniel P. Berrange wrote:

On Mon, Apr 03, 2017 at 04:06:53PM -0700, Clark Boylan wrote:

I have pushed a change to devstack [3] to enable using UCA which pulls
in new Libvirt and mostly seems to work. I think we should consider
switching to UCA as this may fix our Libvirt problems and if it doesn't,
we will be closer to a version of Libvirt that upstream should be
willing to fix.

This isn't the most straightfoward switch as UCA has a different repo
for each OpenStack release. libvirt-python is sensitve to the underlying
library changing; it is backward compatible but libvirt-python built
against older libvirt won't work against new libvirt. The result is a
libvirt-python wheel built on our wheel mirror does not work with UCA.


I'm surprised about that - could you elaborate on what's broken for you.
The libvirt.so provides a stable public API, and the standalone python
binding only uses public APIs from libvirt.so.  IOW you should be able
to build libvirt-python against 1.3.0 and then use it against 2.5.0 with
no problems.

NB, *before* libvirt-python lived on pypi, it used some non-public
libvirt.so symbols, so was tied to the exact libvirt.so it was built
against. Assuming you're using the pypi version this should no longer
apply.


The specific issue was "AttributeError: 'module' object has no attribute
'VIR_MIGRATE_POSTCOPY'" where module here is libvirt (full log and
traceback at [0]). The libvirt-python module here was built against
Libvirt 1.3.1 turned into a wheel and copied into our wheel mirror. Then
when running against Libvirt 2.5.0 Nova seems to have detected that
newer features should be present that are not reflected in the compiled
libvirt-python resulting in the error. This crashed nova compute.

Problem was easily corrected by preventing devstack from using our wheel
mirror for libvirt-python which resulted in a new installation built
against Libvirt 2.5.0.

It seems like the API is stable enough for backward compatibility but
not forward compatibility. Its also possible that Nova is doing version
checking in a buggy way and should be checking what the libvirt-python
version is and what it supports?


Ok, so yeah your last sentance is the correct interpretation. You've built
libvirt-python against libvirt v1.3.1, so it only includes support for
constants & methods that exist in that version. The VIR_MIGRATE_POSTCOPY
constant was introduced in v1.3.3, so it will not be included in the
libvirt-python you built.

When checking features Nova calls a libvirt API that returns the version
of the libvirtd daemon, which is v2.5.0, and then just blindly assumes
libvirt-python has the same version.

Unfortunately there is no way for Nova to determine what libvirt version
the python binding was built against, so it can't improve its version
check in this respect. To deal with this, Nova would two options:

 - Provide a nova.conf parameter to force it to assume an older libvirt
   version, thus disabling the features regardless of what libvirtd
   supports
 - Make nova check for existance of the python constants / APIs it is
   trying to use, in addition to checking the libvirt version

The first option is pretty trivial to do if needed. The second option would
be the more correct approach, but a much bigger maint burden, so I'm not
convinced it is worth it.


I'm not convinced either are worth it - I think if we just stop building 
libvirt wheels in our wheel mirror it'll resolve itself. Most places 
that are actually running OpenStack for real aren't going to be building 
their install packages blind to what version of the OS they're going to 
install on - so it's really only a problem with one of our gate 
optimizations.



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

Re: [openstack-dev] [manila] share server frameworks for DHSS=False case

2017-04-04 Thread Ben Swartzlander


On 04/03/2017 03:58 PM, Valeriy Ponomaryov wrote:



On Mon, Apr 3, 2017 at 10:00 PM, Ben Swartzlander > wrote:


... and we later gave up on supporting remote ZFS using SSH altogether.

-Ben


No, we didn't. It works. Just have couple of workarounds related to
difference of remote and local shell executors.


Thanks for this correction. While the SSH path isn't actively used we 
are fixing bugs in that code path so it remains a valid option.


-Ben



--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com 
vponomar...@mirantis.com 


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



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

[OpenStack-Infra] New caching reverse proxies

2017-04-04 Thread Clark Boylan

Hello,

Just a heads up that we are experimenting with new caching reverse
proxies on our cloud region local mirror nodes. The idea here being that
not every hosted resource is easily mirrorable but we can pretty easily
cache them locally in regions to reduce errors and speed up downloads.
More details can be found in https://review.openstack.org/#/c/453241/
(reviews welcome). The config is all done in the existing mirror host
apache configuration.

Currently testing it out with RDO (rsyncs are slow and updates frequent
so not good AFS mirroring candidate until those items can be sorted out)
and the puppet modules and tripleo are consuming RDO from here. Possible
future work includes proxying dockerhub for container image downloads.

Clark

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

Re: [openstack-dev] [oslo][requirements][designate][cinder] Reverting eventlet version bump

2017-04-04 Thread Clint Byrum

Excerpts from Monty Taylor's message of 2017-04-04 12:19:36 -0500:
> On 04/04/2017 09:19 AM, Jay S Bryant wrote:
> > Monty,
> >
> > I agree with your approach.  Think we should not break other projects
> > with a change like this and the answer thus far has been to just patch
> > each project individually to work around the issues introduced by
> > eventlet.  So, I support this approach and think Sean would as well.
> 
> To follow up with everyone - dims and I spent a bit of time this morning 
> testing combinations of things, and it seems that master of eventlet 
> actually also does not fix things - there are some issues that will just 
> need to be figured out.
> 
> The suggested path forward at the moment is to pull designate out of the 
> requirements-sync process so it can stay pinned at 0.19 while the issues 
> are sorted out. A patch to bump designate back to 0.20.1 can accompany 
> the patch to fix it for 0.20.1 - and can be done as people have time, 
> rather than in a rush.
> 

Has anyone made any attempt to eliminate eventlet from Designate? The
less places it's used, the less problems OpenStack seems to have, IMO.
But I can see on cursory examination it has quite a few services so
perhaps it's just too entrenched?

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

[openstack-dev] [refstack][interop-wg] Nomination of Luz Cazares as RefStack core

2017-04-04 Thread Catherine Cuong Diep




Hello everyone,

I would like to nominate Luz Cazares as a core reviewer for the RefStack
project.  Luz is one of the main contributors and has been actively
providing reviews and feedback over the last year in our project.  She will
be a fantastic addition to the RefStack core review team.

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

Re: [openstack-dev] [infra] Stop enabling EPEL mirror by default

2017-04-04 Thread Fox, Kevin M

It'll affect kolla-kubernetes, but we have a patch ready to go. Go for it.

Thanks,
Kevin

From: Emilien Macchi [emil...@redhat.com]
Sent: Tuesday, April 04, 2017 10:28 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [infra] Stop enabling EPEL mirror by default

On Tue, Apr 4, 2017 at 1:02 PM, Paul Belanger  wrote:
> Greetings,
>
> Recently we've been running into some issues keeping our EPEL mirror properly
> sync'd. We are working to fix this, however we'd also like to do the 
> following:
>
>   Stop enabling EPEL mirror by default
>   https://review.openstack.org/#/c/453222/
>
> For the most part, we enable EPEL for our image build process, this to install
> haveged.  However, it is also likely the majority of centos-7 projects don't
> actually need EPEL.  I know specifically both RDO and TripleO avoid using the
> EPEL repository because of how unstable it is.
>
> Since it is possible this could be a breaking change, jobs will still be able 
> to
> use EPEL, but it will be an opt-in process. Your jobs will need to be updated 
> to
> do:
>
>   $ sudo yum-config-manager --enable epel
>
> Feel free to join us in openstack-infra if you have any questions or concerns.

On behalf of Puppet OpenStack and TripleO groups (both high consumers
of centos-7 nodes): no blocker, go for it.

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



--
Emilien Macchi

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

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

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive


On 04/04/2017 12:05 PM, Ihar Hrachyshka wrote:

I mentioned that in a meeting today but for greater visibility...

This change in how we gate against LTS raises a question whether what
we claim in: 
https://review.openstack.org/#/c/402940/4/reference/project-testing-interface.rst
is still valid. The wording of the document is such that suggests we
test against LTS, and with the UCA adoption in gate, that will no
longer be true. I am not against the change per se, I just want the
decision to be thought through and advertised to consumers beyond
tight circle of upstream developers.


Totally - and that's a good point. I think we may just need to update 
the wording some. The intent has always been that we develop targetting 
the software we think is appropriate for OpenStack- but the LTS line and 
testing are to ensure we don't introduce a dependency that's 
unreasonably hard to backport on top of an LTS release.


An example of that would be growing a dependency on a kernel feature 
that would be too much to backport - or if we had decided to move to 
Python3 back in the RHEL6 days (before there was a python3 available)


RDO and UCA are both ways that the distro vendors themselves are 
providing backport software on top of their LTS releases. So if it's in 
one of those the distro vendor themselves have de-facto communicated 
that it's not unreasonable to backport that piece of software to run on 
top of the LTS - since they have already done it.


All of that is not spelled out clearly though - so I agree, it would be 
potentially useful to describe that situation more clearly in the PTI.



Ihar

On Mon, Apr 3, 2017 at 4:39 PM, Clark Boylan  wrote:

On Mon, Apr 3, 2017, at 04:33 PM, Ihar Hrachyshka wrote:

Are we going to keep some job not using the archive, to make sure we
don't
break people using packages from LTS? Maybe just periodic/non-voting
would
be enough to keep it working on older packages.


Old stable branches will continue to run against the base LTS release.
But considering that this is how users of Ubuntu get newer packages, the
deployment projects are using it for newer branches, and we know that
the base LTS is broken, I'm not sure how much benefit there would be to
keep testing on the base LTS if we make the switch.

Its important to note that anyone using base LTS is broken and we know
this because of our testing.

Clark

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


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




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

Re: [openstack-dev] [infra] Stop enabling EPEL mirror by default

On Tue, Apr 4, 2017 at 1:02 PM, Paul Belanger  wrote:
> Greetings,
>
> Recently we've been running into some issues keeping our EPEL mirror properly
> sync'd. We are working to fix this, however we'd also like to do the 
> following:
>
>   Stop enabling EPEL mirror by default
>   https://review.openstack.org/#/c/453222/
>
> For the most part, we enable EPEL for our image build process, this to install
> haveged.  However, it is also likely the majority of centos-7 projects don't
> actually need EPEL.  I know specifically both RDO and TripleO avoid using the
> EPEL repository because of how unstable it is.
>
> Since it is possible this could be a breaking change, jobs will still be able 
> to
> use EPEL, but it will be an opt-in process. Your jobs will need to be updated 
> to
> do:
>
>   $ sudo yum-config-manager --enable epel
>
> Feel free to join us in openstack-infra if you have any questions or concerns.

On behalf of Puppet OpenStack and TripleO groups (both high consumers
of centos-7 nodes): no blocker, go for it.

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



-- 
Emilien Macchi

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

[Openstack] Deployment fails

2017-04-04 Thread Konstantin Raskoshnyi

Hi guys, I added 4 modes (2 controllers, nova & cinder)

When I deploy them master node fails with this error

All nodes are finished. Failed tasks: Task[build_deploy_image/master]
Stopping the deployment process

Master node has internet access, I can ping ubuntu servers + all slave
nodes has access to internet and pass networking test

Any thought?


Snippet

{ "status": "running", "idling": 0, "lastrun": 1491323459, "enabled": 1,
"raw_report": null, "running": 1, "version": null, "stopped": 0, "time": {
"last_run": 0 }, "output": "Currently running; last completed run 1794
seconds ago", "runtime": 1794, "changes": null, "events": null,
"resources": { "changed_resources": "", "failed_resources": "",
"out_of_sync": 0, "changed": 0, "failed": 1, "restarted": 0, "total": 0 } }
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [oslo][requirements][designate][cinder] Reverting eventlet version bump


On 04/04/2017 09:19 AM, Jay S Bryant wrote:

Monty,

I agree with your approach.  Think we should not break other projects
with a change like this and the answer thus far has been to just patch
each project individually to work around the issues introduced by
eventlet.  So, I support this approach and think Sean would as well.


To follow up with everyone - dims and I spent a bit of time this morning 
testing combinations of things, and it seems that master of eventlet 
actually also does not fix things - there are some issues that will just 
need to be figured out.


The suggested path forward at the moment is to pull designate out of the 
requirements-sync process so it can stay pinned at 0.19 while the issues 
are sorted out. A patch to bump designate back to 0.20.1 can accompany 
the patch to fix it for 0.20.1 - and can be done as people have time, 
rather than in a rush.



On 4/4/2017 8:33 AM, Monty Taylor wrote:

Hey all,

We recently increased the version of eventlet we're using. The bump
was driven by python3.5 enablement for oslo.messaging, which is a
great thing to have exist. However, it has hard-broken designate - and
not just the docs builds like happened for other projects.

There is a patch that has landed to upstream eventlet that will fix
the designate issues, but it is not yet released.

I'd like to propose we revert the U-C bump and block 0.20 in our
requirements. This hamstrings the 3.5 enablement a bit, but it
unbreaks designate, and I'd argue that we need to prioritize not
breaking services in cases like this. (also, because designate is
broken, openstack-ansible has gate issues, and shade had gate issues
until we removed designate from our gate config which was extremely
sad making)

Sean McGinnis already proposed a patch to revert the bump:

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

which I think we should restore, then modify it to also include a
requirements block. As soon as 0.21 is released, we can upgrade to
that and get 3.5 for oslo.messaging back on track.

Thoughts?

Monty

__

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



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



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

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

2017-04-04 Thread Daniel P. Berrange

On Tue, Apr 04, 2017 at 09:21:27AM -0700, Clark Boylan wrote:
> On Tue, Apr 4, 2017, at 06:36 AM, Daniel P. Berrange wrote:
> > On Mon, Apr 03, 2017 at 04:06:53PM -0700, Clark Boylan wrote:
> > > I have pushed a change to devstack [3] to enable using UCA which pulls
> > > in new Libvirt and mostly seems to work. I think we should consider
> > > switching to UCA as this may fix our Libvirt problems and if it doesn't,
> > > we will be closer to a version of Libvirt that upstream should be
> > > willing to fix.
> > > 
> > > This isn't the most straightfoward switch as UCA has a different repo
> > > for each OpenStack release. libvirt-python is sensitve to the underlying
> > > library changing; it is backward compatible but libvirt-python built
> > > against older libvirt won't work against new libvirt. The result is a
> > > libvirt-python wheel built on our wheel mirror does not work with UCA.
> > 
> > I'm surprised about that - could you elaborate on what's broken for you.
> > The libvirt.so provides a stable public API, and the standalone python
> > binding only uses public APIs from libvirt.so.  IOW you should be able
> > to build libvirt-python against 1.3.0 and then use it against 2.5.0 with
> > no problems.
> > 
> > NB, *before* libvirt-python lived on pypi, it used some non-public
> > libvirt.so symbols, so was tied to the exact libvirt.so it was built
> > against. Assuming you're using the pypi version this should no longer
> > apply.
> 
> The specific issue was "AttributeError: 'module' object has no attribute
> 'VIR_MIGRATE_POSTCOPY'" where module here is libvirt (full log and
> traceback at [0]). The libvirt-python module here was built against
> Libvirt 1.3.1 turned into a wheel and copied into our wheel mirror. Then
> when running against Libvirt 2.5.0 Nova seems to have detected that
> newer features should be present that are not reflected in the compiled
> libvirt-python resulting in the error. This crashed nova compute.
> 
> Problem was easily corrected by preventing devstack from using our wheel
> mirror for libvirt-python which resulted in a new installation built
> against Libvirt 2.5.0.
> 
> It seems like the API is stable enough for backward compatibility but
> not forward compatibility. Its also possible that Nova is doing version
> checking in a buggy way and should be checking what the libvirt-python
> version is and what it supports?

Ok, so yeah your last sentance is the correct interpretation. You've built
libvirt-python against libvirt v1.3.1, so it only includes support for
constants & methods that exist in that version. The VIR_MIGRATE_POSTCOPY
constant was introduced in v1.3.3, so it will not be included in the
libvirt-python you built.

When checking features Nova calls a libvirt API that returns the version
of the libvirtd daemon, which is v2.5.0, and then just blindly assumes
libvirt-python has the same version.

Unfortunately there is no way for Nova to determine what libvirt version
the python binding was built against, so it can't improve its version
check in this respect. To deal with this, Nova would two options:

 - Provide a nova.conf parameter to force it to assume an older libvirt
   version, thus disabling the features regardless of what libvirtd
   supports
 - Make nova check for existance of the python constants / APIs it is
   trying to use, in addition to checking the libvirt version

The first option is pretty trivial to do if needed. The second option would
be the more correct approach, but a much bigger maint burden, so I'm not
convinced it is worth it.

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

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

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

2017-04-04 Thread Ihar Hrachyshka

I mentioned that in a meeting today but for greater visibility...

This change in how we gate against LTS raises a question whether what
we claim in: 
https://review.openstack.org/#/c/402940/4/reference/project-testing-interface.rst
is still valid. The wording of the document is such that suggests we
test against LTS, and with the UCA adoption in gate, that will no
longer be true. I am not against the change per se, I just want the
decision to be thought through and advertised to consumers beyond
tight circle of upstream developers.

Ihar

On Mon, Apr 3, 2017 at 4:39 PM, Clark Boylan  wrote:
> On Mon, Apr 3, 2017, at 04:33 PM, Ihar Hrachyshka wrote:
>> Are we going to keep some job not using the archive, to make sure we
>> don't
>> break people using packages from LTS? Maybe just periodic/non-voting
>> would
>> be enough to keep it working on older packages.
>
> Old stable branches will continue to run against the base LTS release.
> But considering that this is how users of Ubuntu get newer packages, the
> deployment projects are using it for newer branches, and we know that
> the base LTS is broken, I'm not sure how much benefit there would be to
> keep testing on the base LTS if we make the switch.
>
> Its important to note that anyone using base LTS is broken and we know
> this because of our testing.
>
> Clark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [infra] Stop enabling EPEL mirror by default

2017-04-04 Thread Paul Belanger

Greetings,

Recently we've been running into some issues keeping our EPEL mirror properly
sync'd. We are working to fix this, however we'd also like to do the following:

  Stop enabling EPEL mirror by default
  https://review.openstack.org/#/c/453222/

For the most part, we enable EPEL for our image build process, this to install
haveged.  However, it is also likely the majority of centos-7 projects don't
actually need EPEL.  I know specifically both RDO and TripleO avoid using the
EPEL repository because of how unstable it is.

Since it is possible this could be a breaking change, jobs will still be able to
use EPEL, but it will be an opt-in process. Your jobs will need to be updated to
do:

  $ sudo yum-config-manager --enable epel

Feel free to join us in openstack-infra if you have any questions or concerns.

-PB

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

Re: [Openstack] Not getting private network field in networks tab

2017-04-04 Thread pratik dave

Thanks for replying.

I do not see any Tenant or Private network on network tab.

As you can see in the screenshot attached.

On Apr 4, 2017 8:33 PM, "Konstantin Raskoshnyi"  wrote:

> Hi,
> Because you're using VLAN segmentation in this case you'll have 5 networks
>
> ADMIN Pxe
> Public*
> Storage*
> Tenants*
> Management*
>
> For network with * you can use vlans
>
>
> On Tue, Apr 4, 2017 at 5:30 AM pratik dave  wrote:
>
>> Hello Everyone,
>>
>> While deploying OpenStack environment we are getting error for network
>> verification.
>>
>> We are getting error verification failed. And expected VLAN not received
>> on ens192.
>>
>> Also we observed we are not getting private network field as we have seen
>> in many blogs and videos. We are getting option to enter public, management
>> and storage network details.
>>
>> Please find attached screenshot for your reference and request your
>> inputs to resolve the issue.
>> ___
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [novaclient] novaclient and httpretty - unable to record

2017-04-04 Thread Matt Riedemann


On 4/4/2017 8:09 AM, Monty Taylor wrote:

On 04/04/2017 04:43 AM, George Shuklin wrote:

Sorry for asking in dev maillist, but it really looks like dev issue.

I'm writing  application which relies on novaclient, glanceclient, etc.

It's almost done, but I thought about adding end to end tests by
recording and actual requests and replies to openstack. I used httpretty
library for this. Unfortunately, it ignores all requests and unable to
record them.


You might have better luck with either requests_mock or betamax. There
is a betamax test fixture in the keystoneauth1 that you can use if you
want to go the betamax route:

http://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/tests/unit/test_betamax_fixture.py


If you'd rather go requests_mock (which is what I've been using to great
pleasure) you can look in the shade test suite for some examples -
although it's a big test suite so things get complex:

http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/tests/unit/base.py#n398


http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/tests/unit/test_security_groups.py#n380



Does someone knew anything about httpretty and novaclient interaction?
(I think keystoneauth1 and other openstack clients behaves the same
way?).


I unfortunately don't know about httpretty and keystoneauth. I don't
know of any specific reason it shouldn't work, but as I use the other
things I have never explored it.


Code example:

import httpretty
from keystoneauth1 import identity
from keystoneauth1 import session
import novaclient.client
auth_data = {'tenant_name':'any', 'username': 'any', 'password': 'any',
'auth_url': 'https://google.com/does-not-matter/'}
with httpretty.HTTPretty.record('test.json'):
auth = identity.v2.Password(**auth_data)
s = session.Session(auth=auth)
cl = novaclient.client.Client('2', session=s)
z = cl.flavors.find(name='SSD.30')


Thanks!


__

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



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


FWIW novaclient unit tests already use requests_mock:

https://github.com/openstack/python-novaclient/blob/7.1.0/novaclient/tests/unit/utils.py

However, the actual framework in there is confusing, at least to me.

--

Thanks,

Matt

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

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

2017-04-04 Thread Clark Boylan

On Tue, Apr 4, 2017, at 06:36 AM, Daniel P. Berrange wrote:
> On Mon, Apr 03, 2017 at 04:06:53PM -0700, Clark Boylan wrote:
> > I have pushed a change to devstack [3] to enable using UCA which pulls
> > in new Libvirt and mostly seems to work. I think we should consider
> > switching to UCA as this may fix our Libvirt problems and if it doesn't,
> > we will be closer to a version of Libvirt that upstream should be
> > willing to fix.
> > 
> > This isn't the most straightfoward switch as UCA has a different repo
> > for each OpenStack release. libvirt-python is sensitve to the underlying
> > library changing; it is backward compatible but libvirt-python built
> > against older libvirt won't work against new libvirt. The result is a
> > libvirt-python wheel built on our wheel mirror does not work with UCA.
> 
> I'm surprised about that - could you elaborate on what's broken for you.
> The libvirt.so provides a stable public API, and the standalone python
> binding only uses public APIs from libvirt.so.  IOW you should be able
> to build libvirt-python against 1.3.0 and then use it against 2.5.0 with
> no problems.
> 
> NB, *before* libvirt-python lived on pypi, it used some non-public
> libvirt.so symbols, so was tied to the exact libvirt.so it was built
> against. Assuming you're using the pypi version this should no longer
> apply.

The specific issue was "AttributeError: 'module' object has no attribute
'VIR_MIGRATE_POSTCOPY'" where module here is libvirt (full log and
traceback at [0]). The libvirt-python module here was built against
Libvirt 1.3.1 turned into a wheel and copied into our wheel mirror. Then
when running against Libvirt 2.5.0 Nova seems to have detected that
newer features should be present that are not reflected in the compiled
libvirt-python resulting in the error. This crashed nova compute.

Problem was easily corrected by preventing devstack from using our wheel
mirror for libvirt-python which resulted in a new installation built
against Libvirt 2.5.0.

It seems like the API is stable enough for backward compatibility but
not forward compatibility. Its also possible that Nova is doing version
checking in a buggy way and should be checking what the libvirt-python
version is and what it supports?

[0]
http://logs.openstack.org/92/451492/4/check/gate-devstack-dsvm-updown-ubuntu-xenial/19dca66/logs/screen-n-cpu.txt.gz?level=ERROR#_2017-03-29_22_55_19_038

Hope this helps,
Clark

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

Re: [openstack-dev] [tripleo][kolla] extended start and hostpath persistent dirs (was: kolla_bootstrap for non-openstack services)

2017-04-04 Thread Bogdan Dobrelya

On 03.04.2017 21:01, Dan Prince wrote:
> On Mon, 2017-04-03 at 16:15 +0200, Bogdan Dobrelya wrote:
>> Let's please re-evaluate configuration of containerized non-
>> openstack,
>> like database, message queue, key value, web, services for tripleo
>> heat
>> templates and Kolla. Here is an example containerized etcd patch [0].
>>
>> tl;dr use kolla images and bootsrap OR upstream images with direct
>> commands:
>>
>> .. code-block:: yaml
>> kolla_config:
>> /var/lib/kolla/config_files/foo.json
>>   command: /usr/bin/foo
>>
>> vs
>>
>> .. code-block:: yaml
>> foo:
>> image: upstream/foo:latest
>> command: /usr/bin/foo
>>
>> Note, tht already doesn't use configs [1] copied into the images by
>> kolla build time. The next and logical step might be to omit kolla's
>> bootstrap, where applicable, as well.
> 
> The kolla config file copying proved to be a bit pedantic. So we
> removed it. A good example of this would be how this played out for the
> keystone service:
> 
> http://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?
> id=332e8ec10345ad5c8bf10a532f6f6003da682b68
> 
>>
>> There is a two options:
>> * use kolla images and bootstrap as t-h-t does now for all services
>> being containerized
> 
> We do not use KOLLA_BOOTSTRAP for all services now. Only 4 services use
> it currently I think. I think the general consensus is we should not be
> using it unless there is a functional requirement to do so. Services
> like Mysql and Rabbitmq have some extra initialization that needs to
> execute in-container before the services startup. We could duplicate
> this in tripleo-heat-templates, run it with docker-cmd perhaps and do
> it that way but we initially made exception for just a few services.
> 
> Other services like Glance are using it, but that is just historical.
> There is already a patch to remove the use of KOLLA_BOOTSTRAP for this
> service:
> 
> https://review.openstack.org/#/c/440884/1
> 
> So in summary the consensus is we'd prefer not to be using the
> KOLLA_BOOTSTRAP environment variables because in some cases there is a
> 'Kolla' flavor to these things that don't match how TripleO deploys
> things.
> 
> It is worth pointing out that while we aren't using KOLLA_BOOTSTRAP we
> are using the kolla startup systems in many cases. This gives some
> features around file permissions, extra sudoers files, etc. We may be
> able to stop using this for some services but I also think we are
> getting value out of the interfaces today. They aren't nearly as
> verbose as the Kolla config copying stuff so we could go either way.

That's interesting, there is related topic with hostpath mounted
persistent log dirs [0]. The issue is:

[tl;dr] kolla_config is a bad fit for logs, let's run containers' steps
as 'user: root' in a user namespace remapped [1] for a tripleocontainers
system user. Thoughts? And would that work for stock centos7/rhel7 kernels?


So, the issue is when log/data dirs created by host_prep_tasks, we must
configure host permissions in a simple non-opinionated way.
What I can see for t-h-t to cover it on its own:
* Custom entrypoints for containers adds complexity and head ache.
* Mount logs world writable is a non starter.
* Running containers as a user root is a security issue.

What I can see for Kolla to accomplish that task:
* the extended start does not cover logs and there are nuances with
recursive chowning and permissions of new files [2].
* log directories doesn't fit well into the kolla_config's volumes and
permissions defined in services' config.json. Using those for log
volumes would look like a dirty hack. This also would undo the recent
changes with using hostpath mounts instead of the kolla_config volumes.

That's why I came to the option with 'user: root' and remapped user
namespace for docker daemon. Please share your thoughts.

[0] https://review.openstack.org/#/c/442603/
[1] https://goo.gl/HtDQYk
[2] https://review.openstack.org/#/c/452742/

> 
>> pros: same way to template everything, kolla build/start just works.
>> risks: non-openstack services, eventually, may stop being supported
>> by
>> Kolla for number of reasons. Kolla bootstrap changes aren't tested in
>> tripleo CI and might be breaking
>> cons: locking in to the kolla opinionated bootstrap entry points and
>> kolla_config's config.json and command.
>>
>> * if applicable to the service, use upstream images (etcd example
>> [2])
>> w/o any kolla parts.
>> pros: less moving parts like custom entry points, no locking in
>> onto opinionated Kolla config/bootstrap
>> risks: Upstream image changes aren't tested in tripleo CI and might
>> be
>> breaking
>> cons: different ways to template openstack/non-openstack services,
>> kolla
>> build/start doesn't work for the latter.
>>
>> [0] https://review.openstack.org/#/c/447627/
>> [1] https://review.openstack.org/#/c/451366
>> [2]
>> https://review.openstack.org/#/c/445883/2/contrib/overcloud_container
>> s.yaml
>>
> 
>

Re: [openstack-dev] [novaclient] novaclient and httpretty - unable to record

2017-04-04 Thread George Shuklin


Thank you very much for advise!

On 04/04/2017 04:09 PM, Monty Taylor wrote:

On 04/04/2017 04:43 AM, George Shuklin wrote:

Sorry for asking in dev maillist, but it really looks like dev issue.

I'm writing  application which relies on novaclient, glanceclient, etc.

It's almost done, but I thought about adding end to end tests by
recording and actual requests and replies to openstack. I used httpretty
library for this. Unfortunately, it ignores all requests and unable to
record them.


You might have better luck with either requests_mock or betamax. There 
is a betamax test fixture in the keystoneauth1 that you can use if you 
want to go the betamax route:


http://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/tests/unit/test_betamax_fixture.py 



If you'd rather go requests_mock (which is what I've been using to 
great pleasure) you can look in the shade test suite for some examples 
- although it's a big test suite so things get complex:


http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/tests/unit/base.py#n398 



http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/tests/unit/test_security_groups.py#n380 




Does someone knew anything about httpretty and novaclient interaction?
(I think keystoneauth1 and other openstack clients behaves the same 
way?).


I unfortunately don't know about httpretty and keystoneauth. I don't 
know of any specific reason it shouldn't work, but as I use the other 
things I have never explored it.



Code example:

import httpretty
from keystoneauth1 import identity
from keystoneauth1 import session
import novaclient.client
auth_data = {'tenant_name':'any', 'username': 'any', 'password': 'any',
'auth_url': 'https://google.com/does-not-matter/'}
with httpretty.HTTPretty.record('test.json'):
auth = identity.v2.Password(**auth_data)
s = session.Session(auth=auth)
cl = novaclient.client.Client('2', session=s)
z = cl.flavors.find(name='SSD.30')


Thanks!


__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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




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

Re: [Openstack] Not getting private network field in networks tab

2017-04-04 Thread Konstantin Raskoshnyi

Hi,
Because you're using VLAN segmentation in this case you'll have 5 networks

ADMIN Pxe
Public*
Storage*
Tenants*
Management*

For network with * you can use vlans


On Tue, Apr 4, 2017 at 5:30 AM pratik dave  wrote:

> Hello Everyone,
>
> While deploying OpenStack environment we are getting error for network
> verification.
>
> We are getting error verification failed. And expected VLAN not received
> on ens192.
>
> Also we observed we are not getting private network field as we have seen
> in many blogs and videos. We are getting option to enter public, management
> and storage network details.
>
> Please find attached screenshot for your reference and request your inputs
> to resolve the issue.
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [neutron][networking-l2gw] openstack vtep setup missing docs

2017-04-04 Thread Saverio Proto

Hello Armando,

I managed to implement the L2GW setup purely in software, without an
hardware appliance.

I documented in the README file, please look at this review
https://review.openstack.org/453209

I have a question: do we have a name for this node where the actually
bridging happens between a VXLAN tenant network and a physical L2 network ?
Is it okay to call it the l2gw node ?

The l2gw plugin it self runs on the controller, so also the
neutron-l2gw-plugin agent runs on the controller.

I think it necessary to clarify this naming, because before trying the
software I did the mistake of thinking that the neutron-l2gw-agent had
to run on the switch where the actual briding happens.

thank you

Saverio




On 30/03/17 18:40, Armando M. wrote:
> 
> 
> On 30 March 2017 at 08:47, Saverio Proto  > wrote:
> 
> Hello,
> 
> I am trying to use the neutron l2gw plugin, but I am not using a bare
> metal switch to bridge.
> 
> I am using a server with Openvswitch.
> 
> 
> I am not aware of any effort to implement L2GW purely in software, in
> fact this was one key missing pieces that prevented the project to have
> CI solely dealt with the upstream infra resources. Perhaps OVN may come
> to the rescue here, I recall at some point the team was looking at the
> L2GW API.
> 
> Thanks,
> Armando
>  
> 
> 
> Following this documentation:
> 
> http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
> 
> 
> At one point there is this command:
> 
> sudo vtep-bootstrap L5 10.0.0.5 192.168.91.21 --no_encryption
> 
> This vtep-bootstrap is specific for Cumulux Linux
> 
> Anybody has documentation with normal vtep-ctl commands ?
> 
> So far on the Ubuntu server I did the following:
> 
> apt-get install openvswitch-vtep
> ovsdb-tool create /etc/openvswitch/vtep.db
> /usr/share/openvswitch/vtep.ovsschema
> 
> Anyone has more complete documentation ?
> 
> I did not understand if the vtep-openvswitch controlled by the l2gw
> plugin will make vxlan tunnels to all the compute nodes, to bridge the
> tenant network with a physical l2 network ? Or all this traffic has to
> pass to the network node also because the vtep openvswitch is not able
> to talk to the compute nodes ?
> 
> thank you
> 
> Saverio
> 
> 
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch ,
> http://www.switch.ch
> 
> http://www.switch.ch/stories
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

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

[Openstack] [aodh] alarm-action posts don't seem to have any payload

2017-04-04 Thread Mike Smith

Hello

We recently transitioned from ‘legacy’ Ceilometer to Ceilometer+AODH+Gnocchi in 
our Mitaka cloud.   One thing I noticed is that the alarm-action HTTP POSTs 
don’t seem to contain data about the alarm.  In our old config, we used to 
receive information like this from the POST from Ceilometer’s alarm notifier:

  


The POSTs that come from the AODH notifier look like this:



The AODH notifier log about the alarm shows:

2017-04-04 08:22:15.151 64223 INFO aodh.notifier.rest [-] Notifying alarm 
clubo:cpu_low c97e05ad-d85c-464f-8026-765c372fdce5 with severity low from alarm 
to alarm with action SplitResult(scheme=u'https', netloc=u'XXX', 
path=u'/api/scaling/remove/XXX/', query='', fragment='') because Remaining as 
alarm due to 1 samples outside threshold, most recent: 9.59306036578. 
request-id: req-e676dab8-664a-4891-af69-2a2753e1a65d

Is this expected?  Is there a way to configure AODH to include this type of 
information in it’s POST payload for the alarm-actions?

Thanks,


Mike Smith
Lead Cloud Systems Architect
Overstock.com



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [oslo][requirements][designate][cinder] Reverting eventlet version bump

2017-04-04 Thread Jay S Bryant


Monty,

I agree with your approach.  Think we should not break other projects 
with a change like this and the answer thus far has been to just patch 
each project individually to work around the issues introduced by 
eventlet.  So, I support this approach and think Sean would as well.


Thanks,

Jay



On 4/4/2017 8:33 AM, Monty Taylor wrote:

Hey all,

We recently increased the version of eventlet we're using. The bump 
was driven by python3.5 enablement for oslo.messaging, which is a 
great thing to have exist. However, it has hard-broken designate - and 
not just the docs builds like happened for other projects.


There is a patch that has landed to upstream eventlet that will fix 
the designate issues, but it is not yet released.


I'd like to propose we revert the U-C bump and block 0.20 in our 
requirements. This hamstrings the 3.5 enablement a bit, but it 
unbreaks designate, and I'd argue that we need to prioritize not 
breaking services in cases like this. (also, because designate is 
broken, openstack-ansible has gate issues, and shade had gate issues 
until we removed designate from our gate config which was extremely 
sad making)


Sean McGinnis already proposed a patch to revert the bump:

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

which I think we should restore, then modify it to also include a 
requirements block. As soon as 0.21 is released, we can upgrade to 
that and get 3.5 for oslo.messaging back on track.


Thoughts?

Monty

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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



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

Re: [openstack-dev] [oslo][requirements][designate][cinder] Reverting eventlet version bump


On 04/04/2017 08:37 AM, Davanum Srinivas wrote:

Monty,

Got a link to "patch that has landed to upstream eventlet that will
fix the designate issues"?


https://github.com/eventlet/eventlet/commit/78f2ef8a81600d19d6d670803ef73747ab8d81b9


Thanks,
Dims

On Tue, Apr 4, 2017 at 9:33 AM, Monty Taylor  wrote:

Hey all,

We recently increased the version of eventlet we're using. The bump was
driven by python3.5 enablement for oslo.messaging, which is a great thing to
have exist. However, it has hard-broken designate - and not just the docs
builds like happened for other projects.

There is a patch that has landed to upstream eventlet that will fix the
designate issues, but it is not yet released.

I'd like to propose we revert the U-C bump and block 0.20 in our
requirements. This hamstrings the 3.5 enablement a bit, but it unbreaks
designate, and I'd argue that we need to prioritize not breaking services in
cases like this. (also, because designate is broken, openstack-ansible has
gate issues, and shade had gate issues until we removed designate from our
gate config which was extremely sad making)

Sean McGinnis already proposed a patch to revert the bump:

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

which I think we should restore, then modify it to also include a
requirements block. As soon as 0.21 is released, we can upgrade to that and
get 3.5 for oslo.messaging back on track.

Thoughts?

Monty

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







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

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

2017-04-04 Thread Jesse Pretorius

On 4/4/17, 12:06 AM, "Clark Boylan"  wrote:

> After some thought I think my preferred method of rolling this out would
> be to blacklist libvirt-python from our wheel mirror building entirely
> and force installs to happen from source so that we are base Xenial and
> $UCA_version independent (local testing of these builds show it only
> takes a few seconds). Then have specific jobs (like devstack) explicitly
> opt into the UCA repo appropriate for them (if any). This last bit is
> from feedback from OpenStack Ansible that having the base images be
> fairly clean is desirable, but it would also be hard to know which
> version of UCA is appropriate for our Xenial images (this likely differs
> based on the job).

An approach that could be taken here is to bake the repo config (and install 
packages from that repo) for the UCA version that’s the earliest version we 
support for that OS. For example – the earliest version that supports Xenial is 
Newton, so pre-configure and install packages into the image from UCA 
Xenial/Newton. Then in any jobs which care about which version of UCA is used 
the repo config can be changed and the packages updated. This potentially saves 
a little gate time.

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

Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

2017-04-04 Thread Daniel P. Berrange

On Tue, Apr 04, 2017 at 07:16:51AM -0400, Sean Dague wrote:
> This is definitely a trade off, I know the last time we tried UCA we had
> such a high failure rate we had to revert. But, that was a much younger
> libvirt that was only just starting to get heavy testing in OpenStack.
> So it feels like it's worth a shot. It will at least be interesting to
> see if it makes things better.
> 
> The libvirt bump will bring in libvirtd and live migration postcopy for
> testability on the Nova side, both of which would be good things.

NB, you'd need corresponding QEMU bump too for post-copy, but IIUC the
UCA contain that, so it'd be fine.


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

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

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

2017-04-04 Thread Daniel P. Berrange

On Mon, Apr 03, 2017 at 04:06:53PM -0700, Clark Boylan wrote:
> Hello,
> 
> One of the major sets of issues currently affecting gate testing is
> Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> and they happen frequently [0][1][2]. These issues appear to only affect
> Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> #openstack-nova it is clear that Libvirt isn't interested in debugging
> such an old version of Libvirt (1.3.1). And while it isn't entirely
> clear to me which exact version would be acceptable to them the Ubuntu
> Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).

If going to the libvirt upstream community for help, we'd generally want
to see the latest upstream release being used. Ideally along with willingness
to test git master if investigating a troublesome issue, but we understand
using git master is not practical for many people.

If using an old version provided by an OS distro, then we would generally
expect the OS distro maintainers to lead the investigation, and take the
responsibility for reproducing on latest upstream. Upstream libvirt simply
doesn't have bandwidth to do the OS distro maintainers job for them when
using old distro versions.

> I have pushed a change to devstack [3] to enable using UCA which pulls
> in new Libvirt and mostly seems to work. I think we should consider
> switching to UCA as this may fix our Libvirt problems and if it doesn't,
> we will be closer to a version of Libvirt that upstream should be
> willing to fix.
> 
> This isn't the most straightfoward switch as UCA has a different repo
> for each OpenStack release. libvirt-python is sensitve to the underlying
> library changing; it is backward compatible but libvirt-python built
> against older libvirt won't work against new libvirt. The result is a
> libvirt-python wheel built on our wheel mirror does not work with UCA.

I'm surprised about that - could you elaborate on what's broken for you.
The libvirt.so provides a stable public API, and the standalone python
binding only uses public APIs from libvirt.so.  IOW you should be able
to build libvirt-python against 1.3.0 and then use it against 2.5.0 with
no problems.

NB, *before* libvirt-python lived on pypi, it used some non-public
libvirt.so symbols, so was tied to the exact libvirt.so it was built
against. Assuming you're using the pypi version this should no longer
apply.

> Now its entirely possible that newer Libvirt will be worse than current
> (old) Libvirt; however, being closer to upstream should make getting
> fixes easier. Would be great if those with a better understanding of
> Libvirt could chime in on this if I am completely wrong here.

As a general rule your expectation is right - newer libvirt should
generally be better. There is always the chance of screwups, but we issue
maint releases where needed - the only question mark would be whether UCA
pulls in any maint releases. I would like to think that if such a problem
happened, openstack would be able to escalate it to a Canonical maintainer
to get a maint release / patch into UCA, since presumably any such bug
would be important to Canonical customers using OpenStack too.

> Finally it is worth noting that we will get newer packages of other
> software as well, most notably openvswitch will be version 2.6.1 instead
> of 2.5.0.

IIUC, you'd get newer QEMU/KVM too, which is arguably just as desirable
as getting newer libvirt.

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

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

Re: [openstack-dev] [oslo][requirements][designate][cinder] Reverting eventlet version bump

2017-04-04 Thread Davanum Srinivas

Monty,

Got a link to "patch that has landed to upstream eventlet that will
fix the designate issues"?

Thanks,
Dims

On Tue, Apr 4, 2017 at 9:33 AM, Monty Taylor  wrote:
> Hey all,
>
> We recently increased the version of eventlet we're using. The bump was
> driven by python3.5 enablement for oslo.messaging, which is a great thing to
> have exist. However, it has hard-broken designate - and not just the docs
> builds like happened for other projects.
>
> There is a patch that has landed to upstream eventlet that will fix the
> designate issues, but it is not yet released.
>
> I'd like to propose we revert the U-C bump and block 0.20 in our
> requirements. This hamstrings the 3.5 enablement a bit, but it unbreaks
> designate, and I'd argue that we need to prioritize not breaking services in
> cases like this. (also, because designate is broken, openstack-ansible has
> gate issues, and shade had gate issues until we removed designate from our
> gate config which was extremely sad making)
>
> Sean McGinnis already proposed a patch to revert the bump:
>
> https://review.openstack.org/#/c/448104/
>
> which I think we should restore, then modify it to also include a
> requirements block. As soon as 0.21 is released, we can upgrade to that and
> get 3.5 for oslo.messaging back on track.
>
> Thoughts?
>
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

[openstack-dev] [oslo][requirements][designate][cinder] Reverting eventlet version bump


Hey all,

We recently increased the version of eventlet we're using. The bump was 
driven by python3.5 enablement for oslo.messaging, which is a great 
thing to have exist. However, it has hard-broken designate - and not 
just the docs builds like happened for other projects.


There is a patch that has landed to upstream eventlet that will fix the 
designate issues, but it is not yet released.


I'd like to propose we revert the U-C bump and block 0.20 in our 
requirements. This hamstrings the 3.5 enablement a bit, but it unbreaks 
designate, and I'd argue that we need to prioritize not breaking 
services in cases like this. (also, because designate is broken, 
openstack-ansible has gate issues, and shade had gate issues until we 
removed designate from our gate config which was extremely sad making)


Sean McGinnis already proposed a patch to revert the bump:

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

which I think we should restore, then modify it to also include a 
requirements block. As soon as 0.21 is released, we can upgrade to that 
and get 3.5 for oslo.messaging back on track.


Thoughts?

Monty

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

Re: [openstack-dev] [openstack-ansible] Adding a scenario for shade's functional tests

2017-04-04 Thread Jesse Pretorius

On 4/4/17, 1:39 PM, "Monty Taylor"  wrote:

>I'd love to make a gate job that:
>   - Deploys a cloud with openstack-ansible
>   - Runs shade's functional tests against that cloud

Fantastic. Let’s see how we can help.

>   Which makes me think it just needs to be an additional scenario perhaps?

Maybe. Our scenario’s, right now, are focused more around what 
Infrastructure/OpenStack services are deployed. If you want/need a larger set 
than our default ‘aio’ scenario, then yes a different scenario would need to be 
setup. The alternative, of course, is to override the confd_overrides var in 
your test setup with an ‘aio’ scenario of your own – but I think it’d be nice 
to rather bake whatever you need in so that we can help maintain it.
https://github.com/openstack/openstack-ansible/blob/master/tests/bootstrap-aio.yml#L28-L46

>As I started to poke, I need to figure out the best way to accomplish
>something. Namely, shade's functional tests expect a clouds.yaml that
>defines two entires - one admin and one non-admin.

>OSA already creates a clouds.yaml with admin creds, so that's done. And
>there is already tempest setup that creates a demo user, so that's done
>too. Here's where I could use some advice:

>- What's the best way to plumb through an option to also write an entry
>to clouds.yaml for the demo user? I'm thinking a boolean in
>openstack-ansible-openstack_openrc like
>"openrc_clouds_yml_add_demo_user" that can be wrapped around a second
>entry in clouds.yaml.j2?

Well, an option could be that an arbitrary dict could be looped through to add 
any content for additional entries in clouds.yml – we could then have the 
tempest demo account settings pulled out of the tempest role (they’re hard 
coded there now, and probably should not be), then have the role loop through 
the same dict if it’s defined. The dict can then be defined in the utility_all 
group vars or are perhaps best only set in the AIO prep config (so that they 
don’t end up being used in production deployments).

>- Can we create the demo user and not run tempest? It's in the
>os_tempest role at the moment. Should I split out the user creation bits
>into a "test_setup" role that tempest depends on - and then also make a
>shade_test role that also depends on the test_setup role?

Well, creating a user and a different clouds.yaml file could also be done with 
a few tasks in a playbook. Unless there’s an opportunity for re-use I don’t 
really see the point of creating a role for it.

>- If we do a test_setup role, should that maybe just write a whole
>additional clouds.yaml out that has the admin and the demo user so that
>we don't have to put conditionals in places that also get used for prod
>deploys?

The existing tempest role creation of a static set of demo accounts is terrible 
anyway. We should ideally make them adaptable and ensure that the passwords are 
randomized.

Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [manila] share server frameworks for DHSS=False case

2017-04-04 Thread Tom Barron

question below, not just for Ben.  If you know, please respond.

On 04/03/2017 03:00 PM, Ben Swartzlander wrote:
> On 04/03/2017 02:24 PM, Tom Barron wrote:
...  ...

> While Manila doesn't care about 2 backends potentially sharing an IP,
> you do have to consider how the m-shr services interact with the daemon
> to avoid situations where they fight eachother. I haven't looked into
> the potential issues around sharing a Ganesha instance, but I know that
> the LVM driver, which uses nfs-kernel-server, does have some issues in
> this area which need fixing.

Do we know that there are concurrency issues with LVM driver due to
multiple backend processes messing with the LVM infra on a single host
vs concurrency issues due to multiple operations in multiple threads
within a single backend?

Do we have any bugs raised on issues of either type?

Thanks,

-- Tom

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

Re: [openstack-dev] [neutron] Engine facade

2017-04-04 Thread Gary Kotton

Thanks Kevin,
We will also need https://review.openstack.org/#/c/453048/ in some way or form.

From: Kevin Benton 
Reply-To: OpenStack List 
Date: Tuesday, April 4, 2017 at 1:18 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] Engine facade

I worked with Gary on IRC and discovered that we aren't making use of the flag 
added in [1], which makes adoption harder. I've proposed a patch to 
neutron-lib[2] that should alleviate some of these issues.

1. https://bugs.launchpad.net/oslo.db/+bug/1664643
2. https://review.openstack.org/#/c/453063/

On Tue, Apr 4, 2017 at 3:11 AM, Anna Taraday 
> wrote:
Hi!

This errors does not mean that foreign key usage is broken. This means that 
there is a mess with transactions. As you paste small piece of trace it is hard 
to say why this happen, but during my work I saw such errors and resolve them. 
And probably you need to revisit your unit tests.

Please, send me email directly with links for traces, does this happen on 
master branch, does it happen on one of your changes - it is hard to guess.

On Tue, Apr 4, 2017 at 11:16 AM Gary Kotton 
> wrote:
Hi,
The problem that we have is that any foreign key usage under transactions is 
now broken. An example of an exception that is raised is:

DBReferenceError: (sqlite3.IntegrityError) FOREIGN KEY constraint failed 
[SQL: u'INSERT INTO neutron_nsx_firewall_section_mappings (created_at, 
updated_at, neutron_id, nsx_id) VALUES (?, ?, ?, ?)'] [parameters: ('2017-04-04 
06:48:25.595118', None, '6a086bf1-b1c9-495f-bfca-810d6638e3fa', 
'2563cd05-edd9-4c7f-9708-857a129e2642')]

This is a major refactor in the plugin (which I guess is part and parcel of 
rolling with the punches). I am just concerned if we are the only folks that 
have affected by this.
Thanks
Gary

From: Gary Kotton >
Reply-To: OpenStack List 
>
Date: Monday, April 3, 2017 at 3:14 PM

To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] Engine facade

Hi,
We needed to make all of those changes to just get the plugin to pass unit 
tests and CI. We are still seeing lots of issues and need to look deeper. The 
façade changes have caused a lot of instability issues. I am not 100% sure why. 
Issues that we have seen:
1. object creation under a transaction broke
2. deleting DB entries under transaction also broke
Thanks
Gary

From: Anna Taraday 
>
Reply-To: OpenStack List 
>
Date: Monday, April 3, 2017 at 11:53 AM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] Engine facade

Hi!

I'm a little confused change https://review.openstack.org/#/c/452539/ is about 
switching for new facade, does the master branch fails the same?

On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton 
> wrote:
Yes, sorry my bad for not adding it - 
http://logs.openstack.org/39/452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/14c019c/testr_results.html.gz
Please see the test test_create_port_dns_name
Thanks
Gary

From: Kevin Benton 
Reply-To: OpenStack List 
>
Date: Monday, April 3, 2017 at 12:56 AM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] Engine facade

Do you have a link to a traceback?

On Apr 2, 2017 09:25, "Gary Kotton" 
> wrote:
Hi,
The change https://review.openstack.org/#/c/402750/ has broken the vmware-nsx 
plugin. I am not sure if this has had effect on any other decomposed plugins.
One of the issues that we have is when we create a PortDNS object under a 
transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError) 
FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id, 
current_dns_name, current_dns_domain, previous_dns_name, previous_dns_domain, 
dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters: 
('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'', u'port-dns-name')]
Any ideas?
Thanks
Gary

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

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive


On 04/03/2017 06:06 PM, Clark Boylan wrote:

Hello,

One of the major sets of issues currently affecting gate testing is
Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
and they happen frequently [0][1][2]. These issues appear to only affect
Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
#openstack-nova it is clear that Libvirt isn't interested in debugging
such an old version of Libvirt (1.3.1). And while it isn't entirely
clear to me which exact version would be acceptable to them the Ubuntu
Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).

I have pushed a change to devstack [3] to enable using UCA which pulls
in new Libvirt and mostly seems to work. I think we should consider
switching to UCA as this may fix our Libvirt problems and if it doesn't,
we will be closer to a version of Libvirt that upstream should be
willing to fix.

This isn't the most straightfoward switch as UCA has a different repo
for each OpenStack release. libvirt-python is sensitve to the underlying
library changing; it is backward compatible but libvirt-python built
against older libvirt won't work against new libvirt. The result is a
libvirt-python wheel built on our wheel mirror does not work with UCA.
On the positive side both the OpenStack puppet modules and OpenStack
Ansible are using UCA with their deployment tooling so this should get
us closer to what people are using in the wild.

After some thought I think my preferred method of rolling this out would
be to blacklist libvirt-python from our wheel mirror building entirely
and force installs to happen from source so that we are base Xenial and
$UCA_version independent (local testing of these builds show it only
takes a few seconds). Then have specific jobs (like devstack) explicitly
opt into the UCA repo appropriate for them (if any). This last bit is
from feedback from OpenStack Ansible that having the base images be
fairly clean is desirable, but it would also be hard to know which
version of UCA is appropriate for our Xenial images (this likely differs
based on the job).

Now its entirely possible that newer Libvirt will be worse than current
(old) Libvirt; however, being closer to upstream should make getting
fixes easier. Would be great if those with a better understanding of
Libvirt could chime in on this if I am completely wrong here.

Finally it is worth noting that we will get newer packages of other
software as well, most notably openvswitch will be version 2.6.1 instead
of 2.5.0.

Any other thoughts or ideas?


I think it's a great idea. I don't think there is actual value in trying 
to support ludicrously old libvirt.



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

Re: [Openstack] Slow internet speed - Instances with floating IP

Hi Mohit,

The tenant networks use an MTU of 8950. The floating network uses and MTU
of 9000.

neutron net-show 4305e3d5-b083-4f33-a2a0-1dfccf1238b6
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| availability_zone_hints   |  |
| availability_zones| nova |
| created_at| 2016-10-10T15:35:44  |
| description   |  |
| id| 4305e3d5-b083-4f33-a2a0-1dfccf1238b6 |
| ipv4_address_scope|  |
| ipv6_address_scope|  |
| mtu   | 8950 |
| name  | systems-net  |
| port_security_enabled | True |
| provider:network_type | vxlan|
| provider:physical_network |  |
| provider:segmentation_id  | 100  |
| router:external   | False|
| shared| False|
| status| ACTIVE   |
| subnets   | d1265c93-d47c-4902-89a6-8ad3172fb946 |
| tags  |  |
| tenant_id | c7c31d0bd344476a8c8ca39a19e1be15 |
| updated_at| 2016-10-10T15:35:44  |
+---+--+

neutron net-show 4c7544f3-c06b-48cf-babc-015d29dd7e62
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| availability_zone_hints   |  |
| availability_zones| nova |
| created_at| 2016-09-23T11:07:56  |
| description   |  |
| id| 4c7544f3-c06b-48cf-babc-015d29dd7e62 |
| ipv4_address_scope|  |
| ipv6_address_scope|  |
| is_default| False|
| mtu   | 9000 |
| name  | admin_floating_net   |
| port_security_enabled | True |
| provider:network_type | flat |
| provider:physical_network | physnet1 |
| provider:segmentation_id  |  |
| router:external   | True |
| shared| False|
| status| ACTIVE   |
| subnets   | c70635c4-9bf7-4e4d-9353-c619e196cdf0 |
| tags  |  |
| tenant_id | a2b6f1b348e54229b3244183d6aa41a5 |
| updated_at| 2016-09-23T11:07:56  |
+---+--+

Thank You,

___

John Petrini
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [novaclient] novaclient and httpretty - unable to record


On 04/04/2017 04:43 AM, George Shuklin wrote:

Sorry for asking in dev maillist, but it really looks like dev issue.

I'm writing  application which relies on novaclient, glanceclient, etc.

It's almost done, but I thought about adding end to end tests by
recording and actual requests and replies to openstack. I used httpretty
library for this. Unfortunately, it ignores all requests and unable to
record them.


You might have better luck with either requests_mock or betamax. There 
is a betamax test fixture in the keystoneauth1 that you can use if you 
want to go the betamax route:


http://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/tests/unit/test_betamax_fixture.py

If you'd rather go requests_mock (which is what I've been using to great 
pleasure) you can look in the shade test suite for some examples - 
although it's a big test suite so things get complex:


http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/tests/unit/base.py#n398

http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/tests/unit/test_security_groups.py#n380


Does someone knew anything about httpretty and novaclient interaction?
(I think keystoneauth1 and other openstack clients behaves the same way?).


I unfortunately don't know about httpretty and keystoneauth. I don't 
know of any specific reason it shouldn't work, but as I use the other 
things I have never explored it.



Code example:

import httpretty
from keystoneauth1 import identity
from keystoneauth1 import session
import novaclient.client
auth_data = {'tenant_name':'any', 'username': 'any', 'password': 'any',
'auth_url': 'https://google.com/does-not-matter/'}
with httpretty.HTTPretty.record('test.json'):
auth = identity.v2.Password(**auth_data)
s = session.Session(auth=auth)
cl = novaclient.client.Client('2', session=s)
z = cl.flavors.find(name='SSD.30')


Thanks!


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



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

[openstack-dev] [neutron] [classifier] CCF Meeting

2017-04-04 Thread Duarte Cardoso, Igor

Hi all,

Reminding that the Common Classification Framework meeting is today in about an 
hour @ #openstack-meeting.

Agenda:
https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Discussion_Topic_4_April_2017

Best regards,
Igor.

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

[openstack-dev] [election][tc] flaper87's candidacy to serve as a TC member

2017-04-04 Thread Flavio Percoco


(m-l copy of my candidacy on https://review.openstack.org/453156 )

I'm announcing my candidacy for a position on the OpenStack Technical Committee.
For those of you who don't know me yet, I'm Flavio Percoco. I'm currently
employed by Red Hat and I've been in the Technical Committee for the last 2
years.

I truly believe my work as part of the Technical Committee is very much a
community work as it's a technical work. I'm personally interested in finding
ways to evolve our community while still empowering people to do technical work,
improve themselves, and be amazing. My work as a member of the Technical
Committee has always followed this belief and so do the following points that I
believe we should keep working on:

#1 Keep getting rid of any tribal knowledge there could exists

Our community has had a significant growth over the last years and as people
come and go I believe it's extremely important to document our culture, our
beliefs, and to clarify our vision.

More projects are being (or going to be) added to the big tent in the future.
This set of projects are diverse in technology, scope and goals. My experience
as a mentor throughout the process for on-boarding new projects has been that
there are still uncertainties in our community, especially for folks that are
not as familiar with it. What does it mean to be part of the community? What am
I expected to do and/or behave like? What is good/bad CI? Can I use other
languages? are just examples of questions that come up. Some of these have be
answered, others still need some work.

#2 Cross-Community engagements and interactions

I'd like to dedicate more time on building bridges with other communities like
Go's, Cloud Native Computing Foundation, etc. I believe there's a lot we can all
learn from each other and the more we work together, the more we'll improve our
technologies/communities and the more our users will benefit.

As part of my tasks during the 2016-2017 period, I worked on a reference
document which describes the process to add new languages in the community. This
means that, given a good use-case, it's possible to add/create projects that use
other languages that are not adopted by the community yet. This work started of
as a request from the Swift team and evolved into how can we enable the
community to experiment and explore new fields outside of "what we know". I find
this exploration and experimentation critical for OpenStack's growth as a
community and as a technology.

I'd like to extend what has been done with the new language additions reference
document to other communities and technologies. To be more specific I'd like to
help building bridges and making sure the right processes for interacting with
other communities like CNCF exist and that such interactions are happening.

#3 Containing the Big Tent bubble

Several new teams have been added to the big tent, and I believe this is
great. I also believe that some teams are not meant to exist forever. Some
teams play a role for a limited amount of time and this is good too.

As part of evolving our community and making sure we communicate the right
message, I believe we should do constant checks on our team structure, how we
can re-organize these teams (if needed) and how we can keep the list clean.

I'm personally more interested in the re-organization part of the process. How
we can encourage collaboration on some areas that happen to have more overlap
without affecting negatively the mission of the teams involved.

#4 Communicate more

I am part of the communications working group in the TC. We focus on
communicating as much as possible the things that happen in the technical
committee reviews and meetings.

This effort slowed down quite a bit in the last couple of months but I'd like to
pick it up again and build a new team of writers to make sure all the
discussions happening at the governance level will reach as many community
members as possible.

I believe in this community, I believe in this technology and I believe we've
done a great job moving the community up despite all the downs we've had. I
believe there's still a lot we need (and can) do and that there's a lot of
excitement to have in this community.

Thanks for reading thus far and for considering me as valid candidate. If
elected, I will keep working on my current tasks and the ones I just mentioned
as part of this candidacy. I hope you'll help me improve while we all work on
improving OpenStack. Regardless of the result, it has been an honor to serve
y'all thus far.

Rock on!
Flavio

--
@flaper87
Flavio Percoco


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

[Openstack] Not getting private network field in networks tab

2017-04-04 Thread pratik dave

Hello Everyone,

While deploying OpenStack environment we are getting error for network
verification.

We are getting error verification failed. And expected VLAN not received on
ens192.

Also we observed we are not getting private network field as we have seen
in many blogs and videos. We are getting option to enter public, management
and storage network details.

Please find attached screenshot for your reference and request your inputs
to resolve the issue.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [openstack-ansible] Adding a scenario for shade's functional tests


Hey all!

I woke up early this morning and found myself thinking "I clearly don't 
have enough work on my plate, why don't I add some more?"


I'd love to make a gate job that:
- Deploys a cloud with openstack-ansible
- Runs shade's functional tests against that cloud

Which makes me think it just needs to be an additional scenario perhaps?

As I started to poke, I need to figure out the best way to accomplish 
something. Namely, shade's functional tests expect a clouds.yaml that 
defines two entires - one admin and one non-admin.


OSA already creates a clouds.yaml with admin creds, so that's done. And 
there is already tempest setup that creates a demo user, so that's done 
too. Here's where I could use some advice:


- What's the best way to plumb through an option to also write an entry 
to clouds.yaml for the demo user? I'm thinking a boolean in 
openstack-ansible-openstack_openrc like 
"openrc_clouds_yml_add_demo_user" that can be wrapped around a second 
entry in clouds.yaml.j2?


- Can we create the demo user and not run tempest? It's in the 
os_tempest role at the moment. Should I split out the user creation bits 
into a "test_setup" role that tempest depends on - and then also make a 
shade_test role that also depends on the test_setup role?


- If we do a test_setup role, should that maybe just write a whole 
additional clouds.yaml out that has the admin and the demo user so that 
we don't have to put conditionals in places that also get used for prod 
deploys?


I think that's about all the questions I have for now ...

Thanks!
Monty

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

Re: [Openstack] Slow internet speed - Instances with floating IP

2017-04-04 Thread Mohit .

Hello John,


Can you update (increase) the MTU parameter set under "neutron net-show
{your-net-name}"


Thanks
Mohit.


On Tue, Apr 4, 2017 at 4:01 PM, John Petrini  wrote:

> Adding the OpenStack list in hopes this might get some attention there.
>
> Thanks All,
>
> ___
>
> John Petrini
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [nova] Nova API sub-team meeting

2017-04-04 Thread Ghanshyam Mann

Hi All,



We have weekly Nova API meeting tomorrow. The meeting is being held
Wednesday UTC1300 and irc channel is #openstack-meeting-4.



The proposed agenda and meeting details are here:



https://wiki.openstack.org/wiki/Meetings/NovaAPI



Please feel free to add items to the agenda.


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

Re: [OpenStack-Infra] [nodepool] unable to get a floating IP

2017-04-04 Thread Alex Burmashev


Thanks for help!

Actually after all it was pretty obvious: network is checked by netaddr 
lib, so if your private network is reported as public by netaddr ( while 
physically being private ) the whole setup will think it's public.


I changed my private network from 8.0.0.0/24 to 10.0.0.0/24 and 
everything is OK now.



03.04.2017 19:45, Jeremy Stanley пишет:

On 2017-04-03 19:32:42 +0200 (+0200), Alex Burmashev wrote:
[...]

Now i have to figure out why private IP is considered as public...

[...]

There are a number of potential reasons, and the logic behind that
decision is encapsulated in the shade.meta.get_server_external_v4()
function:

http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/meta.py?h=1.19.0#n113




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

Re: [openstack-dev] [all] Switching gate testing to use Ubuntu Cloud Archive

2017-04-04 Thread Sean Dague

This is definitely a trade off, I know the last time we tried UCA we had
such a high failure rate we had to revert. But, that was a much younger
libvirt that was only just starting to get heavy testing in OpenStack.
So it feels like it's worth a shot. It will at least be interesting to
see if it makes things better.

The libvirt bump will bring in libvirtd and live migration postcopy for
testability on the Nova side, both of which would be good things.

-Sean

On 04/03/2017 07:06 PM, Clark Boylan wrote:
> Hello,
> 
> One of the major sets of issues currently affecting gate testing is
> Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> and they happen frequently [0][1][2]. These issues appear to only affect
> Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> #openstack-nova it is clear that Libvirt isn't interested in debugging
> such an old version of Libvirt (1.3.1). And while it isn't entirely
> clear to me which exact version would be acceptable to them the Ubuntu
> Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).
> 
> I have pushed a change to devstack [3] to enable using UCA which pulls
> in new Libvirt and mostly seems to work. I think we should consider
> switching to UCA as this may fix our Libvirt problems and if it doesn't,
> we will be closer to a version of Libvirt that upstream should be
> willing to fix.
> 
> This isn't the most straightfoward switch as UCA has a different repo
> for each OpenStack release. libvirt-python is sensitve to the underlying
> library changing; it is backward compatible but libvirt-python built
> against older libvirt won't work against new libvirt. The result is a
> libvirt-python wheel built on our wheel mirror does not work with UCA.
> On the positive side both the OpenStack puppet modules and OpenStack
> Ansible are using UCA with their deployment tooling so this should get
> us closer to what people are using in the wild.
> 
> After some thought I think my preferred method of rolling this out would
> be to blacklist libvirt-python from our wheel mirror building entirely
> and force installs to happen from source so that we are base Xenial and
> $UCA_version independent (local testing of these builds show it only
> takes a few seconds). Then have specific jobs (like devstack) explicitly
> opt into the UCA repo appropriate for them (if any). This last bit is
> from feedback from OpenStack Ansible that having the base images be
> fairly clean is desirable, but it would also be hard to know which
> version of UCA is appropriate for our Xenial images (this likely differs
> based on the job).
> 
> Now its entirely possible that newer Libvirt will be worse than current
> (old) Libvirt; however, being closer to upstream should make getting
> fixes easier. Would be great if those with a better understanding of
> Libvirt could chime in on this if I am completely wrong here.
> 
> Finally it is worth noting that we will get newer packages of other
> software as well, most notably openvswitch will be version 2.6.1 instead
> of 2.5.0.
> 
> Any other thoughts or ideas?
> 
> [0] http://status.openstack.org/elastic-recheck/#1646779
> [1] http://status.openstack.org/elastic-recheck/#1643911
> [2] http://status.openstack.org/elastic-recheck/#1638982
> [3] https://review.openstack.org/451492
> 
> Thank you,
> Clark
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [OpenStack-Dev][Cinder][Driver][Nimble] - Need Point of contact

2017-04-04 Thread Duncan Thomas

Their CI contact from the wiki (
https://wiki.openstack.org/wiki/ThirdPartySystems/Nimble_Storage_CI )
is openstack...@nimblestorage.com - that's probably a good start.

On 4 April 2017 at 11:58, nidhi.h...@wipro.com  wrote:
> Hi all,
>
>
> I was working on few bugs related to Nimble cinder driver.
>
> I needed some clarification.
>
>
> May i know right point of contact for this?
>
>
> Who from nimble should be contacted for their cinder
>
> driver bugs?
>
>
> Thanks
>
> Nidhi
>
>
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments. WARNING: Computer viruses can be transmitted
> via email. The recipient should check this email and any attachments for the
> presence of viruses. The company accepts no liability for any damage caused
> by any virus transmitted by this email. www.wipro.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Duncan Thomas

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

[openstack-dev] [OpenStack-Dev][Cinder][Driver][Nimble] - Need Point of contact

2017-04-04 Thread nidhi.h...@wipro.com

Hi all,


I was working on few bugs related to Nimble cinder driver.

I needed some clarification.


May i know right point of contact for this?


Who from nimble should be contacted for their cinder

driver bugs?


Thanks

Nidhi



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] Slow internet speed - Instances with floating IP

Adding the OpenStack list in hopes this might get some attention there.

Thanks All,

___

John Petrini
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] Slow internet speed - Instances with floating IP