Re: [openstack-dev] [all] what do you work on upstream of OpenStack?

[Clint Byrum]

Excerpts from Doug Hellmann's message of 2016-06-23 08:37:04 -0400:
> Excerpts from Doug Hellmann's message of 2016-06-13 15:11:17 -0400:
> > I'm trying to pull together some information about contributions
> > that OpenStack community members have made *upstream* of OpenStack,
> > via code, docs, bug reports, or anything else to dependencies that
> > we have.
> > 
> > If you've made a contribution of that sort, I would appreciate a
> > quick note.  Please reply off-list, there's no need to spam everyone,
> > and I'll post the summary if folks want to see it.
> > 
> > Thanks,
> > Doug
> > 
> 
> I've summarized the results of all of your responses (on and off
> list) on a blog post this morning [1]. I removed individual names
> because I was concentrating on the community as a whole, rather than
> individual contributions.
> 
> I'm sure there are projects not listed, either because I missed
> something in my summary or because someone didn't reply. Please feel
> free to leave a comment on the post with references to other projects.
> It's not necessary to link to specific commits or bugs or anything like
> that, unless there's something you would especially like to highlight.
> 
> Thank you for your input into the survey. I'm impressed with the
> breadth of the results. I'm very happy to know that our community,
> which so often seems to be focused on building new projects, also
> contributes to existing projects that we all rely on.
> 
> [1] 
> https://doughellmann.com/blog/2016/06/23/openstack-contributions-to-other-open-source-projects/

That is pretty cool.

I forgot to reply to your original request, but I did a lot of python3
porting on the pysaml2 project in support of Keystone's python3 port.

https://github.com/rohe/pysaml2/commits?author=SpamapS

__
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-ansible] Change of default database collation

[Jimmy McCrory]

Hi all,

OpenStack-Ansible has been configuring the default database collation as
'utf8_unicode_ci'.
We've recently run into an issue with new deployments during cinder
database migrations where a foreign key column had different a collation
between the parent and child table[1].

That's since been fixed, and we're now looking at changing the default
collation to match the default of MySQL/MariaDB's utf8 character set to
avoid the possibility of this same discrepancy with new deployments[2].

The question then comes to how to best handle upgrades from Mitaka to
Newton.
Any input for the current proposal[3] from anyone that may have experience
with any project's database migration scripts, or MySQL-based databases in
general, would be appreciated.

Also,
Have any of the other deployment projects been effected by this?
Are there any in-progress efforts to help further enforce a standard
character set and collation through DB migration scripts?

Thanks

[1] https://bugs.launchpad.net/cinder/+bug/1594195
[2] https://review.openstack.org/#/c/331786/
[3] https://review.openstack.org/#/c/333733/
__
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] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[Preston L. Bannister]

On 06/23/2016  Daniel Berrange wrote (lost attribution in thread):

> Our long term goal is that 100% of all network storage will be connected
>
to directly by QEMU. We already have the ability to partially do this with
> iSCSI, but it is lacking support for multipath. As & when that gap is
> addressed though, we'll stop using the host OS for any iSCSI stuff.
>
> So if you're requiring access to host iSCSI volumes, it'll work in the
> short-medium term, but in the medium-long term we're not going to use
> that so plan accordingly.
>

On 06/23/2016 10:09 AM, Walter A. Boring IV wrote:

> We regularly fix issues with iSCSI attaches in the release cycles of
> OpenStack,
> because it's all done in python using existing linux packages.  How often
> are QEMU
> releases done and upgraded on customer deployments vs. python packages
> (os-brick)?
>
> I don't see a compelling reason for re-implementing the wheel,
> and it seems like a major step backwards.
>

On Thu, Jun 23, 2016 at 12:07:43PM -0600, Chris Friesen wrote:

> This is an interesting point.
>
> Unless there's a significant performance benefit to connecting
> directly from qemu, it seems to me that we would want to leverage
> the existing work done by the kernel and other "standard" iSCSI
> initators.
>

On Thu, Jun 23, 2016 at 1:28 PM, Sean McGinnis 
wrote:
>
> I'm curious to find out this as well. Is this for a performance gain? If
> so, do we have any metrics showing that gain is significant enough to
> warrant making a change like this?
>
> The host OS is still going to be involved. AFAIK, this just cuts out the
> software iSCSI initiator from the picture. So we would be moving from a
> piece of software dedicated to one specific functionality, to a
> different piece of software that's main reason for existence is nothing
> to do with IO path management.
>
> I'm not saying I'm completely opposed to this. If there is a reason for
> doing it then it could be worth it. But so far I haven't seen anything
> explaining why this would be better than what we have today.



First, I have not taken any measurements, so please ignore everything I
say. :)

Very generally, if you take out unnecessary layers, you can often improve
performance and reliability. Not in every case, but often.

Volume connections routed through the Linux kernel *might* lose performance
from the extra layer (measures are needed), and have to be managed. The
last could be easily underestimated. Nova has to manage Linux's knowledge
of volume connections. In the strictest sense the nova-compute host Linux
does not *need* to know about volumes attached to Nova instances. The
hairiest part of the the problem: What to do when the nova-compute Linux
table of attached volumes gets out of sync? My guess is there are error
cases not-yet well-handled in Nova in this area. My guess is Nova could be
somewhat simpler if all volumes were directly attached to QEMU.

(Bit cheating when mentioning the out-of-sync case, as got bit a couple
times in testing. It happens.)

But ... as mentioned earlier, suspect you cannot get to 100% direct to QEMU
if there is specialized hardware that has to tie into the nova-compute
Linux. Seems unlikely you would get consensus, as this impacts major
vendors. Which means you have to keep managing the host map of volumes.
Which means you cannot simplify Nova. (If someone knows how to use the
specialized hardware, with less footprint in host Linux, this answer could
change.)

Where this will land, I do not know. Do not know the performance measures.

Can OpenStack allow for specialized hardware, without routing through host
Linux? (Probably not, but would be happy to be wrong.)

And again, as an outsider, I could be wrong about everything. :)
__
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] What's Up, Doc? 24 June 2016

[Lana Brindley]

Hi everyone,

We're starting to see a real rush of projects publishing their Install Guides 
this week, which is really exciting! We're also working on getting the index 
page on docs.openstack.org up and running, so we should have that ready to go 
up by the time I'm writing this newsletter next week. Well done to all the docs 
people, and the cross-project liaisons who have been working hard to make this 
happen. It's great to see it all start to come together :)

== Progress towards Newton ==

103 days to go!

Bugs closed so far: 207

Newton deliverables: 
https://wiki.openstack.org/wiki/Documentation/NewtonDeliverables
Feel free to add more detail and cross things off as they are achieved 
throughout the release.

Also, just a note that the CFP for Barcelona is open now, until 13 July. If you 
want to brainstorm some documentation-related ideas, please get in touch!

== Speciality Team Reports ==

'''HA Guide: Bogdan Dobrelya'''
No report this week.

'''Install Guide: Lana Brindley'''
Swift, Manila patches in progress. Petr is working on the index page: 
https://review.openstack.org/331704 Feedback requested! Next meeting: 5 July 
0600 UTC

'''Networking Guide: Edgar Magana'''
No report this week.

'''Security Guide: Nathaniel Dillon'''
No report this week.

'''User Guides: Joseph Robinson'''
No report this week.

'''Ops Guide: Shilla Saebi'''
Team is currently reviewing enterprise ops documentation to incorporate into 
the Ops Guide. 
Ops tasks are documented here: https://etherpad.openstack.org/p/ops-arch-tasks
OpenStack ops guide reorg in progress & documented here: 
https://etherpad.openstack.org/p/ops-guide-reorg
Members of the ops guide team are joining ops meetings to find volunteers

'''API Guide: Anne Gentle'''
Progress ongoing on navigation for multiple OpenStack APIs: 
https://review.openstack.org/#/c/329508
Working on lists of project's API references that don't use RST+YAML framework: 
http://lists.openstack.org/pipermail/openstack-docs/2016-June/008775.html

'''Config/CLI Ref: Tomoyuki Kato'''
Got some comments for improvements from Brian Rosmaita, Hemanth Makkapati and 
Richard Jones. Thank you!
Closed many bugs for Configuration Reference.
Updated openstack, glance, neutron-sanity-check, and trove-manage CLI reference.

'''Training labs: Pranav Salunke, Roger Luethi'''
Webpage is looking good and also all the URL's point to the right link 
http://docs.openstack.org/training_labs/
Trying to finalize PXE support https://review.openstack.org/#/c/305991/

'''Training Guides: Matjaz Pancur'''
Italian translation of the Upstream training
Details about running a Lego session (https://review.openstack.org/#/c/325020/, 
https://review.openstack.org/#/c/330819/)

'''Hypervisor Tuning Guide: Blair Bethwaite
No report this week.

'''UX/UI Guidelines: Michael Tullis, Rodrigo Caballero'''
No report this week.

== Site Stats ==

The top five search terms on the site so far during June: snapshot, cinder, 
nova, security group, quota

== Doc team meeting ==

Next meetings:

The US meeting was held this week, you can read the minutes here: 
https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2016-06-22

Next meetings:
APAC: Wednesday 29 June, 00:30 UTC
US: Wednesday 6 July, 19:00 UTC

Please go ahead and add any agenda items to the meeting page here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#24_June_2016

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



signature.asc
Description: OpenPGP digital 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-dev] [Kuryr] Refactoring into common library and kuryr-libnetwork + Nested_VMs

[Vikas Choudhary]

Hi Team,

As already discussed with some of teammates over irc and internally,
thought of bringing discussionto ml for more opinions:

My idea on repo structure is something similar to this:

kuryr
└── controller
│   ├── api (running on controller node(cluster master or openstack
controller node), talking to other services(neutron))
│   │
│   ├── kubernetes-controller
│   │   │
│   │   └── watcher (for network related services making api calls)
│   │
│   │___any_other_coe_controller_capable_of_watching_events
│
│
│
│___driver
 │common (traffic tagging utilities and binding)
 │
 │kubernetes(cni)
 │
 │libnetwork(network and ipam driver)(for network related services
making api calls)
 │
 │ any_other_driver(calling api for nw related services if watcher
not supported)


Thoughts?


-Vikas




-- Forwarded message --
From: Vikas Choudhary 
Date: Thu, Jun 23, 2016 at 2:54 PM
Subject: Re: Kuryr Refactoring into common library and kuryr-libnetwork +
Nested_VMs
To: Antoni Segura Puimedon 


@Toni, Can you please explain a bit on how the roles regarding
 vlan/segmentation id allocation, tagging ang untagging containers' traffic
are divided among entities you mentioned.

In my understanding, in k8s case, API_watcher has resource translators and
these will be talking to neutron for port creation and ip allocation. Then
why for k8s case, neutron talking utilities are present in common lib. Or
in other words, which neutron apis will be used from common lib?

-Vikas

On Thu, Jun 23, 2016 at 2:22 PM, Antoni Segura Puimedon 
wrote:

>
>
> On Thu, Jun 23, 2016 at 7:28 AM, Irena Berezovsky 
> wrote:
>
>> Hi guys,
>> Just minor suggestion from my side. Please link all the refactoring
>> patches to the same launchpad bp/topic so it will be easy to trace the
>> relevant work.
>>
>> Vikas, Gal,let me know if you need so help.
>>
>> BR,
>> Irena
>>
>> On Thu, Jun 23, 2016 at 7:58 AM, Vikas Choudhary <
>> choudharyvika...@gmail.com> wrote:
>>
>>> Hi Gal,
>>>
>>> Greeting of the day!!!
>>>
>>> I have trying reaching you over irc unsuccessfully since last two days.
>>> So finally thought of dropping an email.
>>>
>>> Since you have taken up the task of moving code to kuryr-libnetwork and
>>> I also have started working on refactoring/changes for nested-vm, seems
>>> there is some overlap. Therefore wanted to coordinate following two tasks:
>>>
>>> 1. Writing a common(COE agnostic) library , "Kuryr_api" or some other
>>> similar name, responsible for handling requests from kuryr-libnetwork and
>>> making requests to other OpenStack services.
>>>
>>> 2. Modify current kuryr controllers.py to make calls to common
>>> "Kuryr_api" and not to OpenStack services directly.
>>>
>>
> My idea was to leave:
>
> https://github.com/openstack/kuryr
>
> with a single package
>
> kuryr
> └── lib
> ├── binding
> │   └── __init__.py
> └── __init__.py
>
>
>  that would contain just a library with the common  bits like the
> controller, the binding, and utils to talk to neutron.
>
> Then, the other repos like openstack/kuryr-libnetwork and
> openstack/kuryr-kubernetes would have a package like the following:
>
> kuryr
> └── kubernetes
> ├── cni
> │   └── __init__.py
> ├── __init__.py
> └── watcher
> └── __init__.py
>
> This way, all would be inside the namespace Python package kuryr (read the
> first and second answers to
> http://stackoverflow.com/questions/1675734/how-do-i-create-a-namespace-package-in-python
>
>
>
>
>>> Shall i start working on both of these or you are already working on
>>> either one? Please suggest.
>>>
>>>
>>> -Vikas
>>>
>>>
>>>
>>
>
__
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] [nova][pci-passthrough] definitely specify VFIO driver as the host PCI driver for passthrough

[Chen Fan]

hi all,
 in openstack, we can use the pci passthrough feature now, refer to
 https://wiki.openstack.org/wiki/Pci_passthrough
 but we can't definitely specify the host pci driver is LEGACY_KVM 
or newer VFIO,
 new VFIO driver is more safer, and higher-performance user-space 
driver
 than legacy kvm driver (pci-stub), the benefit relative to kvm 
assignment driver

 could refer to http://lwn.net/Articles/474088/.
 In additional, VFIO driver provides the GPU passthrough as primary 
card support.
 I think it is more useful for further GPU passthrough support in 
openstack.


 Openstack relies on the libvirt nodedev device configuration to do 
pci passthrough,
 with managed mode, the configured device is automatically detached 
and re-attached
 with KVM or VFIO driver that depended on the host driver modules 
configuration,
 so now we can't specify the driver in openstack to VFIO mode, I 
think we should need
 to add this feature support in openstack to get pci passhthrough 
more scalability.


 a simply idea is to add a option in nova.conf HOST_PCI_MODEL = 
VFIO /KVM to specify

 the pci passthrough device driver is using VFIO driver.
 any comments are welcome. :)

Thanks,
Chen



--
Sincerely,
Chen Fan


__
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][monasca][requirements] Kafka 1.x for Oslo.Messaging and Monasca

[Tony Breeds]

On Wed, Jun 22, 2016 at 05:34:27AM +, Keen, Joe wrote:
> Davanum,
>   We started work on getting Monasca into the global requirements with two
> reviews [1] [2] that add gate jobs and check requirements jobs for the
> Monasca repositories.  Some repositories are being adapted to use versions
> of libraries that OpenStack currently accepts [3] and we¹re looking at the
> libraries we use that are not currently part of OpenStack and seeing if
> they¹re worth trying to add to the global requirements.  We¹re hoping to
> be able to start adding the global requirements reviews within a week or
> two.
> 
> We definitely want to talk with the oslo.messaging team and explain the
> ways we use Kafka and what effects the move to the 1.x versions of the
> library has on us.  I¹ve attempted to contact the oslo.messaging team in
> the oslo IRC channel to see if we can talk about this at a weekly meeting
> but I wasn¹t able to connect with anyone.  Would you prefer that
> conversation happen on the mailing list here or could we add that topic to
> the next weekly meeting?
> 
> [1] https://review.openstack.org/#/c/316293/
> [2] https://review.openstack.org/#/c/323567/

These 2 are merged.

> [3] https://review.openstack.org/#/c/323598/

Taking a tangent here:

In 2014[1] we added a cap to psutil because 2.x wasn't compatible with 1.x
which is fine but 2 years latere we have 4.3.0 and because of the cap I'm
guessing we've done very little to work towards 4.3.0

I've added an item for the requirements team to look at what's involved in
raising the minimum for psutil, but:
Requirement: psutil<2.0.0,>=1.1.1 (used by 41 projects)
it wont happen soon.

Is psutil the last of the "old" libraries you need to deal with?

Getting back to the topic of kafka, what are the pain points involved in
working with the 2.x API?  Clearly we're going to need to get monasca and
oslo.messgaing on a compatible page RSN or we'll end up delaying things until
Ocata :(

Yours Tony.

[1] https://review.openstack.org/#/c/81373/


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] [keystone] [stable/mitaka] Error: Discovering versions from the identity service failed when creating the password plugin....

[Tony Breeds]

On Tue, Jun 21, 2016 at 10:27:28AM +0530, mohammad shahid wrote:
> Hi,
> 
> I am getting below error while starting openstack devstack with
> stable/mitaka release. can someone look at this problem ?

so I *think* you're trying to deploy stable/mitaka with the master version of
devstack.

Please make sure that you're running the stable/mitaka version of devstack.

git clone https://git.openstack.org/openstack-dev/devstack
cd devstack
git checkout -b stable/mitaka -t origin/stable/mitaka

If that doesn't work please inlude the devstack SHA you are using along with
the trace and config.

Tony.


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-dev] [cinder]restore method while ceph backup backend is used

[刘庆]

Hi all,
This is Liu Qing, new to this community. I have a question about the ceph
backup backend.
>From the cinder/backup/manager.py, the restore process is done by attach
the original device(restore dest) to the cinder service host. And in the
ceph driver the full_restore will discard the additional space if restore
dest(by volume extend) is larger than the backup. There are two ways to
discard the unused space, by ceph discard or write zeroes to the unused
space. As the dest is attached to the host, the dest is not recognized as
an ceph volume. Ceph discard will never be used in volume restore, right?
But ceph discard is much more efficient than writing zeroes to the unused
space. Is there any plan to use the ceph discard way? Thanks.

Liu Qing
__
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] Packaging Virtualenvs

[John Dewey]

Not only is it interesting, it’s awesome :)

John


On June 23, 2016 at 5:53:59 PM, Silence Dogood (m...@nycresistor.com) wrote:

I'll check out giftwrap.  never heard of it.  But interesting.

On Thu, Jun 23, 2016 at 7:50 PM, Xav Paice  wrote:

> Can I suggest that using the tool https://github.com/openstack/giftwrap
> might make live a bunch easier?
>
> I went down a similar path with building Debs in a venv using
> dh_virtualenv, with some good success when I sorted the shebang. I later
> found that the debs produced by Giftwrap are not only very easy to build
> and test, but also take a bunch less effort to maintain and create new
> packages for new things.  To run the resulting code, I just symlink the
> ${venv}/bin/$binary to /usr/local/bin and run the thing using very
> similar init scripts to the ones supplied by the distro packages.  Works
> like a charm, because the shebang in the binary points at the venv, not
> the system python.
>
> I do, however, package the init scripts, sample configs, etc in a
> separate .deb, which is really very quick and easy and allows me to
> control the bits I want to, and let Giftwrap take care of the OpenStack
> code repos.
>
>
> On Thu, 2016-06-23 at 23:40 +, Matt Joyce wrote:
> > I want the script to dynamically instantiate the venv is call activate
> > this at execution time and deactivate when done.
> >
> >
> >
> > On June 23, 2016 5:12:07 PM EDT, Doug Hellmann 
> > wrote:
> > Excerpts from Silence Dogood's message of 2016-06-23 15:45:34
> -0400:
> >  I know from conversations that a few folks package
> their python apps as
> >  distributable virtualenvs.   spotify created
> dh-virtualenv for this.  you
> >  can do it pretty simply by hand.
> >
> >  I built a toolchain for building rpms as distributable
> virtualenvs and that
> >  works really well.
> >
> >  What I'd like to do is make it so that every app that's
> built as a
> >  virtualenv gets setup to automatically execute at call
> time in their
> >  virtualenv.
> >
> >  I see two options:
> >
> >  1)  Dynamically generate a wrapper script during build
> and put it in the
> >  RPM.  Call the wrapper.
> >
> >  2)  Created a dependency global module ( as an rpm )
> set it as a
> >  dependency.  And basically it'd be an autoexecuting
> import that
> >
> > instantiates the virtualenv.  it would probably know all
> it needs to
> >  because I am building all my packages to an internal
> standard.  Then when
> >  building the APP rpm all I need to do is inject an
> import into the import
> >  chain if it's being built as a virtualenv.  Then I have
> what are
> >  effectively statically compiled python apps.
> >
> >  I like 2.  But 1 isn't very bad.  Both are a little
> hokey.
> >
> >  Was curious if folks might have a preference, or a
> better idea.
> >
> >  Thanks.
> >
> >  Matt
> >
> > I'm not sure what you mean by a "wrapper script".  If you run the
> > Python console script from within the virtualenv you've packaged,
> > you shouldn't need to do anything to "activate" that environment
> > separately because it should have the correct shebang line.
> >
> > Are you seeing different behavior?
> >
> > Doug
> >
> >
> > __
> >
> > 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
>
>
>
> ___
> 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
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [requirements][packaging] Normalizing requirements file

[Tony Breeds]

On Wed, Jun 22, 2016 at 03:23:43PM +1000, Tony Breeds wrote:
> On Wed, Jun 22, 2016 at 06:45:31AM +0200, Haïkel wrote:
> > Hi,
> > 
> > as a packager, I spend a lot of time to scrutinize the requirements
> > repo, and I find it easier to read if specifiers are ordered.
> > So in a quick glance, you can check which is the min version required
> > and max one without trying to search them among other specifiers.
> > I scripted a basic linter to do that (which also normalize comments to
> > PEP8 standards)
> > 
> > Initial review is here:
> > https://review.openstack.org/#/c/332623/
> > 
> > script is available here;
> > https://gist.github.com/hguemar/7a17bf93f6c8bd8ae5ec34bf9ab311a1
> > 
> > Your thoughts?
> 
> I'm fine with doign something like this.  I wrote [1] some time ago but didn't
> push on it as I needed to verify that this wouldn't create a "storm" of
> pointless updates that just reorder things in every projects 
> *requirements.txt.

I think we need to pause on these 'normalizing' changes in g-r.  They're
genertaing whitspace only reviews in many, (possibly all) projects that have
managed requirements.

We need to do more testing and possibly make the bot smarter befoer we look at
this again.


Yours Tony.


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-dev] [kolla][ironic] My thoughts on Kolla + BiFrost integration

[Steven Dake (stdake)]

Hey folks,

I created the following sequence diagram to show my thinking on Ironic 
integration.  I recognize some internals of the recently merged bifrost changes 
are not represented in this diagram.  I would like to see a bootstrap action do 
all of the necessary things to bring up BiFrost in a container using Sean's WIP 
Kolla patch followed by bare metal minimal OS load followed by Kolla dependency 
software (docker-engine, docker-py, and ntpd) loading and initialization.

This diagram expects ssh keys to be installed on the deployment targets via 
BiFrost.

https://creately.com/diagram/ipt09l352/ROMDJH4QY1Avy1RYhbMUDraaQ4%3D

Thoughts welcome, especially from folks in the Ironic community or Sean who is 
leading this work in Kolla.

Regards,
-steve

__
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] Status of the OpenStack port to Python 3

[Steve Martinelli]

+1 on the idea of running function tests to see the fallout. Right now
python-memcached is labelled as py3 compatible and in keystone our unit
tests pass, but I'm skeptical about its behavior in functional and tempest
tests.
On Jun 23, 2016 1:14 PM, "Sean Dague"  wrote:

So, given that everything in base iaas is over besides Nova, and there
is some python 3 support in Devstack, before Newton is over one could
get a python 3 (except Nova) job running, and start seeing the fallout
of full stack testing. We could even prioritize functional changes in
Nova to get full stack python 3 working (a lot of what is holding Nova
back is actually unit tests that aren't python 3 clean).

That seems like the next logical step, and I think would help add
incentive to full stack testing to show this actually working outside of
just isolated test suites.

On 06/23/2016 12:58 PM, Davanum Srinivas wrote:
> +1 from me as well Doug! ("community to set a goal for Ocata to have
Python
> 3 functional tests running for all projects.")
>
> -- Dims
>
> On Thu, Jun 23, 2016 at 12:11 PM, Doug Hellmann 
wrote:
>> Excerpts from Thomas Goirand's message of 2016-06-22 10:49:01 +0200:
>>> On 06/22/2016 09:18 AM, Victor Stinner wrote:
 Hi,

 Current status: only 3 projects are not ported yet to Python 3:

 * nova (76% done)
 * trove (42%)
 * swift (0%)

https://wiki.openstack.org/wiki/Python3

 Number of projects already ported:

 * 19 Oslo Libraries
 * 4 Development Tools
 * 22 OpenStack Clients
 * 6 OpenStack Libraries (os-brick, taskflow, glance_store, ...)
 * 12 OpenStack services approved by the TC
 * 17 OpenStack services (not approved by the TC)

 Raw total: 80 projects. In fact, 3 remaining projects on 83 is only 4%,
 we are so close! ;-)

 The next steps are to port the 3 remaining projects and work on
 functional and integration tests on Python 3.

 Victor
>>>
>>> Hi Victor,
>>>
>>> Thanks a lot for your efforts on Py3.
>>>
>>> Do you think it looks like possible to have Nova ported to Py3 during
>>> the Newton cycle?
>>>
>>> Cheers,
>>>
>>> Thomas Goirand (zigo)
>>>
>>
>> I'd like for the community to set a goal for Ocata to have Python
>> 3 functional tests running for all projects.
>>
>> As Tony points out, it's a bit late to have this as a priority for
>> Newton, though work can and should continue. But given how close
>> we are to having the initial phase of the port done (thanks Victor!),
>> and how far we are from discussions of priorities for Ocata, it
>> seems very reasonable to set a community-wide goal for our next
>> release cycle.
>>
>> Thoughts?
>>
>> Doug
>>
>>
__
>> 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
__
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] Packaging Virtualenvs

[Silence Dogood]

I'll check out giftwrap.  never heard of it.  But interesting.

On Thu, Jun 23, 2016 at 7:50 PM, Xav Paice  wrote:

> Can I suggest that using the tool https://github.com/openstack/giftwrap
> might make live a bunch easier?
>
> I went down a similar path with building Debs in a venv using
> dh_virtualenv, with some good success when I sorted the shebang. I later
> found that the debs produced by Giftwrap are not only very easy to build
> and test, but also take a bunch less effort to maintain and create new
> packages for new things.  To run the resulting code, I just symlink the
> ${venv}/bin/$binary to /usr/local/bin and run the thing using very
> similar init scripts to the ones supplied by the distro packages.  Works
> like a charm, because the shebang in the binary points at the venv, not
> the system python.
>
> I do, however, package the init scripts, sample configs, etc in a
> separate .deb, which is really very quick and easy and allows me to
> control the bits I want to, and let Giftwrap take care of the OpenStack
> code repos.
>
>
> On Thu, 2016-06-23 at 23:40 +, Matt Joyce wrote:
> > I want the script to dynamically instantiate the venv is call activate
> > this at execution time and deactivate when done.
> >
> >
> >
> > On June 23, 2016 5:12:07 PM EDT, Doug Hellmann 
> > wrote:
> > Excerpts from Silence Dogood's message of 2016-06-23 15:45:34
> -0400:
> >  I know from conversations that a few folks package
> their python apps as
> >  distributable virtualenvs.   spotify created
> dh-virtualenv for this.  you
> >  can do it pretty simply by hand.
> >
> >  I built a toolchain for building rpms as distributable
> virtualenvs and that
> >  works really well.
> >
> >  What I'd like to do is make it so that every app that's
> built as a
> >  virtualenv gets setup to automatically execute at call
> time in their
> >  virtualenv.
> >
> >  I see two options:
> >
> >  1)  Dynamically generate a wrapper script during build
> and put it in the
> >  RPM.  Call the wrapper.
> >
> >  2)  Created a dependency global module ( as an rpm )
> set it as a
> >  dependency.  And basically it'd be an autoexecuting
> import that
> >
> > instantiates the virtualenv.  it would probably know all
> it needs to
> >  because I am building all my packages to an internal
> standard.  Then when
> >  building the APP rpm all I need to do is inject an
> import into the import
> >  chain if it's being built as a virtualenv.  Then I have
> what are
> >  effectively statically compiled python apps.
> >
> >  I like 2.  But 1 isn't very bad.  Both are a little
> hokey.
> >
> >  Was curious if folks might have a preference, or a
> better idea.
> >
> >  Thanks.
> >
> >  Matt
> >
> > I'm not sure what you mean by a "wrapper script".  If you run the
> > Python console script from within the virtualenv you've packaged,
> > you shouldn't need to do anything to "activate" that environment
> > separately because it should have the correct shebang line.
> >
> > Are you seeing different behavior?
> >
> > Doug
> >
> >
> > __
> >
> > 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
>
>
>
> ___
> 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] [ironic] Gate troubleshooting howto

[Jay Faulkner]

I dropped this Friday as an option based on the results. If you're interested 
this will still be happening, but in mid-July.

Thanks,
Jay Faulkner
OSIC


> On Jun 22, 2016, at 12:39 PM, Jay Faulkner  wrote:
> 
> There was a request at the mid-cycle for a presentation on
> troubleshooting Ironic gate failures. I'd be willing to share some of my
> knowledge about this to interested folks.
> 
> I've created a doodle with a few possible times; note that one option is
> this Friday, but the others are in mid-July, as I'll be moving over the
> gap of time; so I can do before or after the move.
> 
> Please vote here: http://doodle.com/poll/44whfnwkkm4vcgn4
> 
> 
> Thanks,
> Jay Faulkner
> OSIC
> 
> 
> 
> __
> 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-operators] Packaging Virtualenvs

[Xav Paice]

Can I suggest that using the tool https://github.com/openstack/giftwrap
might make live a bunch easier?

I went down a similar path with building Debs in a venv using
dh_virtualenv, with some good success when I sorted the shebang. I later
found that the debs produced by Giftwrap are not only very easy to build
and test, but also take a bunch less effort to maintain and create new
packages for new things.  To run the resulting code, I just symlink the
${venv}/bin/$binary to /usr/local/bin and run the thing using very
similar init scripts to the ones supplied by the distro packages.  Works
like a charm, because the shebang in the binary points at the venv, not
the system python.

I do, however, package the init scripts, sample configs, etc in a
separate .deb, which is really very quick and easy and allows me to
control the bits I want to, and let Giftwrap take care of the OpenStack
code repos.


On Thu, 2016-06-23 at 23:40 +, Matt Joyce wrote:
> I want the script to dynamically instantiate the venv is call activate
> this at execution time and deactivate when done.
> 
> 
> 
> On June 23, 2016 5:12:07 PM EDT, Doug Hellmann 
> wrote:
> Excerpts from Silence Dogood's message of 2016-06-23 15:45:34 -0400:
>  I know from conversations that a few folks package their 
> python apps as
>  distributable virtualenvs.   spotify created dh-virtualenv 
> for this.  you
>  can do it pretty simply by hand.
>  
>  I built a toolchain for building rpms as distributable 
> virtualenvs and that
>  works really well.
>  
>  What I'd like to do is make it so that every app that's 
> built as a
>  virtualenv gets setup to automatically execute at call time 
> in their
>  virtualenv.
>  
>  I see two options:
>  
>  1)  Dynamically generate a wrapper script during build and 
> put it in the
>  RPM.  Call the wrapper.
>  
>  2)  Created a dependency global module ( as an rpm ) set it 
> as a
>  dependency.  And basically it'd be an autoexecuting import 
> that
> 
> instantiates the virtualenv.  it would probably know all it 
> needs to
>  because I am building all my packages to an internal 
> standard.  Then when
>  building the APP rpm all I need to do is inject an import 
> into the import
>  chain if it's being built as a virtualenv.  Then I have what 
> are
>  effectively statically compiled python apps.
>  
>  I like 2.  But 1 isn't very bad.  Both are a little hokey.
>  
>  Was curious if folks might have a preference, or a better 
> idea.
>  
>  Thanks.
>  
>  Matt
> 
> I'm not sure what you mean by a "wrapper script".  If you run the
> Python console script from within the virtualenv you've packaged,
> you shouldn't need to do anything to "activate" that environment
> separately because it should have the correct shebang line.
> 
> Are you seeing different behavior?
> 
> Doug
> 
> 
> __
> 
> 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



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

Re: [Openstack] No valid host was found. There are not enough hosts available. (Was: Create instance fails on creating block device - Block Device Mapping is Invalid)

[Turbo Fredriksson]

On Jun 24, 2016, at 12:32 AM, Turbo Fredriksson wrote:

> And now I'm stuck again. Looking at the information of the instance, it now 
> say:
> 
>  No valid host was found. There are not enough hosts available.


Looking closer at the Controllers logs, I see:

- s n i p -
2016-06-24 00:29:38.835 20278 INFO glance.registry.api.v1.images 
[req-55daa3fe-c192-41a4-a5c0-0b6e076a4bcf 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] Image cirros not found
2016-06-24 00:29:38.837 20278 INFO eventlet.wsgi.server 
[req-55daa3fe-c192-41a4-a5c0-0b6e076a4bcf 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] 127.0.0.1 - - [24/Jun/2016 00:29:38] 
"GET /images/cirros HTTP/1.1" 404 242 0.251989
2016-06-24 00:29:38.852 20307 ERROR glance.registry.client.v1.client 
[req-55daa3fe-c192-41a4-a5c0-0b6e076a4bcf 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] Registry client request GET 
/images/cirros raised NotFound
- s n i p -
-- 
System administrators motto:
You're either invisible or in trouble.
- Unknown


___
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] Packaging Virtualenvs

[Matt Joyce]

I want the script to dynamically instantiate the venv is call activate this at 
execution time and deactivate when done.



On June 23, 2016 5:12:07 PM EDT, Doug Hellmann  wrote:
>Excerpts from Silence Dogood's message of 2016-06-23 15:45:34 -0400:
>> I know from conversations that a few folks package their python apps
>as
>> distributable virtualenvs.   spotify created dh-virtualenv for this. 
>you
>> can do it pretty simply by hand.
>> 
>> I built a toolchain for building rpms as distributable virtualenvs
>and that
>> works really well.
>> 
>> What I'd like to do is make it so that every app that's built as a
>> virtualenv gets setup to automatically execute at call time in their
>> virtualenv.
>> 
>> I see two options:
>> 
>> 1)  Dynamically generate a wrapper script during build and put it in
>the
>> RPM.  Call the wrapper.
>> 
>> 2)  Created a dependency global module ( as an rpm ) set it as a
>> dependency.  And basically it'd be an autoexecuting import that
>> instantiates the virtualenv.  it would probably know all it needs to
>> because I am building all my packages to an internal standard.  Then
>when
>> building the APP rpm all I need to do is inject an import into the
>import
>> chain if it's being built as a virtualenv.  Then I have what are
>> effectively statically compiled python apps.
>> 
>> I like 2.  But 1 isn't very bad.  Both are a little hokey.
>> 
>> Was curious if folks might have a preference, or a better idea.
>> 
>> Thanks.
>> 
>> Matt
>
>I'm not sure what you mean by a "wrapper script".  If you run the
>Python console script from within the virtualenv you've packaged,
>you shouldn't need to do anything to "activate" that environment
>separately because it should have the correct shebang line.
>
>Are you seeing different behavior?
>
>Doug
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack] What can make Cinder not find Image? (Was: Create instance fails on creating block device - Block Device Mapping is Invalid)

[Turbo Fredriksson]

- s n i p -
2016-06-23 23:08:25.277 25887 INFO cinder.api.openstack.wsgi 
[req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18d
b0dd03aa23 - - -] GET 
http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/test
2016-06-23 23:08:25.278 25887 DEBUG cinder.api.openstack.wsgi 
[req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18
db0dd03aa23 - - -] Empty body provided in request get_body 
/usr/lib/python2.7/dist-packages/cinder/api/openstack/wsgi.py:936
2016-06-23 23:08:25.278 25887 DEBUG cinder.api.openstack.wsgi 
[req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18
db0dd03aa23 - - -] Calling method '>' 
_process_stack /
usr/lib/python2.7/dist-packages/cinder/api/openstack/wsgi.py:1092
2016-06-23 23:08:25.362 25887 INFO cinder.api.openstack.wsgi 
[req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] HTTP exception thrown: Volume test 
could not be found.
2016-06-23 23:08:25.363 25887 INFO cinder.api.openstack.wsgi 
[req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] 
http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/test returned 
with HTTP 404
2016-06-23 23:08:25.366 25887 INFO eventlet.wsgi.server 
[req-9d2bc683-7599-4539-92a6-b8e8503591c8 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] 10.0.4.1 "GET 
/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/test HTTP/1.1" status: 404  len: 
418 time: 0.8508980
- s n i p -

and yet:

- s n i p -
bladeA01b:~# openstack volume list  
  
+--+--+---+--+-+
| ID   | Display Name | Status| Size | 
Attached to |
+--+--+---+--+-+
| 8dbd3b7c-e36b-433f-a3b0-d701f63f63c2 | test | available |5 |  
   |
+--+--+---+--+-+
- s n i p -

That's with the "admin" user+password etc though..
--
There are no dumb questions,
unless a customer is asking them.
- Unknown


___
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] NUMA, huge pages, and scheduling

[Jay Pipes]

On 06/22/2016 01:56 PM, Paul Michali wrote:

I did have a question about the current implementation as described by
292499, 324379, and 292500.

Looking at the code, when a NUMAPagesTopology object is create, a new
parameter is passed for the "reserved" pages. This reservation comes
from a dictionary, which is populated at LIbvirtDriver init time, via
grabbing the multi-string configuration settings from nova.conf. Because
the object's API is changed, a version change is required.

Is it possible to, instead of adding a new argument to reduce the
"total" argument (Ian Wells suggested this to me on a patch I had), by
the number of reserved pages from the config file? This would prevent
the need to alter the object's API.  So, instead of:

 mempages = [
 objects.NUMAPagesTopology(
 size_kb=pages.size,
 total=pages.total,
 used=0,
 reserved=_get_reserved_memory_for_cell(
 self,cell.id , pages.size))
 for pages in cell.mempages]


Do something like this...

  mempages = [

objects.NUMAPagesTopology( size_kb=pages.size, used=0, total=pages.total
- _get_reserved_memory_for_cell( self, cell.id ,
pages.size)) for pages in cell.mempages]
If we do this, would it avoid issues with back porting the change?


No, that would cause anyone who upgraded to Mitaka to immediately have 
the total column contain incorrect data... you would essentially have a 
double-reserve calculation.


Best,
-jay

__
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] [nova] NUMA, huge pages, and scheduling

[Jay Pipes]

On 06/22/2016 01:56 PM, Paul Michali wrote:

I did have a question about the current implementation as described by
292499, 324379, and 292500.

Looking at the code, when a NUMAPagesTopology object is create, a new
parameter is passed for the "reserved" pages. This reservation comes
from a dictionary, which is populated at LIbvirtDriver init time, via
grabbing the multi-string configuration settings from nova.conf. Because
the object's API is changed, a version change is required.

Is it possible to, instead of adding a new argument to reduce the
"total" argument (Ian Wells suggested this to me on a patch I had), by
the number of reserved pages from the config file? This would prevent
the need to alter the object's API.  So, instead of:

 mempages = [
 objects.NUMAPagesTopology(
 size_kb=pages.size,
 total=pages.total,
 used=0,
 reserved=_get_reserved_memory_for_cell(
 self,cell.id , pages.size))
 for pages in cell.mempages]


Do something like this...

  mempages = [

objects.NUMAPagesTopology( size_kb=pages.size, used=0, total=pages.total
- _get_reserved_memory_for_cell( self, cell.id ,
pages.size)) for pages in cell.mempages]
If we do this, would it avoid issues with back porting the change?

Thanks!

PCM


On Wed, Jun 15, 2016 at 5:52 PM Matt Riedemann
> wrote:

On 6/15/2016 3:10 PM, Paul Michali wrote:
 > Is the plan to back port that change to Mitaka?
 >
 > Thanks,
 >
 > PCM
 >
 >
 > On Wed, Jun 15, 2016 at 1:31 PM Matt Riedemann
 > 
>> wrote:
 >
 > On 6/14/2016 3:09 PM, Jay Pipes wrote:
 > >
 > > Yes. Code merged recently from Sahid does this:
 > >
 > > https://review.openstack.org/#/c/277422/
 > >
 > > Best,
 > > -jay
 > >
 >
 > That was actually reverted out of mitaka:
 >
 > https://review.openstack.org/#/c/292290/
 >
 > The feature change that got into newton was this:
 >
 > https://review.openstack.org/#/c/292499/
 >
 > Which was busted, and required:
 >
 > https://review.openstack.org/#/c/324379/
 >
 > Well, required as long as you want your compute service to
start. :)
 >
 > And no, we aren't backporting these, especially to liberty
which is
 > security / critical fix mode only now.
 >
 > --
 >
 > Thanks,
 >
 > Matt Riedemann
 >
 >
 >
  __
 > 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
 >

No, it's really a feature.

--

Thanks,

Matt Riedemann


__
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

[openstack-dev] [vitrage][aodh] Notifications about aodh alarm state changes

[Afek, Ifat (Nokia - IL)]

Hi Julien, Gordon,

I understood that during Aodh-Vitrage design session in Austin, you had a 
discussion about Vitrage need for notifications about Aodh alarm state changes. 
Did you have a chance to think about it since, and to check how this can be 
done?

Thanks,
Ifat.


__
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] [kolla] better solution for the non-ini format configure file

[Steven Dake (stdake)]

I looked more at this solution and am struggling to come up with a solution for:


https://github.com/openstack/kolla/blob/master/ansible/roles/nova/tasks/config.yml#L69-L85


That doesn't involve creating a task per file.


Any ideas?


Regards

-steve

From: Steven Dake >
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Thursday, June 23, 2016 at 6:07 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: Re: [openstack-dev] [kolla] better solution for the non-ini format 
configure file

Looks like a really cool feature, and possibly a way to non-ini files, such as 
policy.json files which we just want to copy rather then override.

Kolla already has ini merging for ini files though and the example you provide 
is an ini file.  I like Kolla's ini merging, and it is sort of an external 
interface, since operators have been using it, so to remove it would mean 
following the deprecation cycle.  I do agree this would be fantastic for 
straight copies of non-ini configuration files.

Regards
-steve

From: OpenStack Mailing List Archive >
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Wednesday, June 22, 2016 at 8:47 PM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: Re: [openstack-dev] [kolla] better solution for the non-ini format 
configure file

Link: https://openstack.nimeyo.com/83165/?show=88496#a88496
From: AndrewLiu >


Recently, we find this feature of ansible:
http://docs.ansible.com/ansible/playbooks_loops.html#finding-first-matched-files

A specific path of template file can be add in the ansible task.

If a user want to customize an non-ini template file, the user can copy the 
template file to the customization directory, and modify the template file as 
the user wants.

An example of how to modify the ansible task:

change from:

- name: Copying over horizon.conf
  template:
  src: "{{ item }}.conf.j2"
  dest: "{{ node_config_directory }}/{{ item }}/{{ item }}.conf"
  with_items:
  - "horizon"


to:

- name: Copying over horizon.conf
  template:
  src: "{{ item }}"
  dest: "{{ node_config_directory }}/horizon/horizon.conf"
  with_first_found:
  - "{{ node_custom_config }}/horizon.conf.j2"
  - "horizon.conf.j2"


But a convention of how to organize the directory structure of customization 
template files should be addressed.
__
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] [lbaas]HA for lbaas v2 agent

[Doug Wiegley]

As Assaf mentioned, namespace and octavia are two different lbaas drivers.  But 
within those:

- The lbaas plugin will schedule lbaas VIPs from all available lbaas-agents (I 
think it’s random.)  No, you can’t move them later, or override the scheduler.

- The lbaas agent is used by the octavia driver. Octavia is its own REST 
endpoint, and the lbaas driver for it just makes synchronous REST calls.

Thanks,
doug


> On Jun 23, 2016, at 3:33 PM, Assaf Muller  wrote:
> 
> On Thu, Jun 23, 2016 at 3:43 PM, Akshay Kumar Sanghai
>  wrote:
>> Thanks Assaf.
>> I have few questions for lbaas:
>> -  if i run agents on multiple nodes, will the request be ditrsibuted by
>> neutron-server?
>> - Does neutron lbaas agent forward the request to octavia-api or the
>> neutron-server?
> 
> The LBaaS v2 API has multiple implementations. One of which is based
> off haproxy and namespaces, known as the agent based implementation.
> Do you have neutron-lbaas-agent running on your network nodes? The
> second implementation is called Octavia and is based off service VMs
> instead of agents and namespaces. Octavia calls out to Nova to create
> VMs and inside those VMs is an agent that talks back to Octavia, and
> that creates an haproxy instance to perform the actual loadbalancing.
> The answer to both of your questions depends on which of these two
> implementations you're going with. There's a bunch of summit sessions
> about Octavia you can look in to.
> 
>> 
>> Thanks
>> Akshay
>> 
>> On Thu, Jun 23, 2016 at 1:00 AM, Assaf Muller  wrote:
>>> 
>>> On Wed, Jun 22, 2016 at 3:17 PM, Akshay Kumar Sanghai
>>>  wrote:
 Hi,
 I have a multinode openstack installation (3 controller, 3 network
 nodes,
 and some compute nodes).
 Like l3 agent, is high availability feature available for the lbaas v2
 agent?
>>> 
>>> It is not. Nir Magnezi is working on a couple of patches to implement
>>> a simplistic HA solution for LBaaS v2 with haproxy:
>>> https://review.openstack.org/#/c/28/
>>> https://review.openstack.org/#/c/327966/
>>> 
 
 Thanks
 Akshay
 
 
 __
 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


__
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] [lbaas]HA for lbaas v2 agent

[Assaf Muller]

On Thu, Jun 23, 2016 at 3:43 PM, Akshay Kumar Sanghai
 wrote:
> Thanks Assaf.
> I have few questions for lbaas:
> -  if i run agents on multiple nodes, will the request be ditrsibuted by
> neutron-server?
> - Does neutron lbaas agent forward the request to octavia-api or the
> neutron-server?

The LBaaS v2 API has multiple implementations. One of which is based
off haproxy and namespaces, known as the agent based implementation.
Do you have neutron-lbaas-agent running on your network nodes? The
second implementation is called Octavia and is based off service VMs
instead of agents and namespaces. Octavia calls out to Nova to create
VMs and inside those VMs is an agent that talks back to Octavia, and
that creates an haproxy instance to perform the actual loadbalancing.
The answer to both of your questions depends on which of these two
implementations you're going with. There's a bunch of summit sessions
about Octavia you can look in to.

>
> Thanks
> Akshay
>
> On Thu, Jun 23, 2016 at 1:00 AM, Assaf Muller  wrote:
>>
>> On Wed, Jun 22, 2016 at 3:17 PM, Akshay Kumar Sanghai
>>  wrote:
>> > Hi,
>> > I have a multinode openstack installation (3 controller, 3 network
>> > nodes,
>> > and some compute nodes).
>> > Like l3 agent, is high availability feature available for the lbaas v2
>> > agent?
>>
>> It is not. Nir Magnezi is working on a couple of patches to implement
>> a simplistic HA solution for LBaaS v2 with haproxy:
>> https://review.openstack.org/#/c/28/
>> https://review.openstack.org/#/c/327966/
>>
>> >
>> > Thanks
>> > Akshay
>> >
>> >
>> > __
>> > 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-operators] Packaging Virtualenvs

[Kris G. Lindgren]

When we did this within CentOS6 with the python 2.7 software collection.  When 
nova called into nova-rootwrap, rootwrap was called without any of the software 
collection or venv stuff activated. So we had to move rootwrap to rootwrap-real 
and create a shell script that did the needful (activate the software 
collection and activate the venv, then call rootwrap-real).

Other than that we just modified the normal upstart scripts to activate the 
venv before executing the service like normal.  Under systemd one would do the 
same.  We never packaged the openstack clients into venv's, but if we did one 
could just add the correct stuff to your keystonerc file.
___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy







On 6/23/16, 3:12 PM, "Doug Hellmann"  wrote:

>Excerpts from Silence Dogood's message of 2016-06-23 15:45:34 -0400:
>> I know from conversations that a few folks package their python apps as
>> distributable virtualenvs.   spotify created dh-virtualenv for this.  you
>> can do it pretty simply by hand.
>> 
>> I built a toolchain for building rpms as distributable virtualenvs and that
>> works really well.
>> 
>> What I'd like to do is make it so that every app that's built as a
>> virtualenv gets setup to automatically execute at call time in their
>> virtualenv.
>> 
>> I see two options:
>> 
>> 1)  Dynamically generate a wrapper script during build and put it in the
>> RPM.  Call the wrapper.
>> 
>> 2)  Created a dependency global module ( as an rpm ) set it as a
>> dependency.  And basically it'd be an autoexecuting import that
>> instantiates the virtualenv.  it would probably know all it needs to
>> because I am building all my packages to an internal standard.  Then when
>> building the APP rpm all I need to do is inject an import into the import
>> chain if it's being built as a virtualenv.  Then I have what are
>> effectively statically compiled python apps.
>> 
>> I like 2.  But 1 isn't very bad.  Both are a little hokey.
>> 
>> Was curious if folks might have a preference, or a better idea.
>> 
>> Thanks.
>> 
>> Matt
>
>I'm not sure what you mean by a "wrapper script".  If you run the
>Python console script from within the virtualenv you've packaged,
>you shouldn't need to do anything to "activate" that environment
>separately because it should have the correct shebang line.
>
>Are you seeing different behavior?
>
>Doug
>
>___
>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] [all] Status of the OpenStack port to Python 3

[Clark Boylan]

On Thu, Jun 23, 2016, at 02:15 PM, Doug Hellmann wrote:
> Excerpts from Thomas Goirand's message of 2016-06-23 23:04:28 +0200:
> > On 06/23/2016 06:11 PM, Doug Hellmann wrote:
> > > I'd like for the community to set a goal for Ocata to have Python
> > > 3 functional tests running for all projects.
> > > 
> > > As Tony points out, it's a bit late to have this as a priority for
> > > Newton, though work can and should continue. But given how close
> > > we are to having the initial phase of the port done (thanks Victor!),
> > > and how far we are from discussions of priorities for Ocata, it
> > > seems very reasonable to set a community-wide goal for our next
> > > release cycle.
> > > 
> > > Thoughts?
> > > 
> > > Doug
> > 
> > +1
> > 
> > Just think about it for a while. If we get Nova to work with Py3, and
> > everything else is working, including all functional tests in Tempest,
> > then after Otaca, we could even start to *REMOVE* Py2 support after
> > Otaca+1. That would be really awesome to stop all the compat layer
> > madness and use the new features available in Py3.
> 
> We'll need to get some input from other distros and from deployers
> before we decide on a timeline for dropping Python 2. For now, let's
> focus on making Python 3 work. Then we can all rejoice while having the
> discussion of how much longer to support Python 2. :-)
> 
> > 
> > I really would love to ship a full stack running Py3 for Debian Stretch.
> > However, for this, it'd be super helful to have as much visibility as
> > possible. Are we setting a hard deadline for the Otaca release? Or is
> > this just a goal we only "would like" to reach, but it's not really a
> > big deal if we don't reach it?
> 
> Let's see what PTLs have to say about planning, but I think if not
> Ocata then we'd want to set one for the P release. We're running
> out of supported lifetime for Python 2.7.

Keep in mind that there is interest in running OpenStack on PyPy which
is python 2.7. We don't have to continue supporting CPython 2.7
necessarily but we may want to support python 2.7 by way of PyPy.

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] [all] Status of the OpenStack port to Python 3

[Doug Hellmann]

Excerpts from Thomas Goirand's message of 2016-06-23 23:04:28 +0200:
> On 06/23/2016 06:11 PM, Doug Hellmann wrote:
> > I'd like for the community to set a goal for Ocata to have Python
> > 3 functional tests running for all projects.
> > 
> > As Tony points out, it's a bit late to have this as a priority for
> > Newton, though work can and should continue. But given how close
> > we are to having the initial phase of the port done (thanks Victor!),
> > and how far we are from discussions of priorities for Ocata, it
> > seems very reasonable to set a community-wide goal for our next
> > release cycle.
> > 
> > Thoughts?
> > 
> > Doug
> 
> +1
> 
> Just think about it for a while. If we get Nova to work with Py3, and
> everything else is working, including all functional tests in Tempest,
> then after Otaca, we could even start to *REMOVE* Py2 support after
> Otaca+1. That would be really awesome to stop all the compat layer
> madness and use the new features available in Py3.

We'll need to get some input from other distros and from deployers
before we decide on a timeline for dropping Python 2. For now, let's
focus on making Python 3 work. Then we can all rejoice while having the
discussion of how much longer to support Python 2. :-)

> 
> I really would love to ship a full stack running Py3 for Debian Stretch.
> However, for this, it'd be super helful to have as much visibility as
> possible. Are we setting a hard deadline for the Otaca release? Or is
> this just a goal we only "would like" to reach, but it's not really a
> big deal if we don't reach it?

Let's see what PTLs have to say about planning, but I think if not
Ocata then we'd want to set one for the P release. We're running
out of supported lifetime for Python 2.7.

Doug

__
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] Packaging Virtualenvs

[Doug Hellmann]

Excerpts from Silence Dogood's message of 2016-06-23 15:45:34 -0400:
> I know from conversations that a few folks package their python apps as
> distributable virtualenvs.   spotify created dh-virtualenv for this.  you
> can do it pretty simply by hand.
> 
> I built a toolchain for building rpms as distributable virtualenvs and that
> works really well.
> 
> What I'd like to do is make it so that every app that's built as a
> virtualenv gets setup to automatically execute at call time in their
> virtualenv.
> 
> I see two options:
> 
> 1)  Dynamically generate a wrapper script during build and put it in the
> RPM.  Call the wrapper.
> 
> 2)  Created a dependency global module ( as an rpm ) set it as a
> dependency.  And basically it'd be an autoexecuting import that
> instantiates the virtualenv.  it would probably know all it needs to
> because I am building all my packages to an internal standard.  Then when
> building the APP rpm all I need to do is inject an import into the import
> chain if it's being built as a virtualenv.  Then I have what are
> effectively statically compiled python apps.
> 
> I like 2.  But 1 isn't very bad.  Both are a little hokey.
> 
> Was curious if folks might have a preference, or a better idea.
> 
> Thanks.
> 
> Matt

I'm not sure what you mean by a "wrapper script".  If you run the
Python console script from within the virtualenv you've packaged,
you shouldn't need to do anything to "activate" that environment
separately because it should have the correct shebang line.

Are you seeing different behavior?

Doug

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

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

[Allison Price]

Hi Anita,

No, registration has not been opened yet. Once it has, we will update the 
mailing list. 

Cheers,
Allison


Allison Price
OpenStack Marketing
alli...@openstack.org


> On Jun 23, 2016, at 3:52 PM, Anita Kuno  wrote:
> 
> On 06/23/2016 04:42 PM, Mark Voelker wrote:
>> Hi Folks,
>> 
>> A quick update on this: today’s the last day of earlybird pricing for 
>> OpenStack East, so if you’d like to attend both events I’d encourage you to 
>> register now (it’s only $99 for the next ~7 hours):
>> 
>> https://www.eventbrite.com/e/openstack-east-tickets-22413148330?ref=ebtnebregn
>> 
>> If you can’t register today, some good news: I spoke with the conference 
>> organizers and it looks like we’ll be able to get some sort of discount code 
>> for folks who are attending the Ops Midcycle and also want to attend 
>> OpenStack East!  We’re still working out logistics, so bear with me—I’ll 
>> send along some more info when I have it.
>> 
>> At Your Service,
>> 
>> Mark T. Voelker
>> 
>> 
>> 
>>> On Jun 22, 2016, at 2:16 PM, Mark Voelker  wrote:
>>> 
>>> It would definitely be cool to have more ops folks attend both events.  I’d 
>>> be happy to check in with the rest of the organizers and see if there’s a 
>>> possibility of working something out.
>>> 
>>> At Your Service,
>>> 
>>> Mark T. Voelker
>>> 
>>> 
>>> 
 On Jun 22, 2016, at 12:27 PM, David Medberry  
 wrote:
 
 Would be sweet if that offer could be extended at least a week as we go 
 through the corp travel process. OTOH, $99 is almost cheap enough to buy 
 and not care I'll be doing that I guess.
 
 On Wed, Jun 22, 2016 at 9:44 AM, Matt Jarvis 
  wrote:
 Hi Mark
 
 Given we've not got the Eventbrite for the Ops Meetup live yet, is there 
 any chance you could extend the early bird pricing or give operators who 
 may be travelling for the Ops Meetup a discount code ? I suspect there may 
 be quite a lot of interest for those travelling some distance. 
 
 Matt
 
 On 22 June 2016 at 14:58, Mark Voelker  wrote:
 Hi Ops,
 
 FYI for those that may not be aware, that’s also the week of OpenStack 
 East.  OpenStack East runs August 23-24 also in New York City (about 
 ~15-20 minutes away from Civic Hall by MTA at the Playstation Theater).  
 If you’re coming to town for the Ops Midcycle, you may want to make a week 
 of it.  Earlybird pricing for OpenStack East is still available but prices 
 increase tomorrow:
 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openstackeast.com_=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=Pouk4RdhAp3O0-4z088jjeJcdTHWxG2QEHGPaCapbAg=pst_dGQnf8jOAggeotgW1NJGzEAbCpWryQ7tNon78IM=
  
 
 At Your Service,
 
 Mark T. Voelker
 (wearer of many hats, one of which is OpenStack East steering committee 
 member)
 
 
 
> On Jun 21, 2016, at 11:36 AM, Jonathan D. Proulx  
> wrote:
> 
> Hi All,
> 
> The Ops Meetups Team has selected[1] New York City as the location of the
> next mid-cycle meetup on August 25 and 26 2016 at Civic Hall[2]
> 
> Many thanks to Bloomberg for sponsoring the location.  And thanks to
> BestBuy as well for their offer of the Seattle location.  The choice
> was very close and hopefully their offer will stand for our next North
> American meet-up.
> 
> There's quite a bit of work to do to make this all happen in the
> next couple of months so it's still a great time to join the Ops
> Meetups Team[3] and help out.
> 
> -Jon
> 
> --
> 
> [1] 
> http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-06-21-14.02.html
> [2] 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__civichall.org_about-2Dcivic-2Dhall_=CwICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=oAH-SSZ6EFikpmcyUpbf3984kyPBIuLJKkQadC6CKUw=36Kl-0b4WBC06xaYXo0V5AM2lHzvjhL48bBV48cz2is=
> [3] https://wiki.openstack.org/wiki/Ops_Meetups_Team
> 
> 
> ___
> 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
 
 
 DataCentred Limited registered in England and Wales no. 05611763
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
 

Re: [openstack-dev] [all] Status of the OpenStack port to Python 3

[Thomas Goirand]

On 06/23/2016 06:11 PM, Doug Hellmann wrote:
> I'd like for the community to set a goal for Ocata to have Python
> 3 functional tests running for all projects.
> 
> As Tony points out, it's a bit late to have this as a priority for
> Newton, though work can and should continue. But given how close
> we are to having the initial phase of the port done (thanks Victor!),
> and how far we are from discussions of priorities for Ocata, it
> seems very reasonable to set a community-wide goal for our next
> release cycle.
> 
> Thoughts?
> 
> Doug

+1

Just think about it for a while. If we get Nova to work with Py3, and
everything else is working, including all functional tests in Tempest,
then after Otaca, we could even start to *REMOVE* Py2 support after
Otaca+1. That would be really awesome to stop all the compat layer
madness and use the new features available in Py3.

I really would love to ship a full stack running Py3 for Debian Stretch.
However, for this, it'd be super helful to have as much visibility as
possible. Are we setting a hard deadline for the Otaca release? Or is
this just a goal we only "would like" to reach, but it's not really a
big deal if we don't reach it?

Cheers,

Thomas Goirand (zigo)

P.S: Again, thanks Victor for your awesome work.


__
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] Next Ops Midcycle NYC August 25-26

[Anita Kuno]

On 06/23/2016 04:42 PM, Mark Voelker wrote:
> Hi Folks,
> 
> A quick update on this: today’s the last day of earlybird pricing for 
> OpenStack East, so if you’d like to attend both events I’d encourage you to 
> register now (it’s only $99 for the next ~7 hours):
> 
> https://www.eventbrite.com/e/openstack-east-tickets-22413148330?ref=ebtnebregn
> 
> If you can’t register today, some good news: I spoke with the conference 
> organizers and it looks like we’ll be able to get some sort of discount code 
> for folks who are attending the Ops Midcycle and also want to attend 
> OpenStack East!  We’re still working out logistics, so bear with me—I’ll send 
> along some more info when I have it.
> 
> At Your Service,
> 
> Mark T. Voelker
> 
> 
> 
>> On Jun 22, 2016, at 2:16 PM, Mark Voelker  wrote:
>>
>> It would definitely be cool to have more ops folks attend both events.  I’d 
>> be happy to check in with the rest of the organizers and see if there’s a 
>> possibility of working something out.
>>
>> At Your Service,
>>
>> Mark T. Voelker
>>
>>
>>
>>> On Jun 22, 2016, at 12:27 PM, David Medberry  wrote:
>>>
>>> Would be sweet if that offer could be extended at least a week as we go 
>>> through the corp travel process. OTOH, $99 is almost cheap enough to buy 
>>> and not care I'll be doing that I guess.
>>>
>>> On Wed, Jun 22, 2016 at 9:44 AM, Matt Jarvis 
>>>  wrote:
>>> Hi Mark
>>>
>>> Given we've not got the Eventbrite for the Ops Meetup live yet, is there 
>>> any chance you could extend the early bird pricing or give operators who 
>>> may be travelling for the Ops Meetup a discount code ? I suspect there may 
>>> be quite a lot of interest for those travelling some distance. 
>>>
>>> Matt
>>>
>>> On 22 June 2016 at 14:58, Mark Voelker  wrote:
>>> Hi Ops,
>>>
>>> FYI for those that may not be aware, that’s also the week of OpenStack 
>>> East.  OpenStack East runs August 23-24 also in New York City (about ~15-20 
>>> minutes away from Civic Hall by MTA at the Playstation Theater).  If you’re 
>>> coming to town for the Ops Midcycle, you may want to make a week of it.  
>>> Earlybird pricing for OpenStack East is still available but prices increase 
>>> tomorrow:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openstackeast.com_=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=Pouk4RdhAp3O0-4z088jjeJcdTHWxG2QEHGPaCapbAg=pst_dGQnf8jOAggeotgW1NJGzEAbCpWryQ7tNon78IM=
>>>  
>>>
>>> At Your Service,
>>>
>>> Mark T. Voelker
>>> (wearer of many hats, one of which is OpenStack East steering committee 
>>> member)
>>>
>>>
>>>
 On Jun 21, 2016, at 11:36 AM, Jonathan D. Proulx  
 wrote:

 Hi All,

 The Ops Meetups Team has selected[1] New York City as the location of the
 next mid-cycle meetup on August 25 and 26 2016 at Civic Hall[2]

 Many thanks to Bloomberg for sponsoring the location.  And thanks to
 BestBuy as well for their offer of the Seattle location.  The choice
 was very close and hopefully their offer will stand for our next North
 American meet-up.

 There's quite a bit of work to do to make this all happen in the
 next couple of months so it's still a great time to join the Ops
 Meetups Team[3] and help out.

 -Jon

 --

 [1] 
 http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-06-21-14.02.html
 [2] 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__civichall.org_about-2Dcivic-2Dhall_=CwICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=oAH-SSZ6EFikpmcyUpbf3984kyPBIuLJKkQadC6CKUw=36Kl-0b4WBC06xaYXo0V5AM2lHzvjhL48bBV48cz2is=
 [3] https://wiki.openstack.org/wiki/Ops_Meetups_Team


 ___
 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
>>>
>>>
>>> DataCentred Limited registered in England and Wales no. 05611763
>>> ___
>>> 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
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> 

Re: [OpenStack-Infra] Questions when Desired Project Name and Launchpad URL does not match for a new project

[Elizabeth K. Joseph]

On Wed, Jun 22, 2016 at 10:52 PM, HU, BIN  wrote:
> (1)Are those names case-sensitive?

No, but lowercase project names are preferred in our configs for consistency.

> (2)Because our Gluon project’s the Launchpad URL is “python-gluon”,
> which is different from our intended OpenStack project name
> “openstack/gluon”, what should I do?
>
> a.   I see an example the manual:
>
>
>
> - project: openstack/
>
>   description: Latest and greatest cloud stuff.
>
>   groups:
>
>  - oslo
>
>
>
> So should I use “groups: -gluon” or something else to
> resolve the mismatch of “openstack/gluon” and
> “https://launchpad.net/python-gluon”?

It should be:

  groups: python-gluton

A similar example is the stevedore project that had the same problem:

http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n3795

> (3)In https://git.openstack.org/openstack-dev/cookiecutter.json, I see:
>
>
>
> {
>
> "module_name": "replace with the name of the python module",
>
> "repo_group": "openstack",
>
> "repo_name": "replace with the name for the git repo",
>
> "launchpad_project": "replace with the name of the project on
> launchpad",
>
> "project_short_description": "OpenStack Boilerplate contains all the
> boilerplate you need to create an OpenStack package."
>
> }
>
>
>
> Note the bolded “replace with the name of the project on launchpad”:
>
> -  what does this mean?
>
> -  Should it be changed because of project name/repo
> “openstack/gluon” and Launchpad URL “python-gluon”?

I'm not very familiar with the cookiecutter repo so someone else may
want to chime in here to explain, but it seems like:

repo_group is openstack

repo_name is gluton

launchpad_project is python-gluon

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

[openstack-dev] [release] Release countdown for week R-15, Jun 20-24

[Doug Hellmann]

Focus
-

Teams should be working on new feature development and bug fixes in this
period between
the first and second milestones.

General Notes
-

The members of the release team will all be traveling next week.
This will result in delays in releases being processed, so please
plan accordingly.

Release Actions
---

Official independent projects should file information about historical
releases using the openstack/releases repository so the team pages
on releases.openstack.org are up to date.

This is also a good time to review stable/liberty and stable/mitaka
branches for needed releases.

Important Dates
---

Newton 2 milestone, July 14.

Newton release schedule: http://releases.openstack.org/newton/schedule.html

__
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] Next Ops Midcycle NYC August 25-26

[Mark Voelker]

Hi Folks,

A quick update on this: today’s the last day of earlybird pricing for OpenStack 
East, so if you’d like to attend both events I’d encourage you to register now 
(it’s only $99 for the next ~7 hours):

https://www.eventbrite.com/e/openstack-east-tickets-22413148330?ref=ebtnebregn

If you can’t register today, some good news: I spoke with the conference 
organizers and it looks like we’ll be able to get some sort of discount code 
for folks who are attending the Ops Midcycle and also want to attend OpenStack 
East!  We’re still working out logistics, so bear with me—I’ll send along some 
more info when I have it.

At Your Service,

Mark T. Voelker



> On Jun 22, 2016, at 2:16 PM, Mark Voelker  wrote:
> 
> It would definitely be cool to have more ops folks attend both events.  I’d 
> be happy to check in with the rest of the organizers and see if there’s a 
> possibility of working something out.
> 
> At Your Service,
> 
> Mark T. Voelker
> 
> 
> 
>> On Jun 22, 2016, at 12:27 PM, David Medberry  wrote:
>> 
>> Would be sweet if that offer could be extended at least a week as we go 
>> through the corp travel process. OTOH, $99 is almost cheap enough to buy and 
>> not care I'll be doing that I guess.
>> 
>> On Wed, Jun 22, 2016 at 9:44 AM, Matt Jarvis  
>> wrote:
>> Hi Mark
>> 
>> Given we've not got the Eventbrite for the Ops Meetup live yet, is there any 
>> chance you could extend the early bird pricing or give operators who may be 
>> travelling for the Ops Meetup a discount code ? I suspect there may be quite 
>> a lot of interest for those travelling some distance. 
>> 
>> Matt
>> 
>> On 22 June 2016 at 14:58, Mark Voelker  wrote:
>> Hi Ops,
>> 
>> FYI for those that may not be aware, that’s also the week of OpenStack East. 
>>  OpenStack East runs August 23-24 also in New York City (about ~15-20 
>> minutes away from Civic Hall by MTA at the Playstation Theater).  If you’re 
>> coming to town for the Ops Midcycle, you may want to make a week of it.  
>> Earlybird pricing for OpenStack East is still available but prices increase 
>> tomorrow:
>> 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openstackeast.com_=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=Pouk4RdhAp3O0-4z088jjeJcdTHWxG2QEHGPaCapbAg=pst_dGQnf8jOAggeotgW1NJGzEAbCpWryQ7tNon78IM=
>>  
>> 
>> At Your Service,
>> 
>> Mark T. Voelker
>> (wearer of many hats, one of which is OpenStack East steering committee 
>> member)
>> 
>> 
>> 
>>> On Jun 21, 2016, at 11:36 AM, Jonathan D. Proulx  wrote:
>>> 
>>> Hi All,
>>> 
>>> The Ops Meetups Team has selected[1] New York City as the location of the
>>> next mid-cycle meetup on August 25 and 26 2016 at Civic Hall[2]
>>> 
>>> Many thanks to Bloomberg for sponsoring the location.  And thanks to
>>> BestBuy as well for their offer of the Seattle location.  The choice
>>> was very close and hopefully their offer will stand for our next North
>>> American meet-up.
>>> 
>>> There's quite a bit of work to do to make this all happen in the
>>> next couple of months so it's still a great time to join the Ops
>>> Meetups Team[3] and help out.
>>> 
>>> -Jon
>>> 
>>> --
>>> 
>>> [1] 
>>> http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-06-21-14.02.html
>>> [2] 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__civichall.org_about-2Dcivic-2Dhall_=CwICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=oAH-SSZ6EFikpmcyUpbf3984kyPBIuLJKkQadC6CKUw=36Kl-0b4WBC06xaYXo0V5AM2lHzvjhL48bBV48cz2is=
>>> [3] https://wiki.openstack.org/wiki/Ops_Meetups_Team
>>> 
>>> 
>>> ___
>>> 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
>> 
>> 
>> DataCentred Limited registered in England and Wales no. 05611763
>> ___
>> 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

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

Re: [Openstack] Volume creation

[Remo Mattei]

Check out targetcli which is showing you the iscsi info. The api calls that to 
create the volume 

Remo

Inviato da iPhone

> Il giorno 23 giu 2016, alle ore 12:43, Turbo Fredriksson  
> ha scritto:
> 
>> On Jun 23, 2016, at 8:37 PM, Remo Mattei wrote:
>> 
>> Once it gets attached 
> 
> Ok, thanx. That will help a little in pinpointing where I'm failing.
> --
> Choose a job you love, and you will never have
> to work a day in your life.
> 
> 
> ___
> 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
> 
> !DSPAM:1,576c3f92201631460711840!
> 


___
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] Placement API WSGI code -- let's just use flask

[Gregory Haynes]

On Wed, Jun 22, 2016, at 09:07 AM, Chris Dent wrote:
> On Tue, 21 Jun 2016, Sylvain Bauza wrote:
> 
> > To be honest, Chris and you were saying that you don't like Flask, and I'm 
> > a 
> > bit agreeing with you. Why now it's a good possibility ?
> 
> As I said when I started the other version of this same thread: What is
> most important to me is generating a consensus that we can actually
> commit to. To build a _real_ consensus it is important to have
> strong opionions that are weakly held[1] otherwise we are not
> actually evaluating the options.
> 
> You are right: I don't like Flask. It claims to be a microframework
> but to me it is overweight. I do, however, like it more than the
> chaos that is the current Nova WSGI stack.

This seems to be a recurring complaint in this thread - has any
consideration been given to using werkzeug[1] directly (its the library
underneath Flask). IMO this isn't a big win because the extra stuff that
comes in with Flask shouldn't present additional problems for us, but if
that really is the sticking point then it might be worth a look.

> 
> Flask has a very strong community and it does lots of stuff well
> such that we, in OpenStack, could just stop worrying about it. That
> is one reasonable way to approach doing WSGI moving forward.
> 

++. If there are issues we hit in Flask because of the extra components
we are so worried about then maybe we could work with them to resolve
these issues? I get the impression we are throwing out the baby with the
bathwater avoiding it altogether due to this fear.

> > Why not Routes and Paste couldn't be using also ?
> 
> More on this elsewhere in the thread.
> 

Cheers,
Greg

1: https://github.com/pallets/werkzeug

__
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] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[Sean McGinnis]

On Thu, Jun 23, 2016 at 12:07:43PM -0600, Chris Friesen wrote:
> On 06/23/2016 10:09 AM, Walter A. Boring IV wrote:
> >
> >volumes connected to QEMU instances eventually become directly connected?
> >
> >>Our long term goal is that 100% of all network storage will be connected
> >>to directly by QEMU. We already have the ability to partially do this with
> >>iSCSI, but it is lacking support for multipath. As & when that gap is
> >>addressed though, we'll stop using the host OS for any iSCSI stuff.
> >>
> >>So if you're requiring access to host iSCSI volumes, it'll work in the
> >>short-medium term, but in the medium-long term we're not going to use
> >>that so plan accordingly.
> >
> >What is the benefit of this largely monolithic approach?  It seems that
> >moving everything into QEMU is diametrically opposed to the unix model 
> >itself and
> >is just a re-implementation of what already exists in the linux world 
> >outside of
> >QEMU.
> >
> >Does QEMU support hardware initiators? iSER?
> >
> >We regularly fix issues with iSCSI attaches in the release cycles of 
> >OpenStack,
> >because it's all done in python using existing linux packages.  How often 
> >are QEMU
> >releases done and upgraded on customer deployments vs. python packages 
> >(os-brick)?
> >
> >I don't see a compelling reason for re-implementing the wheel,
> >and it seems like a major step backwards.
> 
> This is an interesting point.
> 
> Unless there's a significant performance benefit to connecting
> directly from qemu, it seems to me that we would want to leverage
> the existing work done by the kernel and other "standard" iSCSI
> initators.
> 
> Chris

I'm curious to find out this as well. Is this for a performance gain? If
so, do we have any metrics showing that gain is significant enough to
warrant making a change like this?

The host OS is still going to be involved. AFAIK, this just cuts out the
software iSCSI initiator from the picture. So we would be moving from a
piece of software dedicated to one specific functionality, to a
different piece of software that's main reason for existence is nothing
to do with IO path management.

I'm not saying I'm completely opposed to this. If there is a reason for
doing it then it could be worth it. But so far I haven't seen anything
explaining why this would be better than what we have today.

> 
> __
> 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] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[Sean McGinnis]

On Thu, Jun 23, 2016 at 09:50:11AM -0700, Preston L. Bannister wrote:
> Daniel, Thanks. Looking for a sense of direction.
> 
> Clearly there is some range of opinion, as Walter indicates. :)
> 
> Not sure you are get to 100% direct connection to QEMU. When there is
> dedicated hardware to do off-board processing of the connection to storage,
> you might(?) be stuck routing through the nova-compute host Linux. (I am
> not an expert in this area, so I could easily be wrong.) This sort of
> hardware tends to be associated with higher-end "enterprise" storage and
> hosts (and higher cost). The storage guys are in the habit of calling these
> "HBA adaptors" (for high-bandwidth) - might just be a local thing.

nit: HBA == Host Bus Adapter

:)
> 
> I *suspect* that higher cost will drive most cloud deployments away from
> that sort of specialized hardware. In which case the direct-connect to QEMU
> model should (mostly?) work. (My non-expert guess.)
> 
> 
> 
> On Thu, Jun 23, 2016 at 9:09 AM, Walter A. Boring IV 
> wrote:
> 
> >
> > volumes connected to QEMU instances eventually become directly connected?
> >
> > Our long term goal is that 100% of all network storage will be connected
> >> to directly by QEMU. We already have the ability to partially do this with
> >> iSCSI, but it is lacking support for multipath. As & when that gap is
> >> addressed though, we'll stop using the host OS for any iSCSI stuff.
> >>
> >> So if you're requiring access to host iSCSI volumes, it'll work in the
> >> short-medium term, but in the medium-long term we're not going to use
> >> that so plan accordingly.
> >>
> >
> > What is the benefit of this largely monolithic approach?  It seems that
> > moving everything into QEMU is diametrically opposed to the unix model
> > itself and
> > is just a re-implementation of what already exists in the linux world
> > outside of QEMU.
> >
> > Does QEMU support hardware initiators? iSER?
> >
> > We regularly fix issues with iSCSI attaches in the release cycles of
> > OpenStack,
> > because it's all done in python using existing linux packages.  How often
> > are QEMU
> > releases done and upgraded on customer deployments vs. python packages
> > (os-brick)?
> >
> > I don't see a compelling reason for re-implementing the wheel,
> > and it seems like a major step backwards.
> >
> >
> >> Xiao's unanswered query (below) presents another question. Is this a
> >>> site-choice? Could I require my customers to configure their OpenStack
> >>> clouds to always route iSCSI connections through the nova-compute host?
> >>> (I
> >>> am not a fan of this approach, but I have to ask.)
> >>>
> >>
> 
> > In the short term that'll work, but long term we're not intending to
> >> support that once QEMU gains multi-path. There's no timeframe on when
> >> that will happen though.
> >>
> >>
> >> Regards,
> >> Daniel
> >>
> >

> __
> 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] Status of the OpenStack port to Python 3

[Sean McGinnis]

On Thu, Jun 23, 2016 at 12:58:23PM -0400, Davanum Srinivas wrote:

+1 from me as well. I get questions on support for these often enough.

> +1 from me as well Doug! ("community to set a goal for Ocata to have Python
> 3 functional tests running for all projects.")
> 
> -- Dims
> 
> On Thu, Jun 23, 2016 at 12:11 PM, Doug Hellmann  wrote:
> > Excerpts from Thomas Goirand's message of 2016-06-22 10:49:01 +0200:
> >> On 06/22/2016 09:18 AM, Victor Stinner wrote:
> >> > Hi,
> >> >
> >> > Current status: only 3 projects are not ported yet to Python 3:
> >> >
> >> > * nova (76% done)
> >> > * trove (42%)
> >> > * swift (0%)
> >> >
> >> >https://wiki.openstack.org/wiki/Python3
> >> >
> >> > Number of projects already ported:
> >> >
> >> > * 19 Oslo Libraries
> >> > * 4 Development Tools
> >> > * 22 OpenStack Clients
> >> > * 6 OpenStack Libraries (os-brick, taskflow, glance_store, ...)
> >> > * 12 OpenStack services approved by the TC
> >> > * 17 OpenStack services (not approved by the TC)
> >> >
> >> > Raw total: 80 projects. In fact, 3 remaining projects on 83 is only 4%,
> >> > we are so close! ;-)
> >> >
> >> > The next steps are to port the 3 remaining projects and work on
> >> > functional and integration tests on Python 3.
> >> >
> >> > Victor
> >>
> >> Hi Victor,
> >>
> >> Thanks a lot for your efforts on Py3.
> >>
> >> Do you think it looks like possible to have Nova ported to Py3 during
> >> the Newton cycle?
> >>
> >> Cheers,
> >>
> >> Thomas Goirand (zigo)
> >>
> >
> > I'd like for the community to set a goal for Ocata to have Python
> > 3 functional tests running for all projects.
> >
> > As Tony points out, it's a bit late to have this as a priority for
> > Newton, though work can and should continue. But given how close
> > we are to having the initial phase of the port done (thanks Victor!),
> > and how far we are from discussions of priorities for Ocata, it
> > seems very reasonable to set a community-wide goal for our next
> > release cycle.
> >
> > Thoughts?
> >
> > Doug
> >
> > __
> > 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 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] Next Ops Midcycle NYC August 25-26

[Saverio Proto]

Hello there :)

is anyone from the openstack foundation or from bloomberg that can
help out with this ?

I share this for anyone that needs visa.

for Austin we had something like this:
https://www.openstack.org/summit/austin-2016/austin-and-travel/
https://openstackfoundation.formstack.com/forms/visa_form_austin_summit

anyone that needs to apply for Visa will need a 'US point of contact
information'.

Basically, if the organizer of the Ops Midcycle is officially the
openstack foundation or bloomberg, I need to enter in my visa
application the following info:

Organization name
Address in the US
Phone number
Email

It must be a phone number and a email where in case there is a check,
somebody can tell "yes of course, this guy exist and is coming to the
conference" :)

How we sort this out ?

thank you

Saverio

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

[OpenStack-Infra] Questions when Desired Project Name and Launchpad URL does not match for a new project

[HU, BIN]

Hi,

We want to create a new StackForge project "Gluon", and we intend to use the 
repo name "openstack/gluon". But the Launchpad URL is different 
("python-gluon"). We read the details of instruction 
http://docs.openstack.org/infra/manual/creators.html, and examples in 
http://git.openstack.org/cgit, but still couldn't find the way to resolve this 
issue.


(1)I have created our Launchpad project, named "Gluon":

-  https://launchpad.net/python-gluon

o   Note that the Display Name in the Launch is "Gluon", but the URL is 
"python-gluon" according to instruction.

o   This is because someone has registered another "gluon" project in Launchpad 
and used the URL "gluon", which has nothing to do with OpenStack, and it is for 
gaming. See https://launchpad.net/gluon for another unrelated project in 
Launchpad.

-  We still intend to use "openstack/gluon" as our project/repo name, 
which is available now.


(2)I have registered package name "gluon" in PyPi, and added "openstackci" 
as owner too.

Now I am starting to add this project into OpenStack CI system. I have 3 
questions:


(1)Are those names case-sensitive?

(2)Because our Gluon project's the Launchpad URL is "python-gluon", which 
is different from our intended OpenStack project name "openstack/gluon", what 
should I do?

a.   I see an example the manual:

- project: openstack/
  description: Latest and greatest cloud stuff.
  groups:
 - oslo

So should I use "groups: -gluon" or something else to resolve 
the mismatch of "openstack/gluon" and "https://launchpad.net/python-gluon;?


(3)In https://git.openstack.org/openstack-dev/cookiecutter.json, I see:

{
"module_name": "replace with the name of the python module",
"repo_group": "openstack",
"repo_name": "replace with the name for the git repo",
"launchpad_project": "replace with the name of the project on 
launchpad",
"project_short_description": "OpenStack Boilerplate contains all the 
boilerplate you need to create an OpenStack package."
}

Note the bolded "replace with the name of the project on launchpad":

-  what does this mean?

-  Should it be changed because of project name/repo "openstack/gluon" 
and Launchpad URL "python-gluon"?

Thank you for help
Bin

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

Re: [Openstack] Volume creation

[Turbo Fredriksson]

On Jun 23, 2016, at 8:37 PM, Remo Mattei wrote:

> Once it gets attached 

Ok, thanx. That will help a little in pinpointing where I'm failing.
--
Choose a job you love, and you will never have
to work a day in your life.


___
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] Volume creation

[Remo Mattei]

Once it gets attached 

Inviato da iPhone

> Il giorno 23 giu 2016, alle ore 11:56, Turbo Fredriksson  
> ha scritto:
> 
> When a volume is created, is it supposed to be shared with
> iSCSI at the same time, or is/should that be done once an
> Instance attaches it?
> --
> Imagine you're an idiot and then imagine you're in
> the government. Oh, sorry. Now I'm repeating myself
> - Mark Twain
> 
> 
> ___
> 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
> 
> !DSPAM:1,576c341e177632027271986!
> 


___
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] [TripleO] CI package build issues

[John Trowbridge]

On 06/23/2016 02:56 PM, Dan Prince wrote:
> After discovering some regressions today we found what we think is a
> package build issue in our CI environment which might be the cause of
> our issues:
> 
> https://bugs.launchpad.net/tripleo/+bug/1595660
> 
> Specifically, there is a case where DLRN might not be giving an error
> code if build failures occur, and thus our jobs don't get the updated
> package symlink and thus give a false positive.
> 
> Until we get this solved be careful when merging. You might look for
> 'packages not built correctly: not updating the consistent symlink' in
> the job output. I see over 200 of these in the last 24 hours:
> 

I updated the bug, but will reply here for completeness. The "not
updating the consistent symlink" message appears 100% of the time when
not building all packages in rdoinfo.

Instead what happened is we built HEAD of master instead of the refspec
from zuul.

http://logs.openstack.org/17/324117/22/check-tripleo/gate-tripleo-ci-centos-7-nonha/3758449/console.html#_2016-06-23_03_40_49_234238

c48410a05ec0ffd11c717bcf350badc9e5f0e910 is the commit it should have built.

4ef338574b1a7cef8b1b884d439556b24fb09718 was built instead.

So the logstash query we could use is instead:

http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22cleaning%20directory%20and%20cloning%20again%5C%22%20AND%20filename%3A%5C%22console.html%5C%22

I think https://review.rdoproject.org/r/1500 is the fix.

__
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] Packaging Virtualenvs

[Silence Dogood]

I know from conversations that a few folks package their python apps as
distributable virtualenvs.   spotify created dh-virtualenv for this.  you
can do it pretty simply by hand.

I built a toolchain for building rpms as distributable virtualenvs and that
works really well.

What I'd like to do is make it so that every app that's built as a
virtualenv gets setup to automatically execute at call time in their
virtualenv.

I see two options:

1)  Dynamically generate a wrapper script during build and put it in the
RPM.  Call the wrapper.

2)  Created a dependency global module ( as an rpm ) set it as a
dependency.  And basically it'd be an autoexecuting import that
instantiates the virtualenv.  it would probably know all it needs to
because I am building all my packages to an internal standard.  Then when
building the APP rpm all I need to do is inject an import into the import
chain if it's being built as a virtualenv.  Then I have what are
effectively statically compiled python apps.

I like 2.  But 1 isn't very bad.  Both are a little hokey.

Was curious if folks might have a preference, or a better idea.

Thanks.

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

Re: [openstack-dev] [lbaas]HA for lbaas v2 agent

[Akshay Kumar Sanghai]

Thanks Assaf.
I have few questions for lbaas:
-  if i run agents on multiple nodes, will the request be ditrsibuted by
neutron-server?
- Does neutron lbaas agent forward the request to octavia-api or the
neutron-server?

Thanks
Akshay

On Thu, Jun 23, 2016 at 1:00 AM, Assaf Muller  wrote:

> On Wed, Jun 22, 2016 at 3:17 PM, Akshay Kumar Sanghai
>  wrote:
> > Hi,
> > I have a multinode openstack installation (3 controller, 3 network nodes,
> > and some compute nodes).
> > Like l3 agent, is high availability feature available for the lbaas v2
> > agent?
>
> It is not. Nir Magnezi is working on a couple of patches to implement
> a simplistic HA solution for LBaaS v2 with haproxy:
> https://review.openstack.org/#/c/28/
> https://review.openstack.org/#/c/327966/
>
> >
> > Thanks
> > Akshay
> >
> >
> __
> > 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

[openstack-dev] [ironic] Ironic Newton midcycle sprint summary

[Mathieu Mitchell]

Dear group,

Please enjoy this midcycle sprint summary. You might have to put your 
Markdown glasses on for proper formatting :)



The midcycle sprint lasted three days. It was virtually held over 
Infra's conference system and IRC. The event was split in two different 
time slots. The first slot, from 15:00 to 20:00 UTC, was by far the most 
popular. A lot of topics were covered by the participants. The second 
slot, from 00:00 to 04:00 UTC, was much less popular, having a whooping 
peak participant count of four.



June 20 2016 15:00 to 20:00 UTC
---

Most of the group was present for this session. Missing were Devananda 
van der Veen (devananda) and Jay Faulkner (JayF). We decided to create 
an agenda for the upcoming sessions and reserve topics of interest to 
our missing members for the days where they would be present. Also, 
Ukraine was observing a national holiday, so some of our Ukrainian 
members were absent, too.


The session started with an overview of our Newton priorities. This was 
done using the new Ironic Newton Priorities Trello board [1].


[1] https://trello.com/b/ROTxmGIc/ironic-newton-priorities


### Ironic-Neutron integration

The first topic to be covered was the Ironic-Neutron integration. At the 
time of discussing that topic, most patches needed rebasing. However, 
the group still agreed on the following game plan:


  * Merge the devstack parts ASAP
  * Split portgroups support to the end of the patch chain so they can 
merge later. (done: Vladyslav Drok (vdrok) quickly posted a new revision 
for [1] and created [2]).

  * Merge everything but portgroups in server-side Ironic
  * Merge client patches in
  * Merge "Ironic: change flat network provider to 'flat'" in nova [3]
  * Finish portgroups
  * Merge "Replace vif_portgroup_id with vif_port_id" [4] (merged 
already, thanks Dmitry)


[1] https://review.openstack.org/#/c/206244/
[2] https://review.openstack.org/#/c/332177/
[3] https://review.openstack.org/#/c/297895/
[4] https://review.openstack.org/#/c/325197/


### Security groups for Bare metal deployments

Sukhdev Singh (Sukhdev) reports that full security group support will be 
available for bare metal deployments by leveraging the Neutron integration.


> There is minor work that is needed in the Ironic driver. Most of the 
ML2 drivers already know how to deal with Security Groups. Hence, this 
becomes a slam dunk - huge reward with little work.



### Future networking work

Up for review is the spec for VLAN-aware baremetal instances [1] by Sam 
Betts (sambetts). It has received comments and a few reviews, but more 
eyes would help get this through :)


Attach and detach are becoming first class citizens [2] and will be 
defined in network drivers, allowing for different vendors to implement 
their own logic. This will also support post-boot network attach/detach. 
Also, keep an eye open for network-aware scheduling in Nova.


[1] https://review.openstack.org/#/c/277853/
[2] https://review.openstack.org/#/c/317636/


### Driver composition

Big topic that has been in progress for officially more than a year 
(first patch set is dated June 4th, 2015!). We are finally reaching 
consensus. Most people are okay with the spec, the only pain point was 
using the `driver` vs `hardware_type` field. Since hardware_type was 
introduced before dynamic driver had default interfaces, most of the 
group agreed to dropping it and simply keeping the `driver` field.


Dmitry Tantsur (dtantsur) quickly posted a few new patch sets and the 
spec [1] is currently awaiting workflow.


[1] https://review.openstack.org/#/c/188370/


### Serial console spec

Up for review is the Nova-compatible serial console support [1]. The 
group had a few questions but none of the authors were present in the room.


One interesting question was whether this should depend on the driver 
composition spec. The answer was that, given the limited scope of the 
serial console in current deployments, simply one or two new drivers 
could be added to the matrix, instead of duplicating all current 
drivers, preventing this from requiring the driver composition.


Everyone interested posted questions directly in the review for the 
authors to answer. Another point of interest was the full path to the 
socat binary, and the code behaving differently based finding "socat" in 
said string.


[1] https://review.openstack.org/#/c/319505/


June 21 2016 00:00 to 04:00 UTC
---

A small number of participants assisted the session.

An informal discussion took place and the following topics were discussed:

* Merge conflicts and their cause
* Feature enabling
* v2 API
* Multi-node devstack deployments

The session ended early at 01:20 UTC.


June 21 2016 15:00 to 20:00 UTC
---

### Versioning the ironic-python-agent API

Our first topic of the day was IPA API versioning. It was agreed that 
Ironic should work with N-1 and N+1 versions of 

[Openstack] Volume creation

[Turbo Fredriksson]

When a volume is created, is it supposed to be shared with
iSCSI at the same time, or is/should that be done once an
Instance attaches it?
--
Imagine you're an idiot and then imagine you're in
the government. Oh, sorry. Now I'm repeating myself
- Mark Twain


___
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-operators] Astara?

[Jonathan Mills]

I'm seeking user stories, experiences, feedback, etc relating to the use of
Astara for managing the overlay network in a vxlan scenario.  Was it
difficult to set up?  Was it worth your time/effort?  Are you still happy
with it, or do you prefer a different solution?  Your feedback is greatly
appreciated...
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [TripleO] CI package build issues

[Dan Prince]

After discovering some regressions today we found what we think is a
package build issue in our CI environment which might be the cause of
our issues:

https://bugs.launchpad.net/tripleo/+bug/1595660

Specifically, there is a case where DLRN might not be giving an error
code if build failures occur, and thus our jobs don't get the updated
package symlink and thus give a false positive.

Until we get this solved be careful when merging. You might look for
'packages not built correctly: not updating the consistent symlink' in
the job output. I see over 200 of these in the last 24 hours:

http://logstash.openstack.org/#dashboard/file/logstash.json?query=messa
ge%3A%5C%22not%20updating%20the%20consistent%20symlink%5C%22%20AND%20fi
lename%3A%5C%22console.html%5C%22

Dan

__
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] Openstack wt Ansible-all in one(AIO), problem accessing dashboard

[Motamary, Shabrinath]

Hai,

I have installed Openstack with Ansible- all in one version using the following.
http://docs.openstack.org/developer/openstack-ansible/developer-docs/quickstart-aio.html
Installation was successful. When I open the Openrc file in one of the 
containers for dashboard url. I found that dashboard got assigned with virtual 
IP.
How do I access dashboard?
How can I change the Virtual IP to Public IP for accessing dashboard?

Thanks in advance,
Shabari
___
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] [new][release] reno 1.8.0 release

[no-reply]

We are satisfied to announce the release of:

reno 1.8.0: RElease NOtes manager

With source available at:

http://git.openstack.org/cgit/openstack/reno

Please report issues through launchpad:

http://bugs.launchpad.net/reno

For more details, please see below.

Changes in reno 1.7.0..1.8.0


96b0641 ignore all coverage output files
2a86047 add warnings for malformated input
92ddd8f add API for writing the cache file
0c103c3 report extra files with warnings


Diffstat (except docs and test files)
-

.gitignore|  2 +-
reno/cache.py | 58 ++
reno/loader.py| 42 --
reno/scanner.py   | 11 +++---
6 files changed, 194 insertions(+), 25 deletions(-)




__
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] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[Chris Friesen]

On 06/23/2016 10:09 AM, Walter A. Boring IV wrote:


volumes connected to QEMU instances eventually become directly connected?


Our long term goal is that 100% of all network storage will be connected
to directly by QEMU. We already have the ability to partially do this with
iSCSI, but it is lacking support for multipath. As & when that gap is
addressed though, we'll stop using the host OS for any iSCSI stuff.

So if you're requiring access to host iSCSI volumes, it'll work in the
short-medium term, but in the medium-long term we're not going to use
that so plan accordingly.


What is the benefit of this largely monolithic approach?  It seems that
moving everything into QEMU is diametrically opposed to the unix model itself 
and
is just a re-implementation of what already exists in the linux world outside of
QEMU.

Does QEMU support hardware initiators? iSER?

We regularly fix issues with iSCSI attaches in the release cycles of OpenStack,
because it's all done in python using existing linux packages.  How often are 
QEMU
releases done and upgraded on customer deployments vs. python packages 
(os-brick)?

I don't see a compelling reason for re-implementing the wheel,
and it seems like a major step backwards.


This is an interesting point.

Unless there's a significant performance benefit to connecting directly from 
qemu, it seems to me that we would want to leverage the existing work done by 
the kernel and other "standard" iSCSI initators.


Chris

__
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] Status of the OpenStack port to Python 3

[Sean Dague]

So, given that everything in base iaas is over besides Nova, and there
is some python 3 support in Devstack, before Newton is over one could
get a python 3 (except Nova) job running, and start seeing the fallout
of full stack testing. We could even prioritize functional changes in
Nova to get full stack python 3 working (a lot of what is holding Nova
back is actually unit tests that aren't python 3 clean).

That seems like the next logical step, and I think would help add
incentive to full stack testing to show this actually working outside of
just isolated test suites.

On 06/23/2016 12:58 PM, Davanum Srinivas wrote:
> +1 from me as well Doug! ("community to set a goal for Ocata to have Python
> 3 functional tests running for all projects.")
> 
> -- Dims
> 
> On Thu, Jun 23, 2016 at 12:11 PM, Doug Hellmann  wrote:
>> Excerpts from Thomas Goirand's message of 2016-06-22 10:49:01 +0200:
>>> On 06/22/2016 09:18 AM, Victor Stinner wrote:
 Hi,

 Current status: only 3 projects are not ported yet to Python 3:

 * nova (76% done)
 * trove (42%)
 * swift (0%)

https://wiki.openstack.org/wiki/Python3

 Number of projects already ported:

 * 19 Oslo Libraries
 * 4 Development Tools
 * 22 OpenStack Clients
 * 6 OpenStack Libraries (os-brick, taskflow, glance_store, ...)
 * 12 OpenStack services approved by the TC
 * 17 OpenStack services (not approved by the TC)

 Raw total: 80 projects. In fact, 3 remaining projects on 83 is only 4%,
 we are so close! ;-)

 The next steps are to port the 3 remaining projects and work on
 functional and integration tests on Python 3.

 Victor
>>>
>>> Hi Victor,
>>>
>>> Thanks a lot for your efforts on Py3.
>>>
>>> Do you think it looks like possible to have Nova ported to Py3 during
>>> the Newton cycle?
>>>
>>> Cheers,
>>>
>>> Thomas Goirand (zigo)
>>>
>>
>> I'd like for the community to set a goal for Ocata to have Python
>> 3 functional tests running for all projects.
>>
>> As Tony points out, it's a bit late to have this as a priority for
>> Newton, though work can and should continue. But given how close
>> we are to having the initial phase of the port done (thanks Victor!),
>> and how far we are from discussions of priorities for Ocata, it
>> seems very reasonable to set a community-wide goal for our next
>> release cycle.
>>
>> Thoughts?
>>
>> Doug
>>
>> __
>> 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] [all] what do you work on upstream of OpenStack?

[Doug Hellmann]

Excerpts from Ihor Dvoretskyi's message of 2016-06-23 19:47:32 +0300:
> Doug, nice work, thank for collecting these items.
> 
> I'd like to suggest adding Kubernetes as one of the container projects,
> that is actively contributed by people from the OpenStack world. Within the
> Kubernetes Community we have an OpenStack Special Interest Group [0], where
> the most active members are deeply involved into OpenStack and Kubernetes
> either [1].

Thanks for pointing that out. I've updated the list.

Doug

> 
> 0. https://github.com/kubernetes/community/tree/master/sig-openstack
> 1.
> https://github.com/kubernetes/community/blob/master/sig-openstack/SIG-members.md
> 
> On Thu, Jun 23, 2016 at 7:27 PM, Anita Kuno  wrote:
> 
> > On 06/23/2016 08:37 AM, Doug Hellmann wrote:
> > > Excerpts from Doug Hellmann's message of 2016-06-13 15:11:17 -0400:
> > >> I'm trying to pull together some information about contributions
> > >> that OpenStack community members have made *upstream* of OpenStack,
> > >> via code, docs, bug reports, or anything else to dependencies that
> > >> we have.
> > >>
> > >> If you've made a contribution of that sort, I would appreciate a
> > >> quick note.  Please reply off-list, there's no need to spam everyone,
> > >> and I'll post the summary if folks want to see it.
> > >>
> > >> Thanks,
> > >> Doug
> > >>
> > >
> > > I've summarized the results of all of your responses (on and off
> > > list) on a blog post this morning [1]. I removed individual names
> > > because I was concentrating on the community as a whole, rather than
> > > individual contributions.
> > >
> > > I'm sure there are projects not listed, either because I missed
> > > something in my summary or because someone didn't reply. Please feel
> > > free to leave a comment on the post with references to other projects.
> > > It's not necessary to link to specific commits or bugs or anything like
> > > that, unless there's something you would especially like to highlight.
> > >
> > > Thank you for your input into the survey. I'm impressed with the
> > > breadth of the results. I'm very happy to know that our community,
> > > which so often seems to be focused on building new projects, also
> > > contributes to existing projects that we all rely on.
> > >
> > > Doug
> > >
> > > [1]
> > https://doughellmann.com/blog/2016/06/23/openstack-contributions-to-other-open-source-projects/
> > >
> > >
> > __
> > > 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
> > >
> >
> > Thanks for putting this together Doug that is an impressive list.
> >
> > It is interesting as I had not considered Zuul and Jenkins Job Builder
> > to be 'other open source tools' but you are correct, it is a way to look
> > at them.
> >
> > Thanks Doug,
> > Anita.
> >
> > __
> > 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] Status of the OpenStack port to Python 3

[Davanum Srinivas]

+1 from me as well Doug! ("community to set a goal for Ocata to have Python
3 functional tests running for all projects.")

-- Dims

On Thu, Jun 23, 2016 at 12:11 PM, Doug Hellmann  wrote:
> Excerpts from Thomas Goirand's message of 2016-06-22 10:49:01 +0200:
>> On 06/22/2016 09:18 AM, Victor Stinner wrote:
>> > Hi,
>> >
>> > Current status: only 3 projects are not ported yet to Python 3:
>> >
>> > * nova (76% done)
>> > * trove (42%)
>> > * swift (0%)
>> >
>> >https://wiki.openstack.org/wiki/Python3
>> >
>> > Number of projects already ported:
>> >
>> > * 19 Oslo Libraries
>> > * 4 Development Tools
>> > * 22 OpenStack Clients
>> > * 6 OpenStack Libraries (os-brick, taskflow, glance_store, ...)
>> > * 12 OpenStack services approved by the TC
>> > * 17 OpenStack services (not approved by the TC)
>> >
>> > Raw total: 80 projects. In fact, 3 remaining projects on 83 is only 4%,
>> > we are so close! ;-)
>> >
>> > The next steps are to port the 3 remaining projects and work on
>> > functional and integration tests on Python 3.
>> >
>> > Victor
>>
>> Hi Victor,
>>
>> Thanks a lot for your efforts on Py3.
>>
>> Do you think it looks like possible to have Nova ported to Py3 during
>> the Newton cycle?
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>
> I'd like for the community to set a goal for Ocata to have Python
> 3 functional tests running for all projects.
>
> As Tony points out, it's a bit late to have this as a priority for
> Newton, though work can and should continue. But given how close
> we are to having the initial phase of the port done (thanks Victor!),
> and how far we are from discussions of priorities for Ocata, it
> seems very reasonable to set a community-wide goal for our next
> release cycle.
>
> Thoughts?
>
> Doug
>
> __
> 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

Re: [openstack-dev] [all] Status of the OpenStack port to Python 3

[Monty Taylor]

On 06/23/2016 11:11 AM, Doug Hellmann wrote:
> Excerpts from Thomas Goirand's message of 2016-06-22 10:49:01 +0200:
>> On 06/22/2016 09:18 AM, Victor Stinner wrote:
>>> Hi,
>>>
>>> Current status: only 3 projects are not ported yet to Python 3:
>>>
>>> * nova (76% done)
>>> * trove (42%)
>>> * swift (0%)
>>>
>>>https://wiki.openstack.org/wiki/Python3
>>>
>>> Number of projects already ported:
>>>
>>> * 19 Oslo Libraries
>>> * 4 Development Tools
>>> * 22 OpenStack Clients
>>> * 6 OpenStack Libraries (os-brick, taskflow, glance_store, ...)
>>> * 12 OpenStack services approved by the TC
>>> * 17 OpenStack services (not approved by the TC)
>>>
>>> Raw total: 80 projects. In fact, 3 remaining projects on 83 is only 4%,
>>> we are so close! ;-)
>>>
>>> The next steps are to port the 3 remaining projects and work on
>>> functional and integration tests on Python 3.
>>>
>>> Victor
>>
>> Hi Victor,
>>
>> Thanks a lot for your efforts on Py3.
>>
>> Do you think it looks like possible to have Nova ported to Py3 during
>> the Newton cycle?
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
> 
> I'd like for the community to set a goal for Ocata to have Python
> 3 functional tests running for all projects.
> 
> As Tony points out, it's a bit late to have this as a priority for
> Newton, though work can and should continue. But given how close
> we are to having the initial phase of the port done (thanks Victor!),
> and how far we are from discussions of priorities for Ocata, it
> seems very reasonable to set a community-wide goal for our next
> release cycle.

++


__
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] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[Preston L. Bannister]

Daniel, Thanks. Looking for a sense of direction.

Clearly there is some range of opinion, as Walter indicates. :)

Not sure you are get to 100% direct connection to QEMU. When there is
dedicated hardware to do off-board processing of the connection to storage,
you might(?) be stuck routing through the nova-compute host Linux. (I am
not an expert in this area, so I could easily be wrong.) This sort of
hardware tends to be associated with higher-end "enterprise" storage and
hosts (and higher cost). The storage guys are in the habit of calling these
"HBA adaptors" (for high-bandwidth) - might just be a local thing.

I *suspect* that higher cost will drive most cloud deployments away from
that sort of specialized hardware. In which case the direct-connect to QEMU
model should (mostly?) work. (My non-expert guess.)



On Thu, Jun 23, 2016 at 9:09 AM, Walter A. Boring IV 
wrote:

>
> volumes connected to QEMU instances eventually become directly connected?
>
> Our long term goal is that 100% of all network storage will be connected
>> to directly by QEMU. We already have the ability to partially do this with
>> iSCSI, but it is lacking support for multipath. As & when that gap is
>> addressed though, we'll stop using the host OS for any iSCSI stuff.
>>
>> So if you're requiring access to host iSCSI volumes, it'll work in the
>> short-medium term, but in the medium-long term we're not going to use
>> that so plan accordingly.
>>
>
> What is the benefit of this largely monolithic approach?  It seems that
> moving everything into QEMU is diametrically opposed to the unix model
> itself and
> is just a re-implementation of what already exists in the linux world
> outside of QEMU.
>
> Does QEMU support hardware initiators? iSER?
>
> We regularly fix issues with iSCSI attaches in the release cycles of
> OpenStack,
> because it's all done in python using existing linux packages.  How often
> are QEMU
> releases done and upgraded on customer deployments vs. python packages
> (os-brick)?
>
> I don't see a compelling reason for re-implementing the wheel,
> and it seems like a major step backwards.
>
>
>> Xiao's unanswered query (below) presents another question. Is this a
>>> site-choice? Could I require my customers to configure their OpenStack
>>> clouds to always route iSCSI connections through the nova-compute host?
>>> (I
>>> am not a fan of this approach, but I have to ask.)
>>>
>>

> In the short term that'll work, but long term we're not intending to
>> support that once QEMU gains multi-path. There's no timeframe on when
>> that will happen though.
>>
>>
>> Regards,
>> Daniel
>>
>
__
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] [nova] Placement API WSGI code -- let's just use flask

[Sean M. Collins]

Sean Dague wrote:
> If we look at the iaas base layer:
> 
> Keystone - custom WSGI with Routes / Paste
> Glance - WSME + Routes / Paste
> Cinder - custom WSGI with Routes / Paste
> Neutron - pecan + Routes / Paste
> Nova - custom WSGI with Routes / Paste

Neutron's pecan code is still fairly new. Deployments still use the old
code[1]. So, I don't know if Neutron is quite there yet on the pecan
front. :(
 
[1]: 
https://github.com/openstack/neutron/blob/b59bb0fcfa41963c0e2f7bcbf34b7e4f4ff5cd08/neutron/common/config.py#L174

-- 
Sean M. Collins

__
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] what do you work on upstream of OpenStack?

[Ihor Dvoretskyi]

Doug, nice work, thank for collecting these items.

I'd like to suggest adding Kubernetes as one of the container projects,
that is actively contributed by people from the OpenStack world. Within the
Kubernetes Community we have an OpenStack Special Interest Group [0], where
the most active members are deeply involved into OpenStack and Kubernetes
either [1].

0. https://github.com/kubernetes/community/tree/master/sig-openstack
1.
https://github.com/kubernetes/community/blob/master/sig-openstack/SIG-members.md


On Thu, Jun 23, 2016 at 7:27 PM, Anita Kuno  wrote:

> On 06/23/2016 08:37 AM, Doug Hellmann wrote:
> > Excerpts from Doug Hellmann's message of 2016-06-13 15:11:17 -0400:
> >> I'm trying to pull together some information about contributions
> >> that OpenStack community members have made *upstream* of OpenStack,
> >> via code, docs, bug reports, or anything else to dependencies that
> >> we have.
> >>
> >> If you've made a contribution of that sort, I would appreciate a
> >> quick note.  Please reply off-list, there's no need to spam everyone,
> >> and I'll post the summary if folks want to see it.
> >>
> >> Thanks,
> >> Doug
> >>
> >
> > I've summarized the results of all of your responses (on and off
> > list) on a blog post this morning [1]. I removed individual names
> > because I was concentrating on the community as a whole, rather than
> > individual contributions.
> >
> > I'm sure there are projects not listed, either because I missed
> > something in my summary or because someone didn't reply. Please feel
> > free to leave a comment on the post with references to other projects.
> > It's not necessary to link to specific commits or bugs or anything like
> > that, unless there's something you would especially like to highlight.
> >
> > Thank you for your input into the survey. I'm impressed with the
> > breadth of the results. I'm very happy to know that our community,
> > which so often seems to be focused on building new projects, also
> > contributes to existing projects that we all rely on.
> >
> > Doug
> >
> > [1]
> https://doughellmann.com/blog/2016/06/23/openstack-contributions-to-other-open-source-projects/
> >
> >
> __
> > 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
> >
>
> Thanks for putting this together Doug that is an impressive list.
>
> It is interesting as I had not considered Zuul and Jenkins Job Builder
> to be 'other open source tools' but you are correct, it is a way to look
> at them.
>
> Thanks Doug,
> Anita.
>
> __
> 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
>



-- 
Best regards,

Ihor Dvoretskyi
__
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] Create instance fails on creating block device - Block Device Mapping is Invalid

[Turbo Fredriksson]

On Jun 23, 2016, at 4:30 PM, Eugen Block wrote:

> They are running because you didn't stop the services, you just disabled them.

I kind'a expected a disable to stop the service.. But what if I wanted to
stop only ONE service (of several)? For example the "nfs" backend but leave
the "lvm" online. I can't shutdown cinder-volume, that would stop all of them..

> You could stop them for now if you don't intend using cinder until you get an 
> instance up and running, but I would take care of cinder after that. It 
> doesn't affect you if you while trying to boot an instance on local storage 
> because cinder is not required for that.

Well. I can create Cinder volumes without any problems it seems:

bladeA01b:~# openstack volume list
+--+--+---+--+-+
| ID   | Display Name | Status| Size | 
Attached to |
+--+--+---+--+-+
| 0a0929e6-cf4d-40b3-9ba3-9575290993e6 | test2| available |5 |  
   |
| c16975ad-dd45-41d7-b0a9-cbd0849f80e4 | test | available |5 |  
   |
+--+--+---+--+-+
bladeA01b:~# openstack volume show test | grep host
| os-vol-host-attr:host  | bladeA01b@lvm#LVM_iSCSI
bladeA01b:~# openstack volume show test2 | grep host
| os-vol-host-attr:host  | bladeA01b@nfs#nfsbackend

> From your latest logs I assume that you are still trying to boot from volume, 
> I recommend to ignore cinder for now and focus on launching an instance at 
> all.

That doesn't seem to be possible. I've looked over some of the code for
Cinder, and if you don't configure "enabled_backends", then no volume
can be created. Well, they can be created, but they end up in Error state
right away!

> Have you fixed your glance issue?

I don't know. I don't know what's wrong with it :(


But I touch one thing and two other things break :( :( :(. Dang, dang, dang,
I'm getting really tired of this s**t!

- s n i p -
2016-06-23 17:00:21.511 18347 INFO cinder.api.openstack.wsgi 
[req-35b7eb35-997c-4149-a975-aba921d86182 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] HTTP exception thrown: Volume test2 
could not be found.
2016-06-23 17:00:21.513 18347 INFO cinder.api.openstack.wsgi 
[req-35b7eb35-997c-4149-a975-aba921d86182 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] 
http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/test2 returned 
with HTTP 404
2016-06-23 17:00:21.514 18347 INFO eventlet.wsgi.server 
[req-35b7eb35-997c-4149-a975-aba921d86182 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] 10.0.4.1 "GET 
/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/test2 HTTP/1.1" status: 404  len: 
419 time: 0.6278081
2016-06-23 17:00:21.524 18347 INFO cinder.api.openstack.wsgi 
[req-a37ee53f-6910-4411-8260-dd615a722318 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] GET 
http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/detail?all_tenants=1=test2
2016-06-23 17:00:21.600 18347 INFO cinder.volume.api 
[req-a37ee53f-6910-4411-8260-dd615a722318 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] Get all volumes completed successfully.
2016-06-23 17:00:21.609 18347 INFO cinder.api.openstack.wsgi 
[req-a37ee53f-6910-4411-8260-dd615a722318 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] 
http://10.0.4.1:8776/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/detail?all_tenants=1=test2
 returned with HTTP 200
2016-06-23 17:00:21.611 18347 INFO eventlet.wsgi.server 
[req-a37ee53f-6910-4411-8260-dd615a722318 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] 10.0.4.1 "GET 
/v2/2985b96e27f048cd92a18db0dd03aa23/volumes/detail?all_tenants=1=test2 
HTTP/1.1" status: 200  len: 1607 time: 0.0912130
- s n i p -

And yet it's right there! See top of email.
--
Att inse sin egen betydelse är som att få ett kvalster att
fatta att han bara syns i mikroskop
- Arne Anka


___
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] [all] what do you work on upstream of OpenStack?

[Anita Kuno]

On 06/23/2016 08:37 AM, Doug Hellmann wrote:
> Excerpts from Doug Hellmann's message of 2016-06-13 15:11:17 -0400:
>> I'm trying to pull together some information about contributions
>> that OpenStack community members have made *upstream* of OpenStack,
>> via code, docs, bug reports, or anything else to dependencies that
>> we have.
>>
>> If you've made a contribution of that sort, I would appreciate a
>> quick note.  Please reply off-list, there's no need to spam everyone,
>> and I'll post the summary if folks want to see it.
>>
>> Thanks,
>> Doug
>>
> 
> I've summarized the results of all of your responses (on and off
> list) on a blog post this morning [1]. I removed individual names
> because I was concentrating on the community as a whole, rather than
> individual contributions.
> 
> I'm sure there are projects not listed, either because I missed
> something in my summary or because someone didn't reply. Please feel
> free to leave a comment on the post with references to other projects.
> It's not necessary to link to specific commits or bugs or anything like
> that, unless there's something you would especially like to highlight.
> 
> Thank you for your input into the survey. I'm impressed with the
> breadth of the results. I'm very happy to know that our community,
> which so often seems to be focused on building new projects, also
> contributes to existing projects that we all rely on.
> 
> Doug
> 
> [1] 
> https://doughellmann.com/blog/2016/06/23/openstack-contributions-to-other-open-source-projects/
> 
> __
> 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
> 

Thanks for putting this together Doug that is an impressive list.

It is interesting as I had not considered Zuul and Jenkins Job Builder
to be 'other open source tools' but you are correct, it is a way to look
at them.

Thanks Doug,
Anita.

__
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] packets not reaching VM

[Brian Haley]

On 06/23/2016 03:23 AM, Priyanka wrote:

Hi,

We want direct routing LB and LVS supports it. So we were trying that option.
Can we add some rule in neutron-openvswi chain of the LB VM on compute node to
prevent the drop of these packets? If yes please guide us on how can we
configure such a rule. As i can see a drop rule in the chain which drops
anything other than packet with IP and MAC of the LB VM. But our packet has a
different IP. The rule addition would be required at the backend server VM
neutron-openvswi chain as well?


Doing it on your own is fine, but do know that there's only so much support we 
can give when you're not using the built-in tools that already exist.  Luckily 
you have all the Neutron source code, especially since you're running an 
unsupported release like Juno.


Here are two things you can look at:

1) Allowed address pairs

2) Remove the port security feature on certain ports:

2a) remove the security group from the port
2b) neutron port-update $port --port-security-enabled=False

Typically you'd create the port first, then pass it along during the nova boot 
phase, but you should be able to update it afterwards.


-Brian


On Wednesday 22 June 2016 08:16 PM, Brian Haley wrote:

On 06/22/2016 03:42 AM, Priyanka wrote:

Hi,

We have a Openstack Juno setup with 1 controller+neutron node and 3 compute
nodes. 1 VM (LB) has ipvsadm installed and two VMs act as back end server.

On the server with ipvsadm I have eth0:0 IP as 192.168.1.21 which acts as
application IP. The ipvsadm uses round robin scheme. This is done using commands
as below:

sudo ipvsadm -A -t 192.168.1.21:6000 -s rr
sudo ipvsadm -a -t 192.168.1.21:6000 -r 192.168.1.77:6000 -g
sudo ipvsadm -a -t 192.168.1.21:6000 -r 192.168.1.79:6000 -g

where 192.168.1.77 and 192.168.1.79 are back end server VM IP.

The problem is that the packets go out of the LB VM but never reach the back end
server.


You had asked a similar question last week, and I had asked why you just
weren't using Neutron LBaaS to do this?  Seems you are trying to implement
your own load-balancer inside a tenant VM.

Also, Juno is very old, using a newer release would give you access to Octavia
(LBaaS v2) that has more advanced features.


In the tcpdumps on various interfaces show that the packet reach till qbr of the
LB VM but donot reach the qvo interface of LB VM. Are there any rules that get
applied here which block these packets. The packets from the client VM are sent
to back end server by the LB VM by changing the destination MAC of the packets.
  The packets that leave LB VM to reach back end VM have source as the client VM
IP and destination IP as 192.168.1.21 (application IP) and the src MAC of LB VM
and dst MAC of backend server VM. Is this the reason for the packets to be
blocked. Is there any way to allow these packets to flow to the back end server?


There are anti-spoofing rules installed that are most likely causing the
packets to get dropped.

-Brian





___
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] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[Walter A. Boring IV]

volumes connected to QEMU instances eventually become directly connected?


Our long term goal is that 100% of all network storage will be connected
to directly by QEMU. We already have the ability to partially do this with
iSCSI, but it is lacking support for multipath. As & when that gap is
addressed though, we'll stop using the host OS for any iSCSI stuff.

So if you're requiring access to host iSCSI volumes, it'll work in the
short-medium term, but in the medium-long term we're not going to use
that so plan accordingly.


What is the benefit of this largely monolithic approach?  It seems that
moving everything into QEMU is diametrically opposed to the unix model 
itself and
is just a re-implementation of what already exists in the linux world 
outside of QEMU.


Does QEMU support hardware initiators? iSER?

We regularly fix issues with iSCSI attaches in the release cycles of 
OpenStack,
because it's all done in python using existing linux packages.  How 
often are QEMU
releases done and upgraded on customer deployments vs. python packages 
(os-brick)?


I don't see a compelling reason for re-implementing the wheel,
and it seems like a major step backwards.




Xiao's unanswered query (below) presents another question. Is this a
site-choice? Could I require my customers to configure their OpenStack
clouds to always route iSCSI connections through the nova-compute host? (I
am not a fan of this approach, but I have to ask.)

In the short term that'll work, but long term we're not intending to
support that once QEMU gains multi-path. There's no timeframe on when
that will happen though.



Regards,
Daniel



__
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] Status of the OpenStack port to Python 3

[Doug Hellmann]

Excerpts from Thomas Goirand's message of 2016-06-22 10:49:01 +0200:
> On 06/22/2016 09:18 AM, Victor Stinner wrote:
> > Hi,
> > 
> > Current status: only 3 projects are not ported yet to Python 3:
> > 
> > * nova (76% done)
> > * trove (42%)
> > * swift (0%)
> > 
> >https://wiki.openstack.org/wiki/Python3
> > 
> > Number of projects already ported:
> > 
> > * 19 Oslo Libraries
> > * 4 Development Tools
> > * 22 OpenStack Clients
> > * 6 OpenStack Libraries (os-brick, taskflow, glance_store, ...)
> > * 12 OpenStack services approved by the TC
> > * 17 OpenStack services (not approved by the TC)
> > 
> > Raw total: 80 projects. In fact, 3 remaining projects on 83 is only 4%,
> > we are so close! ;-)
> > 
> > The next steps are to port the 3 remaining projects and work on
> > functional and integration tests on Python 3.
> > 
> > Victor
> 
> Hi Victor,
> 
> Thanks a lot for your efforts on Py3.
> 
> Do you think it looks like possible to have Nova ported to Py3 during
> the Newton cycle?
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

I'd like for the community to set a goal for Ocata to have Python
3 functional tests running for all projects.

As Tony points out, it's a bit late to have this as a priority for
Newton, though work can and should continue. But given how close
we are to having the initial phase of the port done (thanks Victor!),
and how far we are from discussions of priorities for Ocata, it
seems very reasonable to set a community-wide goal for our next
release cycle.

Thoughts?

Doug

__
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 Neutron lbaas question

[Doug Wiegley]

Hi,

LBaaS is installed automatically if neutron is present. Then you just need to 
install a driver and get everything configured.  I’d start here:

http://docs.openstack.org/liberty/networking-guide/adv-config-lbaas.html 


Thanks,
doug


> On Jun 23, 2016, at 9:33 AM, zhihao wang  wrote:
> 
> 
> Dear Openstack Team:
> 
> I have some questions regarding to openstack Mitaka Neutron lbaas 
> 
> For Neutron-lbaas installation, should I just follow this LINK
> 
> https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun 
> 
> 
> but my openstack has controller and compute nodes. is not installed by 
> Devstack, it is manually installed on production environment (one controller 
> and a few computed nodes)
>  
> Can I install Neutron-lbaas on production environment , if I can, then what 
> is the document guide?
> Thanks
> wally
> 
> __
> 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] [openstack-dev][ansible] Fail to install Openstack all in one

[Alioune]

Hi all,

I'm trying to install OpenStack all in one using ansible but I got the
error bellow.
Someone knows how to solve this error?

Regards,

ERROR:
+ openstack-ansible --forks 1 openstack-hosts-setup.yml
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e
@/etc/openstack_deploy/user_variables.yml "
ERROR: Inventory script (inventory/dynamic_inventory.py) had an execution
error: No user config loadaed
No openstack_user_config files are available in either the base location or
the conf.d directory

+ (( RETRY++ ))
+ (( 1 != 0 && RETRY < MAX_RETRIES ))
+ '[' 1 -gt 1 ']'
+ openstack-ansible --forks 1 openstack-hosts-setup.yml
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e
@/etc/openstack_deploy/user_variables.yml "
ERROR: Inventory script (inventory/dynamic_inventory.py) had an execution
error: No user config loadaed
No openstack_user_config files are available in either the base location or
the conf.d directory

+ (( RETRY++ ))
+ (( 1 != 0 && RETRY < MAX_RETRIES ))
+ '[' 2 -gt 1 ']'
+ openstack-ansible --forks 1 openstack-hosts-setup.yml -
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e
@/etc/openstack_deploy/user_variables.yml "
ERROR: Inventory script (inventory/dynamic_inventory.py) had an execution
error: No user config loadaed
No openstack_user_config files are available in either the base location or
the conf.d directory

+ (( RETRY++ ))
+ (( 1 != 0 && RETRY < MAX_RETRIES ))
+ '[' 3 -gt 1 ']'
+ openstack-ansible --forks 1 openstack-hosts-setup.yml -
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e
@/etc/openstack_deploy/user_variables.yml "
ERROR: Inventory script (inventory/dynamic_inventory.py) had an execution
error: No user config loadaed
No openstack_user_config files are available in either the base location or
the conf.d directory
___
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] Create instance fails on creating block device - Block Device Mapping is Invalid

[Yngvi Páll Þorfinnsson]

I think it's possible we're far away from the correct path ;-)
It's not mentioned at all in the openstack lbaas V2 documentation, 
but I think it's necessary to install Octavia on the controller machine first.
Then configure neutron on all compute nodes to support lbaas ...
Someone please correct me, if I'm wrong on this

Cheers 
Yngvi

-Original Message-
From: Turbo Fredriksson [mailto:tu...@bayour.com] 
Sent: 23. júní 2016 13:36
To: openstack@lists.openstack.org
Subject: Re: [Openstack] Create instance fails on creating block device - Block 
Device Mapping is Invalid

On Jun 23, 2016, at 2:10 PM, Turbo Fredriksson wrote:

> But even after disabling them, they're still show as 
> "status=disabled,state=up"
> with a "cinder service-list".. ?

I tried anyway, but creating a volume (empty or from an image) gave the host 
field as empty. And the status was Error!

So apparently I need to figure out a way to configure "local storage".


The LVM volume shows:

- s n i p -
bladeA01b:~# openstack volume show test | grep host
| os-vol-host-attr:host | bladeA01b@lvm#LVM_iSCSI |
- s n i p -
--
Build a man a fire, and he will be warm for the night.
Set a man on fire and he will be warm for the rest of his life.


___
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] Openstack Neutron lbaas question

[zhihao wang]

Dear Openstack Team:
I have some questions regarding to openstack Mitaka Neutron lbaas 
For Neutron-lbaas installation, should I just follow this 
LINKhttps://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRunbut my openstack has 
controller and compute nodes. is not installed by Devstack, it is manually 
installed on production environment (one controller and a few computed nodes) 
Can I install Neutron-lbaas on production environment , if I can, then what is 
the document guide?Thankswally   

  ___
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] [ansible] Fail to install Openstack all in one

[Alioune]

Hi all,

I'm trying to install OpenStack all in one using ansible but I got the
error bellow.
Someone knows how to solve this error?

Regards,

ERROR:
+ openstack-ansible --forks 1 openstack-hosts-setup.yml
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e
@/etc/openstack_deploy/user_variables.yml "
ERROR: Inventory script (inventory/dynamic_inventory.py) had an execution
error: No user config loadaed
No openstack_user_config files are available in either the base location or
the conf.d directory

+ (( RETRY++ ))
+ (( 1 != 0 && RETRY < MAX_RETRIES ))
+ '[' 1 -gt 1 ']'
+ openstack-ansible --forks 1 openstack-hosts-setup.yml
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e
@/etc/openstack_deploy/user_variables.yml "
ERROR: Inventory script (inventory/dynamic_inventory.py) had an execution
error: No user config loadaed
No openstack_user_config files are available in either the base location or
the conf.d directory

+ (( RETRY++ ))
+ (( 1 != 0 && RETRY < MAX_RETRIES ))
+ '[' 2 -gt 1 ']'
+ openstack-ansible --forks 1 openstack-hosts-setup.yml -
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e
@/etc/openstack_deploy/user_variables.yml "
ERROR: Inventory script (inventory/dynamic_inventory.py) had an execution
error: No user config loadaed
No openstack_user_config files are available in either the base location or
the conf.d directory

+ (( RETRY++ ))
+ (( 1 != 0 && RETRY < MAX_RETRIES ))
+ '[' 3 -gt 1 ']'
+ openstack-ansible --forks 1 openstack-hosts-setup.yml -
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e
@/etc/openstack_deploy/user_variables.yml "
ERROR: Inventory script (inventory/dynamic_inventory.py) had an execution
error: No user config loadaed
No openstack_user_config files are available in either the base location or
the conf.d directory
__
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] How do you handle purge of database tables ?

[Edgar Magana]

I would encourage you to use that repo and if there is something worth to be 
added updated, please do! All suggestions are welcome.

Edgar

From: Tim Bell 
Date: Wednesday, June 22, 2016 at 10:53 PM
To: Abel Lopez , Gilles Mocellin 

Cc: "OpenStack-operators@lists.openstack.org" 

Subject: Re: [Openstack-operators] How do you handle purge of database tables ?

There are also some tools in the OSOps repository (Nova for example has 
https://github.com/openstack/osops-tools-generic/tree/master/nova)

Tim

From: Abel Lopez 
Date: Thursday 23 June 2016 at 00:03
To: Gilles Mocellin 
Cc: openstack-operators 
Subject: Re: [Openstack-operators] How do you handle purge of database tables ?

Some projects (e.g. cinder) have tools..
`cinder-manage db-purge` or maybe it's "db purge" or something along those 
lines...
It was around Kilo when that got added.

Otherwise, in the past, I've done
mysql backup, then a massive table by table purge of "deleted=1" rows.

On Wed, Jun 22, 2016 at 2:39 PM, Gilles Mocellin 
> wrote:
Le 22/06/2016 à 23:26, Gilles Mocellin a écrit :
Hello,

While digging in nova's database, I found that many objects ar not really 
deleted, but instead just marked deleted.
In fact, it's a general behavior in other projects (cinder, glance...).

I understand that. It can be handy.

But, is there a way to handle regular purging of theses elements inside 
OpenStack configuration ?

Or do we, operators, have to create batchs to purge all that ?

I've found some blueprints indicating that there nothing for now, inside 
OpenStack :

https://blueprints.launchpad.net/nova/+spec/purge-deleted-instances-cmd
https://blueprints.launchpad.net/cinder/+spec/database-purge
https://blueprints.launchpad.net/glance/+spec/database-purge



___
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

[openstack-dev] Openstack Neutron lbaas question

[zhihao wang]

Dear Openstack Team:
I have some questions regarding to openstack Mitaka Neutron lbaas 
For Neutron-lbaas installation, should I just follow this 
LINKhttps://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRunbut my openstack has 
controller and compute nodes. is not installed by Devstack, it is manually 
installed on production environment (one controller and a few computed nodes) 
Can I install Neutron-lbaas on production environment , if I can, then what is 
the document guide?Thankswally   

  __
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] Create instance fails on creating block device - Block Device Mapping is Invalid

[Eugen Block]

"rbd"?


It's a different storage backend, something like a network RAID. But  
don't mind it right now ;-)


But even after disabling them, they're still show as  
"status=disabled,state=up"


They are running because you didn't stop the services, you just  
disabled them. You could stop them for now if you don't intend using  
cinder until you get an instance up and running, but I would take care  
of cinder after that. It doesn't affect you if you while trying to  
boot an instance on local storage because cinder is not required for  
that.


From your latest logs I assume that you are still trying to boot from  
volume, I recommend to ignore cinder for now and focus on launching an  
instance at all. Have you fixed your glance issue? Because that is  
required, otherwise it won't work at all.



Zitat von Turbo Fredriksson :


On Jun 23, 2016, at 12:26 PM, Eugen Block wrote:

/etc/cinder/cinder.conf:enabled_backends = rbd--> that's what I  
use currently


"rbd"?

I'm not sure if it would work, it's been a while since I used local  
storage, but if you just comment the enabled_backend option out and  
restart cinder services, I believe it would create local volumes.


Shouldn't it be enough just to "disable" those services/backends?

I guess I have to, because just commenting that out didn't help, they still
show as enabled and running.

But even after disabling them, they're still show as  
"status=disabled,state=up"

with a "cinder service-list".. ?

Ok, that's different! I'm not running Glance on my Compute, only  
on my Control.


Glance is not supposed to run on a compute node, it runs on a control node.


Ok, good! I thought I missed something fundamental.


What's the output of "openstack endpoint list | grep glance"?


| 57b10556b7bf47eaa019c603a0f6b34f | europe-london | glance | image  
| True | public   | http://10.0.4.1:9292
| 8672f6de1673470d93ab6ccee1c1a2bb | europe-london | glance | image  
| True | internal | http://10.0.4.1:9292
| e45c3e83fe744e7db949cdd89dfe5654 | europe-london | glance | image  
| True | admin| http://10.0.4.1:9292


That's the Control node..


[waited a little while]


How long did you wait?


10-15 seconds perhaps. At least less than (half?) a minute..

 "This section describes how to install and configure the Image  
service, code-named glance, on the controller node."


It is not obvious from that that that (!! :) should only be done on the
Controller! It just say "do this on the controller". It does not make it
clear that you shouldn't do something on the compute as well.

"This section describes how to install and configure the Compute  
service, code-named nova, on the controller node."
"This section describes how to install and configure the Compute  
service on a compute node."


Neither of which distinguish the different parts - what if I
have/want a separate compute and control node? It does not
make things obvious!


And that's why I have a problem with HOWTOs! They _assume_ to much.
And a _BAD_ HOWTO (which all of them on Openstack are!) doesn't even
attempt to explain the different options you have, so if you deviate
even the very slightest, you're f**ked!

There's a _HUMONGOS_ difference between a "HOWTO" and "Documentation"!

Timeout problem? Make sure that nothing blocks the requests  
(proxy?), what response do you get if you execute

control1:~ # curl http://:9292


I was doing that ON the Control. Worked just fine.

And The Control and Compute is on the same switch.
--
Det är när man känner doften av sin egen avföring
som man börjar undra vem man egentligen är.
- Arne Anka


___
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




--
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

Vorsitzende des Aufsichtsrates: Angelika Mozdzen
  Sitz und Registergericht: Hamburg, HRB 90934
  Vorstand: Jens-U. Mozdzen
   USt-IdNr. DE 814 013 983


___
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] How do you handle purge of database tables ?

[Belmiro Moreira]

Hi,
we wrote this blog post a year ago but it still can be useful depending on
the
OpenStack version that you are running.

http://openstack-in-production.blogspot.ch/2015/05/purging-nova-databases-in-cell.html

Belmiro

On Thu, Jun 23, 2016 at 3:32 PM, Nick Jones 
wrote:

> > On Thu, 2016-06-23 at 09:55 +0100, Nick Jones wrote:
> >> Another vote of confidence for the script that Tim has mentioned with
> >> regards to clearing down Nova’s DB.  I blogged a bit about the process
> >> and the results here:
> >>
> >>
> >> http://dischord.org/2015/12/30/archiving-data-in-nova-s-database/
> >>
> >> —
> >
> >>
> >
> > In Nova, there's 'nova-manage db archive_deleted_rows' - is that the one
> > referred to in the blog post above that broke?
>
> That’s the one.
>
> —
>
> -Nick
> --
> DataCentred Limited registered in England and Wales no. 05611763
>
> ___
> 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] Create instance fails on creating block device - Block Device Mapping is Invalid

[Turbo Fredriksson]

I'm starting to think that it might have something to do with the
networking after all:

- s n i p -
2016-06-23 15:52:13.775 25419 DEBUG nova.compute.manager 
[req-87a08e39-96ac-4c23-96dd-5227c972b865 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd
03aa23 - - -] [instance: d75bd127-c554-4d79-bb9e-157c752628f4] Instance 
network_info: |[VIF({'profile': {}, 'ovs_interfaceid': 
u'9c23c0b8-1e96-4e73-b048-55c73
80b2425', 'preserve_on_delete': False, 'network': Network({'bridge': 
'br-provider', 'subnets': [Subnet({'ips': [FixedIP({'meta': {}, 'version': 4, 
'type': 'fi
xed', 'floating_ips': [], 'address': u'10.99.0.4'})], 'version': 4, 'meta': 
{'dhcp_server': u'10.99.0.2'}, 'dns': [IP({'meta': {}, 'version': 4, 'type': 
'dns'
, 'address': u'10.0.0.254'})], 'routes': [], 'cidr': u'10.99.0.0/24', 
'gateway': IP({'meta': {}, 'version': 4, 'type': 'gateway', 'address': 
u'10.99.0.1'})})]
, 'meta': {'injected': False, 'tenant_id': u'2985b96e27f048cd92a18db0dd03aa23', 
'mtu': 1458}, 'id': u'2bb7b8e2-188f-4e46-bf4d-ef5ec81ddb4d', 'label': u'networ
k-99'}), 'devname': u'tap9c23c0b8-1e', 'vnic_type': u'normal', 'qbh_params': 
None, 'meta': {}, 'details': {u'port_filter': True, u'ovs_hybrid_plug': True}, 
'a
ddress': u'fa:16:3e:4c:04:17', 'active': False, 'type': u'ovs', 'id': 
u'9c23c0b8-1e96-4e73-b048-55c7380b2425', 'qbg_params': None})]| 
_allocate_network_async
/usr/lib/python2.7/dist-packages/nova/compute/manager.py:1572
2016-06-23 15:52:13.776 25419 DEBUG nova.compute.claims 
[req-87a08e39-96ac-4c23-96dd-5227c972b865 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd0
3aa23 - - -] [instance: d75bd127-c554-4d79-bb9e-157c752628f4] Aborting claim: 
[Claim: 1024 MB memory, 5 GB disk] abort /usr/lib/python2.7/dist-packages/nova/c
ompute/claims.py:120
2016-06-23 15:52:13.777 25419 DEBUG oslo_concurrency.lockutils 
[req-87a08e39-96ac-4c23-96dd-5227c972b865 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a1
8db0dd03aa23 - - -] Lock "compute_resources" acquired by 
"nova.compute.resource_tracker.abort_instance_claim" :: waited 0.000s inner 
/usr/lib/python2.7/dist-p
ackages/oslo_concurrency/lockutils.py:273
2016-06-23 15:52:14.017 25419 DEBUG oslo_concurrency.lockutils 
[req-87a08e39-96ac-4c23-96dd-5227c972b865 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a1
8db0dd03aa23 - - -] Lock "compute_resources" released by 
"nova.compute.resource_tracker.abort_instance_claim" :: held 0.240s inner 
/usr/lib/python2.7/dist-pac
kages/oslo_concurrency/lockutils.py:285
2016-06-23 15:52:14.018 25419 DEBUG nova.compute.manager 
[req-87a08e39-96ac-4c23-96dd-5227c972b865 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd
03aa23 - - -] [instance: d75bd127-c554-4d79-bb9e-157c752628f4] Build of 
instance d75bd127-c554-4d79-bb9e-157c752628f4 aborted: Block Device Mapping is 
Invalid
. _build_and_run_instance 
/usr/lib/python2.7/dist-packages/nova/compute/manager.py:2081
2016-06-23 15:52:14.019 25419 DEBUG nova.compute.utils 
[req-87a08e39-96ac-4c23-96dd-5227c972b865 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03
aa23 - - -] [instance: d75bd127-c554-4d79-bb9e-157c752628f4] Build of instance 
d75bd127-c554-4d79-bb9e-157c752628f4 aborted: Block Device Mapping is Invalid.
notify_about_instance_usage 
/usr/lib/python2.7/dist-packages/nova/compute/utils.py:284
2016-06-23 15:52:14.020 25419 ERROR nova.compute.manager 
[req-87a08e39-96ac-4c23-96dd-5227c972b865 0b7e5b0653084efdad5d67b66f2cf949 
2985b96e27f048cd92a18db0dd03aa23 - - -] [instance: 
d75bd127-c554-4d79-bb9e-157c752628f4] Build of instance 
d75bd127-c554-4d79-bb9e-157c752628f4 aborted: Block Device Mapping is Invalid.
- s n i p -
___
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] [Fuel] Deprecation of fuel-mirror tool

[Roman Prykhodchenko]

A big +1

> 23 черв. 2016 р. о 14:59 Bulat Gaifullin  
> написав(ла):
> 
> Totally agree with this decision.
> 
> Vladimir, thank you for driving this activity.
> 
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
> 
> 
> 
>> On 23 Jun 2016, at 13:31, Vladimir Kozhukalov > > wrote:
>> 
>> Dear colleagues.
>> 
>> I'd like to announce that fuel-mirror tool is not going to be a part of Fuel 
>> any more. Its functionality is to build/clone rpm/deb repos and modify Fuel 
>> releases repository lists (metadata).
>> 
>> Since Fuel 10.0 it is recommended to use other available tools for managing 
>> local deb/rpm repositories.
>> 
>> Packetary is a good example [0]. Packetary is ideal if one needs to create a 
>> partial mirror of a deb/rpm repository, i.e. mirror that contains not all 
>> available packages but only a subset of packages. To create full mirror it 
>> is better to use debmirror or rsync or any other tools that are available.
>> 
>> To modify releases repository lists one can use commands which are to 
>> available by default on the Fuel admin node since Newton.
>> 
>> # list of available releases
>> fuel2 release list
>> # list of repositories for a release
>> fuel2 release repos list 
>> # save list of repositories for a release in yaml format
>> fuel2 release repos list  -f yaml | tee repos.yaml
>> # modify list of repositories
>> vim repos.yaml
>> # update list of repositories for a release from yaml file
>> fuel2 release repos update  -f repos.yaml
>> 
>> They are provided by python-fuelclient [1] package and were introduced by 
>> this [2] patch.
>> 
>> 
>> [0] https://wiki.openstack.org/wiki/Packetary 
>> 
>> [1] https://github.com/openstack/python-fuelclient 
>> 
>> [2] https://review.openstack.org/#/c/326435/ 
>> 
>> 
>> 
>> Vladimir Kozhukalov
>> __
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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][oslo] pbr potential breaking change coming

[Jeremy Stanley]

On 2016-06-23 13:44:36 +0200 (+0200), Markus Zoeller wrote:
> Interesting, I didn't know that. It runs without warnings in Nova too,
> so hopefully everything's in a good shape for the pbr release. :)

Note that there has been at least one past proposal[1] to add a
"docs" tox environment as mandated in the CTI[2] for official
projects in Python, but it was rejected over concerns it would
encourage projects to run arbitrary commands before/after the Sphinx
build rather than implementing proper plugins.

[1] https://review.openstack.org/119875
[2] 
http://governance.openstack.org/reference/cti/python_cti.html#specific-commands
-- 
Jeremy Stanley

__
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] [fuel] Weekly meeting for today canceled.

[Andrew Woodward]

There is nothing in the agenda for the meeting today, so the meeting is
canceled

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
.
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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] admin-openrc error in openstack

[Turbo Fredriksson]

On Jun 23, 2016, at 3:02 PM, venkat boggarapu wrote:

> export OS_PROJECT_DOMAIN_NAME=defaultexport
> OS_USER_DOMAIN_NAME=defaultexport OS_PROJECT_NAME=adminexport
> OS_USERNAME=adminexport OS_PASSWORD=ADMIN_PASSexport
> OS_AUTH_URL=http://controller:35357/v3export
> OS_IDENTITY_API_VERSION=3export OS_IMAGE_API_VERSION=2


This looks like a cut-and-past error. Please make sure
to put each line on their own:

export OS_PROJECT_DOMAIN_NAME=default
export OS_USER_DOMAIN_NAME=default
export OS_PROJECT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=ADMIN_PASS
export OS_AUTH_URL=http://controller:35357/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2

And try something simple to verify that it works:

openstack user list
-- 
Try not. Do. Or do not. There is no try!
- Yoda


___
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] Ops Tag Team meeting time

[Shamail]

Hi Devon,

> On Jun 23, 2016, at 10:22 AM, Devon Boatwright  
> wrote:
> 
> Hello,
> 
> I just want to verify the time for the Ops Tag Team meeting time. It says 
> every other Thursday at 1400UTC. Which I'm showing would be today at 10am 
> EDT. However, there is no meeting going on? Are these meetings still 
> happening? I see the logs for the last meeting were in March. 
Thanks for bringing up this topic. These meetings should still happen but I 
have not been able to reach out to people with reminders over the last few 
months.  I will start sending routine reminders again to ensure they pick up 
again.

We also need to fix the schedule on eavesdrop.  The ops-tags team usually meets 
only once a month (which is supposed to be every 3rd Thursday of the month) but 
this option can not be defined in eavesdrop, hence our schedule shows every 
other week.  

We can try to hold the meeting every couple of weeks so there is a set cadence 
going forward, although some agendas might be fairly light.

Thanks,
Shamail 
> 
> Thanks!
> -- 
> Devon Boatwright
> devon.boatwri...@gmail.com
> ___
> 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] [grenade] upgrades vs rootwrap

[Sean Dague]

On 06/23/2016 10:07 AM, Sean McGinnis wrote:
> On Thu, Jun 23, 2016 at 12:19:34AM +, Angus Lees wrote:
>> So how does rootwrap fit into the "theory of upgrade"?
>>
>> The doc talks about deprecating config, but is silent on when new required
>> config (rootwrap filters) should be installed.  By virtue of the way the
>> grenade code works (install N from scratch, attempt to run code from N+1),
>> we effectively have a policy that any new configs are installed at some
>> nebulous time *after* the N+1 code is deployed.  In particular, this means
>> a new rootwrap filter needs to be merged a whole release before that
>> rootwrap entry can be used - and anything else is treated as an "exception"
>> (see for example the nova from-* scripts which have basically updated
>> rootwrap for each release).
>>
>> --
>>
>> Stepping back, I feel like an "expand-contract" style upgrade process
>> involving rootwrap should look something like
>> 0. Update rootwrap to be the union of N and N+1 rootwrap filters,
>> 1. Rolling update from N to N+1 code,
>> 2. Remove N-only rootwrap entries.
>>
>> We could make that a bit easier for deployers by having a sensible
>> deprecation policy that requires our own rootwrap filters for each release
>> are already the union of this release and the last (which indeed is already
>> our policy aiui), and then it would just look like:
>> 0. Install rootwrap filters from N+1
>> 1. Rolling update to N+1 code
> 
> I think effectively this is what we've ended up with in the past.
> 
> We've had this issue for some time. There have been several releases
> where either Cinder drivers or os-brick changes have needed to add
> rootwrap changes. Theoretically we _should_ have hit these problems long
> ago.
> 
> I think the only reason it hasn't come up before is that these changes
> are usually for vendor storage backends. So they never got hit in
> grenade tests since those use LVM. We have third party CI, but grenade
> tests are not a part of that.
> 
> The switch to privsep now has really highlighted this gap. I think we
> need to make this implied constraint clear and have it documented. To
> upgrade we will need to make sure the rootwrap filters are in place
> _before_ we perform any upgrades.

Are we going to have to do this for every service individually as it
moves to privsep? Or is there a way we can do it common once, take the
hit, and everyone moves forward?

For instance, can we get oslo.rootwrap to make an exception, in code,
for privsep-helper? Thereby not having to touch a config file in etc to
roll forward.

-Sean

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

[Openstack-operators] Ops Tag Team meeting time

[Devon Boatwright]

Hello,

I just want to verify the time for the Ops Tag Team meeting time. It says
every other Thursday at 1400UTC. Which I'm showing would be today at 10am
EDT. However, there is no meeting going on? Are these meetings still
happening? I see the logs for the last meeting were in March.

Thanks!
-- 
Devon Boatwright
devon.boatwri...@gmail.com
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [tripleo] [bigswitch] question about neutron bigswitch agent

[Emilien Macchi]

for the record: https://review.openstack.org/#/c/73/

On Wed, Jun 22, 2016 at 11:50 PM, Emilien Macchi  wrote:
> Ok I found what I wanted, for the record, only
> python-networking-bigswitch is required on the compute node, and not
> the restproxy options in neutron.
>
> On Wed, Jun 22, 2016 at 1:04 PM, Emilien Macchi  wrote:
>> Hey,
>>
>> I have a quick question for Bigswitch folks.
>> I'm currently working on TripleO composable service and refactoring a
>> bit of Neutron puppet code in TripleO Heat Templates.
>> I need to know if when you deploy a compute node, if you actually need
>> neutron plugins parameter (restproxy bits [1]).
>>
>> Looking at current THT master, it looks like compute environment does
>> not load the plugin, but only agent bits, but
>> puppet-neutron/agents/bigswitch has a require on the plugin, so I'm
>> really confused.
>>
>> Thanks for your help,
>>
>> [1] 
>> https://github.com/openstack/puppet-neutron/blob/master/manifests/plugins/ml2/bigswitch/restproxy.pp#L72-L84
>> --
>> 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

[openstack-dev] [javascript] remove IIFE in js-generator-openstack

[Yujun Zhang]

Hi, JavaScript Ninjas,

Currently, all scripts in js-generator-openstack
 is written in
IIFE form which is not necessary for nodejs project but introduce some
trouble to jsdoc.

What do you think we remove all the IIFE wrapper?

A partial modification can be previewed in
https://review.openstack.org/#/c/322881/

--
Yujun
__
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] [new][oslo] oslo.concurrency 2.6.1 release (liberty)

[no-reply]

We are gleeful to announce the release of:

oslo.concurrency 2.6.1: Oslo Concurrency library

This release is part of the liberty stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.concurrency

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.concurrency

For more details, please see below.

Changes in oslo.concurrency 2.6.0..2.6.1


d65d931 processutils: add support for missing process limits
e33f64f Add prlimit parameter to execute()
306cf37 Updated from global requirements
d0de35f Updated from global requirements
725e2f4 Updated from global requirements
d65a8b8 Update .gitreview for stable/liberty


Diffstat (except docs and test files)
-

.gitreview   |   3 +-
oslo_concurrency/prlimit.py  | 110 +
oslo_concurrency/processutils.py |  67 +++
requirements.txt |   6 +-
setup.py |   2 +-
6 files changed, 327 insertions(+), 5 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 9ac5e1c..5e66c50 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5,2 +5,2 @@
-pbr<2.0,>=1.6
-Babel>=1.3
+pbr>=1.6
+Babel!=2.3.0,!=2.3.1,!=2.3.2,!=2.3.3,>=1.3 # BSD
@@ -10 +10 @@ oslo.i18n>=1.5.0 # Apache-2.0
-oslo.utils>=2.0.0 # Apache-2.0
+oslo.utils!=2.6.0,>=2.0.0 # Apache-2.0



__
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] admin-openrc error in openstack

[venkat boggarapu]

Hi All,

I am getting the error when the run below in admin-openrc file

export OS_PROJECT_DOMAIN_NAME=defaultexport
OS_USER_DOMAIN_NAME=defaultexport OS_PROJECT_NAME=adminexport
OS_USERNAME=adminexport OS_PASSWORD=ADMIN_PASSexport
OS_AUTH_URL=http://controller:35357/v3export
OS_IDENTITY_API_VERSION=3export OS_IMAGE_API_VERSION=2

when i changed the password and url the versions, accordingly after running
the command  and press enter i am not getting any output.

can some one please help regarding this.


With regards
venkat
___
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] [grenade] upgrades vs rootwrap

[Sean McGinnis]

On Thu, Jun 23, 2016 at 12:19:34AM +, Angus Lees wrote:
> So how does rootwrap fit into the "theory of upgrade"?
> 
> The doc talks about deprecating config, but is silent on when new required
> config (rootwrap filters) should be installed.  By virtue of the way the
> grenade code works (install N from scratch, attempt to run code from N+1),
> we effectively have a policy that any new configs are installed at some
> nebulous time *after* the N+1 code is deployed.  In particular, this means
> a new rootwrap filter needs to be merged a whole release before that
> rootwrap entry can be used - and anything else is treated as an "exception"
> (see for example the nova from-* scripts which have basically updated
> rootwrap for each release).
> 
> --
> 
> Stepping back, I feel like an "expand-contract" style upgrade process
> involving rootwrap should look something like
> 0. Update rootwrap to be the union of N and N+1 rootwrap filters,
> 1. Rolling update from N to N+1 code,
> 2. Remove N-only rootwrap entries.
> 
> We could make that a bit easier for deployers by having a sensible
> deprecation policy that requires our own rootwrap filters for each release
> are already the union of this release and the last (which indeed is already
> our policy aiui), and then it would just look like:
> 0. Install rootwrap filters from N+1
> 1. Rolling update to N+1 code

I think effectively this is what we've ended up with in the past.

We've had this issue for some time. There have been several releases
where either Cinder drivers or os-brick changes have needed to add
rootwrap changes. Theoretically we _should_ have hit these problems long
ago.

I think the only reason it hasn't come up before is that these changes
are usually for vendor storage backends. So they never got hit in
grenade tests since those use LVM. We have third party CI, but grenade
tests are not a part of that.

The switch to privsep now has really highlighted this gap. I think we
need to make this implied constraint clear and have it documented. To
upgrade we will need to make sure the rootwrap filters are in place
_before_ we perform any upgrades.

> 
> --
> 
> So: We obviously need to update rootwrap filters at *some* point, and we
> should actually decide when that is.
> 
> We can stick with the current de-facto "config after code" grenade policy
> where we use the rootwrap filters from N for code from N+1, but this
> implies a 6-month lag on any new rootwrap-using code.  I hereby propose we
> choose a "config before code" where we use the rootwrap filters for N+1 for
> code from N+1.  This implies that upgrading the rootwrap filters is a
> necessary precondition for a code upgrade.

+1

> 
> In practice (for grenade) this just means copying any rootwrap filters from
> the new branch into place before attempting code upgrade.  I presume there
> would also be a corresponding ops docs impact - but I haven't seen our
> current published upgrade procedure.

I think we definitely should have this documented somewhere. Not that
most folks will read that documentation, but at least we have it out
there.

> 
> Thoughts?
> 
>  - Gus

> __
> 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-Infra] Problem with Cross-Repo Dependencies in Zuul

[Artur Zarzycki]

W dniu 22.06.2016 o 17:52, James E. Blair pisze:

Artur Zarzycki  writes:


...
And now as I understand zuul should recognize dependencies between patches.
So I created patch1 in repo1 and patch2 in repo2 with Depends-On:
I45137d1186caeafda0cee3504370d01ef3d9d271 (patch1)
and I'm trying to merge patch2. I see that zuul run  gate jobs for
repo2 and above area with job I see message:
Queue: some/repo1, some/repo2
When job finish with success -  code from repo2 is merged.

In zuul debug log I see:
2016-06-22 12:09:39,079 DEBUG zuul.DependentPipelineManager: Checking
for changes needed by :
2016-06-22 12:09:39,080 DEBUG zuul.DependentPipelineManager:   No
changes needed
2016-06-22 12:09:39,080 DEBUG zuul.DependentPipelineManager: Adding
change  to queue 

Could you please give me some hints what I did wrong? Do I need to
make something else to get it working?

 From what you describe, I don't see anything configured incorrectly.
Those log entries suggest that Zuul did not recognize the Depends-On
header and associate the two changes.  First, I would check:

* You are running a version of Zuul that supports Depends-On
* The syntax of the Depends-On header is correct (the line in the commit
   message must match this regex):
   "^Depends-On: (I[0-9a-f]{40})\s*$"

Then I would suggest looking in the debug log for entries near when Zuul
queried Gerrit for the change.  Assuming you are running git master, you
should see log messages like:

INFO zuul.source.Gerrit: Updating 
DEBUG zuul.source.Gerrit: Updating : Running query 
change:I45137d1186caeafda0cee3504370d01ef3d9d271 to find needed changes
DEBUG zuul.source.Gerrit: Updating : Getting 
commit-dependent change patch1
INFO zuul.source.Gerrit: Updating 

Indicating that when it loaded the data for patch2, it parsed the
Depends-On header, saw the I..271 change id, queried for it, and found
patch1 as a result.


Can it cause problems if I download code with
   git clone ssh://some_user@repo_url:29418/$ZUUL_PROJECT .
   git fetch $ZUUL_URL/$ZUUL_PROJECT $ZUUL_REF
   git checkout FETCH_HEAD
instead of using zuul_cloner?

What you do in the job should not affect this problem, however, I would
strongly recommend using zuul-cloner as it contains the collective
wisdom of the best way to prepare a git repo for testing.

-Jim


Thank you James!
You're right. The problem was in zuul version, we had 2.1.0 with some 
patches about I didn't know and one of them had impact on regex you pasted.

After fix it  everything works well  and I see proper logs.

--
Artur





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

[openstack-dev] [storlets]Brand new documentation

[eran]

Brand new documentation for storlets is now available.
Compiled HTML format can be found here:
http://storlets.readthedocs.io/en/latest/

Major new sections are:
1. A use cases section
2. A detailed dev env installation instructions (a-la SAIO), as well  
as deployment instructions.


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

[openstack-dev] [api] Today's API-WG meeting is headless

[Chris Dent]

All three of the usual chairs of the API-WG meeting (at 1600 UTC
in #openstack-meeting-3) are travelling today and will not be in
attendance. Apologies for the late notice.

If you were hoping to bring an issue up at the meeting today please
instead start an email thread tagged "[api]" so we can discuss it
asynchronously or if it seems appropriate create a bug[1].

If your heart was yearning to do some API-WG related thinking and
working during that hour, go to #openstack-meeting-3 at 1600 UTC and
find like minded people to discuss the pending guidelines[2] or
write some new guidelines based on the bugs in [1].

Thanks!

[1] https://bugs.launchpad.net/openstack-api-wg

[2] https://review.openstack.org/#/q/project:openstack/api-wg+status:open

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
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] Create instance fails on creating block device - Block Device Mapping is Invalid

[Turbo Fredriksson]

On Jun 23, 2016, at 2:10 PM, Turbo Fredriksson wrote:

> But even after disabling them, they're still show as 
> "status=disabled,state=up"
> with a "cinder service-list".. ?

I tried anyway, but creating a volume (empty or from an image) gave
the host field as empty. And the status was Error!

So apparently I need to figure out a way to configure "local storage".


The LVM volume shows:

- s n i p -
bladeA01b:~# openstack volume show test | grep host
| os-vol-host-attr:host | bladeA01b@lvm#LVM_iSCSI |
- s n i p -
--
Build a man a fire, and he will be warm for the night.
Set a man on fire and he will be warm for the rest of his life.


___
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] How do you handle purge of database tables ?

[Nick Jones]

> On Thu, 2016-06-23 at 09:55 +0100, Nick Jones wrote:
>> Another vote of confidence for the script that Tim has mentioned with
>> regards to clearing down Nova’s DB.  I blogged a bit about the process
>> and the results here:
>> 
>> 
>> http://dischord.org/2015/12/30/archiving-data-in-nova-s-database/
>> 
>> — 
> 
>> 
> 
> In Nova, there's 'nova-manage db archive_deleted_rows' - is that the one
> referred to in the blog post above that broke?

That’s the one.

— 

-Nick
-- 
DataCentred Limited registered in England and Wales no. 05611763

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

Re: [Openstack-operators] Keystone's DB_SYNC from Kilo to Liberty

[Matt Fischer]

IIRC there are some debug/verbose flags you can pass in. Get anything from
them?
On Jun 23, 2016 5:37 AM, "Alvise Dorigo"  wrote:

> Hi,
> I've a Kilo installation which I want to migrate to Liberty.
> I've installed the Liberty Keystone's RPMs and configured the minimun to
> upgrade the DB schema ("connection" parameter in the [database] section of
> keystone.conf).
> Then, I've tried to run
>
> su -s /bin/sh -c "keystone-manage db_sync" keystone
>
> but it's failed with the following error:
>
> 2016-06-23 13:20:50.191 22423 CRITICAL keystone [-] KeyError:
> 
>
> which is quite useless.
>
> Any suggestion ?
>
> many thanks,
>
> Alvise
>
> ___
> 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] Create instance fails on creating block device - Block Device Mapping is Invalid

[Turbo Fredriksson]

On Jun 23, 2016, at 12:26 PM, Eugen Block wrote:

> /etc/cinder/cinder.conf:enabled_backends = rbd--> that's what I use 
> currently

"rbd"?

> I'm not sure if it would work, it's been a while since I used local storage, 
> but if you just comment the enabled_backend option out and restart cinder 
> services, I believe it would create local volumes.

Shouldn't it be enough just to "disable" those services/backends?

I guess I have to, because just commenting that out didn't help, they still
show as enabled and running.

But even after disabling them, they're still show as "status=disabled,state=up"
with a "cinder service-list".. ?

>> Ok, that's different! I'm not running Glance on my Compute, only on my 
>> Control.
> 
> Glance is not supposed to run on a compute node, it runs on a control node.

Ok, good! I thought I missed something fundamental.

> What's the output of "openstack endpoint list | grep glance"?

| 57b10556b7bf47eaa019c603a0f6b34f | europe-london | glance | image | True | 
public   | http://10.0.4.1:9292
| 8672f6de1673470d93ab6ccee1c1a2bb | europe-london | glance | image | True | 
internal | http://10.0.4.1:9292
| e45c3e83fe744e7db949cdd89dfe5654 | europe-london | glance | image | True | 
admin| http://10.0.4.1:9292

That's the Control node..

>> [waited a little while]
> 
> How long did you wait?

10-15 seconds perhaps. At least less than (half?) a minute..

>  "This section describes how to install and configure the Image service, 
> code-named glance, on the controller node."

It is not obvious from that that that (!! :) should only be done on the
Controller! It just say "do this on the controller". It does not make it
clear that you shouldn't do something on the compute as well.

> "This section describes how to install and configure the Compute service, 
> code-named nova, on the controller node."
> "This section describes how to install and configure the Compute service on a 
> compute node."

Neither of which distinguish the different parts - what if I
have/want a separate compute and control node? It does not
make things obvious!


And that's why I have a problem with HOWTOs! They _assume_ to much.
And a _BAD_ HOWTO (which all of them on Openstack are!) doesn't even
attempt to explain the different options you have, so if you deviate
even the very slightest, you're f**ked!

There's a _HUMONGOS_ difference between a "HOWTO" and "Documentation"!

> Timeout problem? Make sure that nothing blocks the requests (proxy?), what 
> response do you get if you execute
> control1:~ # curl http://:9292

I was doing that ON the Control. Worked just fine.

And The Control and Compute is on the same switch.
-- 
Det är när man känner doften av sin egen avföring
som man börjar undra vem man egentligen är.
- Arne Anka


___
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] openstack liberty and lbaas v2

[Turbo Fredriksson]

On Jun 23, 2016, at 1:35 PM, Yngvi Páll Þorfinnsson wrote:

> service_plugins = 
> router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2
> service_provider = 
> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default

I'm pretty sure that if you look in your log files, you'll see that it
can't find that plugin 
('neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2').

At least, that's what I get.

I've tried all of these without luck:

- s n i p -
lbaas   => not found
 
lbaasv2 => not found
 
neutron.lbaas.loadbalancer.LoadBalancer => not found
 
neutron.lbaas.loadbalancer:LoadBalancer => not found
 
neutron.lbaas.services.loadbalancer.plugin.LoadBalancer => not found
 
neutron.lbaas.services.loadbalancer.plugin:LoadBalancer => not found
 
neutron.services.loadbalancer.plugin.LoadBalancerPlugin => not found
 
neutron.services.loadbalancer.plugin:LoadBalancerPlugin => not found
 
neutron.services.loadbalancer.plugin.LoadBalancerPluginv2   => not found
 
neutron.services.loadbalancer.plugin:LoadBalancerPluginv2   => not found
 
neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPlugin   => not found
 
neutron_lbaas.services.loadbalancer.plugin:LoadBalancerPlugin   => not found
 
neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2 => not found
 
neutron_lbaas.services.loadbalancer.plugin:LoadBalancerPluginv2 => not found
 
- s n i p -

I still haven't got this working :(.
--
God gave man both a penis and a brain,
but unfortunately not enough blood supply
to run both at the same time.
- R. Williams


___
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] [kolla] better solution for the non-ini format configure file

[Steven Dake (stdake)]

Looks like a really cool feature, and possibly a way to non-ini files, such as 
policy.json files which we just want to copy rather then override.

Kolla already has ini merging for ini files though and the example you provide 
is an ini file.  I like Kolla's ini merging, and it is sort of an external 
interface, since operators have been using it, so to remove it would mean 
following the deprecation cycle.  I do agree this would be fantastic for 
straight copies of non-ini configuration files.

Regards
-steve

From: OpenStack Mailing List Archive >
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Wednesday, June 22, 2016 at 8:47 PM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: Re: [openstack-dev] [kolla] better solution for the non-ini format 
configure file

Link: https://openstack.nimeyo.com/83165/?show=88496#a88496
From: AndrewLiu >


Recently, we find this feature of ansible:
http://docs.ansible.com/ansible/playbooks_loops.html#finding-first-matched-files

A specific path of template file can be add in the ansible task.

If a user want to customize an non-ini template file, the user can copy the 
template file to the customization directory, and modify the template file as 
the user wants.

An example of how to modify the ansible task:

change from:

- name: Copying over horizon.conf
  template:
  src: "{{ item }}.conf.j2"
  dest: "{{ node_config_directory }}/{{ item }}/{{ item }}.conf"
  with_items:
  - "horizon"


to:

- name: Copying over horizon.conf
  template:
  src: "{{ item }}"
  dest: "{{ node_config_directory }}/horizon/horizon.conf"
  with_first_found:
  - "{{ node_custom_config }}/horizon.conf.j2"
  - "horizon.conf.j2"


But a convention of how to organize the directory structure of customization 
template files should be addressed.
__
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] [Fuel] Deprecation of fuel-mirror tool

[Bulat Gaifullin]

Totally agree with this decision.

Vladimir, thank you for driving this activity.

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 23 Jun 2016, at 13:31, Vladimir Kozhukalov  
> wrote:
> 
> Dear colleagues.
> 
> I'd like to announce that fuel-mirror tool is not going to be a part of Fuel 
> any more. Its functionality is to build/clone rpm/deb repos and modify Fuel 
> releases repository lists (metadata). 
> 
> Since Fuel 10.0 it is recommended to use other available tools for managing 
> local deb/rpm repositories. 
> 
> Packetary is a good example [0]. Packetary is ideal if one needs to create a 
> partial mirror of a deb/rpm repository, i.e. mirror that contains not all 
> available packages but only a subset of packages. To create full mirror it is 
> better to use debmirror or rsync or any other tools that are available.
> 
> To modify releases repository lists one can use commands which are to 
> available by default on the Fuel admin node since Newton.
> 
> # list of available releases
> fuel2 release list
> # list of repositories for a release
> fuel2 release repos list 
> # save list of repositories for a release in yaml format
> fuel2 release repos list  -f yaml | tee repos.yaml
> # modify list of repositories
> vim repos.yaml
> # update list of repositories for a release from yaml file 
> fuel2 release repos update  -f repos.yaml
> 
> They are provided by python-fuelclient [1] package and were introduced by 
> this [2] patch. 
> 
> 
> [0] https://wiki.openstack.org/wiki/Packetary 
>  
> [1] https://github.com/openstack/python-fuelclient 
> 
> [2] https://review.openstack.org/#/c/326435/ 
> 
> 
> 
> Vladimir Kozhukalov
> __
> 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] openstack liberty and lbaas v2

[Yngvi Páll Þorfinnsson]

HI,

We've upgraded our openstack environment from Kilo to Liberty recently.
But while testing the Loadbalancing servcie , version 2 , I get an error:

neutron lbaas-loadbalancer-create --name test-lb 
b7b7fa5c-fac7-4da0-aa17-8506c2da678b
404 Not Found

The resource could not be found.

I'm using octavia and I've altered 'neutron.conf' file accordingly to the 
Liberty manual

service_plugins = 
router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2
service_provider = 
LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default

I've restarted all network services.

There is no lbaas agent running any more.

I can see from the "neutron ext-list" that LoadBalancing service is still has 
still the same alias as before, i.e. "lbaas"
Should this be "lbaasv2" afterwards?

neutron ext-list
+---+---+
| alias | name  |
+---+---+
| dns-integration   | DNS Integration   |
| ext-gw-mode   | Neutron L3 Configurable external gateway mode |
| binding   | Port Binding  |
| agent | agent |
| subnet_allocation | Subnet Allocation |
| l3_agent_scheduler| L3 Agent Scheduler|
| external-net  | Neutron external network  |
| flavors   | Neutron Service Flavors   |
| net-mtu   | Network MTU   |
| quotas| Quota management support  |
| l3-ha | HA Router extension   |
| provider  | Provider Network  |
| multi-provider| Multi Provider Network|
| lbaas | LoadBalancing service |
| extraroute| Neutron Extra Route   |
| lbaas_agent_scheduler | Loadbalancer Agent Scheduler  |
| extra_dhcp_opt| Neutron Extra DHCP opts   |
| service-type  | Neutron Service Type Management   |
| security-group| security-group|
| dhcp_agent_scheduler  | DHCP Agent Scheduler  |
| rbac-policies | RBAC Policies |
| router| Neutron L3 Router |
| allowed-address-pairs | Allowed Address Pairs |
| dvr   | Distributed Virtual Router|
+---+---+

Best regards
Yngvi

___
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] Unable to do software configuration in heat

[Vijay Baskar]

I am running a private cloud in openstack kilo version. I want to do
software deployments with heat. I can create stacks without any issues, but
when I try to deploy a stack with  - user_data_format: SOFTWARE_CONFIG
while creating a server(OS::Nova::Server), the configuration script fails
with error:

[   40.912057] cloud-init[805]: 2016-06-23 12:00:46,861 -
util.py[WARNING]: Failed running
/var/lib/cloud/instance/scripts/userdata [-]
[   40.927560] cloud-init[805]: 2016-06-23 12:00:46,875 -
cc_scripts_user.py[WARNING]: Failed to run module scripts-user
(scripts in /var/lib/cloud/instance/scripts)
[   40.930312] cloud-init[805]: 2016-06-23 12:00:46,875 -
util.py[WARNING]: Running module scripts-user ()
failed

Taken from boot logs of ubuntu 14.04 cloud server.

Template:

heat_template_version: 2013-05-23


parameters:
  file_content:
type: string
description: The contents of the file /tmp/file

resources:
  boot_config:
type: OS::Heat::CloudConfig
properties:
  cloud_config:
write_files:
- path: /tmp/file
  content: {get_param: file_content}

  server_with_cloud_config:
type: OS::Nova::Server
properties:
  # flavor, image etc
  flavor: m1.mini
  image: d7f70692-48c1-4d42-adc4-213a9c7cdb35
  networks:
- network: 397f1cc4-5368-41d9-a02e-1d1d89003dd7
  key_name: my-key
  user_data_format: SOFTWARE_CONFIG
  user_data: {get_resource: boot_config}


If I change the user_data_format: to "RAW" the configuration works.
user_data_format needs to be SOFTWARE_CONFIG if software deployments are to
be done(OS::Heat::SoftwareDeployment).


Regards,
Vijayabhaskar
___
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