Re: [openstack-dev] [Mistral] Plans to load and performance testing

[Dmitri Zimine]

Anastasia, any start is a good start. 

> 1 api 1 engine 1 executor, list-workbooks

what exactly doest it mean: 1) is mistral deployed on 3 boxes with component 
per box, or all three are processes on the same box? 2) is list-workbooks test 
running while workflow executions going on? How many? what’s the character of 
the load 3) when it says 60% success what exactly does it mean, what kind of 
failures? 4) what is the durability criteria, how long do we expect Mistral to 
withstand the load.  

Let’s discuss this in details on the next IRC meeting? 

Thanks again for getting this started. 

DZ.


On Dec 19, 2014, at 7:44 AM, Anastasia Kuznetsova  
wrote:

> Boris,
> 
> Thanks for feedback! 
> 
> > But I belive that you should put bigger load here: 
> > https://etherpad.openstack.org/p/mistral-rally-testing-results
> 
> As I said it is only beginning and  I will increase the load and change its 
> type. 
> 
> >As well concurrency should be at least 2-3 times bigger than times otherwise 
> >it won't generate proper load and you won't collect >enough data for 
> >statistical analyze.  
> >
> >As well use  "rps" runner that generates more real life load.
> >Plus it will be nice to share as well output of "rally task report" command.
> 
> Thanks for the advice, I will consider it in further testing and reporting.
> 
> Answering to your question about using Rally for integration testing, as I 
> mentioned in our load testing plan published on wiki page,  one of our final 
> goals is to have a Rally gate in one of Mistral repositories, so we are 
> interested in it and I already prepare first commits to Rally.
> 
> Thanks,
> Anastasia Kuznetsova
> 
> On Fri, Dec 19, 2014 at 4:51 PM, Boris Pavlovic  
> wrote:
> Anastasia, 
> 
> Nice work on this. But I belive that you should put bigger load here: 
> https://etherpad.openstack.org/p/mistral-rally-testing-results
> 
> As well concurrency should be at least 2-3 times bigger than times otherwise 
> it won't generate proper load and you won't collect enough data for 
> statistical analyze.  
> 
> As well use  "rps" runner that generates more real life load.
> Plus it will be nice to share as well output of "rally task report" command.
> 
> 
> By the way what do you think about using Rally scenarios (that you already 
> wrote) for integration testing as well? 
> 
> 
> Best regards,
> Boris Pavlovic 
> 
> On Fri, Dec 19, 2014 at 2:39 PM, Anastasia Kuznetsova 
>  wrote:
> Hello everyone,
> 
> I want to announce that Mistral team has started work on load and performance 
> testing in this release cycle.
> 
> Brief information about scope of our work can be found here: 
> https://wiki.openstack.org/wiki/Mistral/Testing#Load_and_Performance_Testing
> 
> First results are published here:
> https://etherpad.openstack.org/p/mistral-rally-testing-results
> 
> Thanks,
> Anastasia Kuznetsova
> @ Mirantis Inc.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [cinder] [driver] DB operations

[Amit Das]

Thanks Duncan.
Do you mean hepler methods in the specific driver class?
On 19 Dec 2014 14:51, "Duncan Thomas"  wrote:

> So our general advice has historical been 'drivers should not be accessing
> the db directly'. I haven't had chance to look at your driver code yet,
> I've been on vacation, but my suggestion is that if you absolutely must
> store something in the admin metadata rather than somewhere that is covered
> by the model update (generally provider location and provider auth) then
> writing some helper methods that wrap the context bump and db call would be
> better than accessing it directly from the driver.
>
> Duncan Thomas
> On Dec 18, 2014 11:41 PM, "Amit Das"  wrote:
>
>> Hi Stackers,
>>
>> I have been developing a Cinder driver for CloudByte storage and have
>> come across some scenarios where the driver needs to do create, read &
>> update operations on cinder database (volume_admin_metadata table). This is
>> required to establish a mapping between OpenStack IDs with the backend
>> storage IDs.
>>
>> Now, I have got some review comments w.r.t the usage of DB related
>> operations esp. w.r.t raising the context to admin.
>>
>> In short, it has been advised not to use "*context.get_admin_context()*".
>>
>>
>> https://review.openstack.org/#/c/102511/15/cinder/volume/drivers/cloudbyte/cloudbyte.py
>>
>> However, i get errors trying to use the default context as shown below:
>>
>> *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher   File
>> "/opt/stack/cinder/cinder/db/sqlalchemy/api.py", line 103, in
>> is_admin_context*
>> *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher return
>> context.is_admin*
>> *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher
>> AttributeError: 'module' object has no attribute 'is_admin'*
>>
>> So what is the proper way to run these DB operations from within a driver
>> ?
>>
>>
>> Regards,
>> Amit
>> *CloudByte Inc.* 
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Mistral] For-each

[Dmitri Zimine]

Folks, 

I appended some more ideas on making for-each loop more readable / less 
confusing in the document. 

It’s not rocking the boat (yet) - all the key agreements done that far, stay so 
far. It’s refinements. 

Please take a look, leave comments, +1 / -1 for various ideas, and leave your 
ideas there, too. 

https://docs.google.com/document/d/1iw0OgQcU0LV_i3Lnbax9NqAJ397zSYA3PMvl6F_uqm0/edit#heading=h.5hjdjqxsgfle

DZ. 

On Dec 19, 2014, at 1:01 PM, Dmitri Zimine  wrote:

> Thanks Angus. 
> 
> One obvious thing is we either make it somewhat consistent, or name it 
> differently. 
> These looks similar, at least on the surface. I wonder if the feedback we’ve 
> got so far (for-each is confusing because it brings wrong expectations) is 
> applicable to Heat, too. 
> 
> Another observation on naming consistency - mistral uses dash, like 
> `for-each`. 
> Heat uses _underscores when naming YAML keys. 
> So does TOSCA standard. We should have thought about this earlier but it may 
> be not late to fix it while v2 spec is still forming. 
> 
> DZ. 
> 
> 
> On Dec 18, 2014, at 9:07 PM, Angus Salkeld  wrote:
> 
>> On Mon, Dec 15, 2014 at 8:00 PM, Nikolay Makhotkin  
>> wrote:
>> Hi,
>> 
>> Here is the doc with suggestions on specification for for-each feature.
>> 
>> You are free to comment and ask questions.
>> 
>> https://docs.google.com/document/d/1iw0OgQcU0LV_i3Lnbax9NqAJ397zSYA3PMvl6F_uqm0/edit?usp=sharing
>> 
>> 
>> 
>> Just as a drive by comment, there is a Heat spec for a "for-each": 
>> https://review.openstack.org/#/c/140849/
>> (there hasn't been a lot of feedback for it yet tho')
>> 
>> Nice to have these somewhat consistent.
>> 
>> -Angus
>>  
>> 
>> -- 
>> Best Regards,Nikolay
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

[openstack-dev] End of year gratitude

[Anne Gentle]

I don't gush much, but when I do, it's end-of-year reflection gushing. We
have some of the most interesting docs in the world.

I'm proud of what we've accomplished as a community, as reviewers, as
coaches, as tool makers, and as writers.

To encourage and motivate nearly 200 separate contributors in six months is
no small feat. I hope you can celebrate with friends, family, pets, and
wildlife, taking a nice, well-earned break.

Warmly,
Anne

 .--._.--.--.__.--.--.__.--.--.__.--.--._.--.
   _(_  _Y_  _Y_  _Y_  _Y_  _)_
  [___][___][___][___][___][___]
  /:' \/:' \/:' \/:' \/:' \/:' \
 |::   |  |::   |  |::   |  |::   |  |::   |  |::   |
 \::.  /  \::.  /  \::.  /  \::.  /  \::.  /  \::.  /
  \::./\::./\::./\::./\::./\::./
   '='  '='  '='  '='  '='  '='
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][fwaas] neutron/agent/firewall.py

[Sridar Kandaswamy (skandasw)]

+1 Mathieu. Paul, this is not related to FWaaS.

Thanks

Sridar

On 12/19/14, 2:23 PM, "Mathieu Gagné"  wrote:

>On 2014-12-19 5:16 PM, Paul Michali (pcm) wrote:
>>
>> This has a FirewallDriver and NoopFirewallDriver. Should this be moved
>> into the neutron_fwaas repo?
>>
>
>AFAIK, FirewallDriver is used to implement SecurityGroup:
>
>See:
>- 
>https://github.com/openstack/neutron/blob/master/neutron/agent/firewall.py
>#L26-L29
>- 
>https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptab
>les_firewall.py#L45
>- 
>https://github.com/openstack/neutron/blob/master/neutron/plugins/hyperv/ag
>ent/security_groups_driver.py#L25
>
>This class looks to not be used by neutron-fwaas
>
>-- 
>Mathieu
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron][vpnaas] Sub-team meetings on Dec 20th and 27th?

[Nati Ueno]

+1 for skip
let's have a vacation :)

2014-12-19 11:01 GMT-08:00 Paul Michali (pcm) :
> Does anyone have agenda items to discuss for the next two meetings during
> the holidays?
>
> If so, please let me know (and add them to the Wiki page), and we’ll hold
> the meeting. Otherwise, we can continue on Jan 6th, and any pop-up items can
> be addressed on the mailing list or Neutron IRC.
>
> Please let me know by Monday, if you’d like us to meet.
>
>
> Regards,
>
> PCM (Paul Michali)
>
> MAIL …..…. p...@cisco.com
> IRC ……..… pc_m (irc.freenode.com)
> TW ………... @pmichali
> GPG Key … 4525ECC253E31A83
> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Nachi Ueno
email:nati.u...@gmail.com
twitter:http://twitter.com/nati

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

Re: [openstack-dev] [neutron][fwaas] neutron/agent/firewall.py

[Mathieu Gagné]

On 2014-12-19 5:16 PM, Paul Michali (pcm) wrote:


This has a FirewallDriver and NoopFirewallDriver. Should this be moved
into the neutron_fwaas repo?



AFAIK, FirewallDriver is used to implement SecurityGroup:

See:
- 
https://github.com/openstack/neutron/blob/master/neutron/agent/firewall.py#L26-L29
- 
https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L45
- 
https://github.com/openstack/neutron/blob/master/neutron/plugins/hyperv/agent/security_groups_driver.py#L25


This class looks to not be used by neutron-fwaas

--
Mathieu

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

[openstack-dev] [neutron][fwaas] neutron/agent/firewall.py

[Paul Michali (pcm)]

Curious…

This has a FirewallDriver and NoopFirewallDriver. Should this be moved into the 
neutron_fwaas repo?

Regards,


PCM (Paul Michali)

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






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

Re: [openstack-dev] [libvirt][vpnaas] IRC Meeting Clash

[Paul Michali (pcm)]

Sorry, I had checked when I set up the VPN meeting and thought that meeting-3 
was available on the wiki, but apparently not. I moved VPNaaS to meeting-4, 
which is not in use and updated the Wiki.

Nachi, let me know what your thoughts about skipping or holding meetings next 
week.

Regards,

PCM (Paul Michali)

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




On Dec 19, 2014, at 3:29 PM, Nati Ueno  wrote:

> Hi folks
> 
> I'm from vpnaas team.
> Sorry, we didn't know that slot was already booked.
> We will use another irc channel.
> 
>> Paul
> let's find another available slot.
> 
> 
> 2014-12-19 2:12 GMT-08:00 Daniel P. Berrange :
>> On Fri, Dec 19, 2014 at 10:05:44AM +, Matthew Gilliard wrote:
>>> Hello,
>>> 
>>>  At the moment, both Libvirt [1] and VPNaaS [2] are down as having
>>> meetings in #openstack-meeting-3 at 1500UTC on Tuesdays. Of course,
>>> there can be only one - and it looks as if the VPN meeting is the one
>>> that actually takes place there.
>>> 
>>>  What's the status of the libvirt meetings? Have they moved, or are
>>> they not happening any more?
>> 
>> They happen, but when there are no agenda items that need discussing
>> they're done pretty quickly.
>> 
>> Given that VPN meeting was only added ot the wiki a week ago, I think
>> it should be the meeting that changes time or place.
>> 
>> NB identifying free slots from the wiki is a total PITA. It is easier to
>> install the iCal calendar feed, which gives you a visual representation
>> of what the free/busy slots are during the week.
>> 
>> Regards,
>> Daniel
>> --
>> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org  -o- http://virt-manager.org :|
>> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Nachi Ueno
> email:nati.u...@gmail.com
> twitter:http://twitter.com/nati



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

Re: [openstack-dev] [Mistral] For-each

[Dmitri Zimine]

Thanks Angus. 

One obvious thing is we either make it somewhat consistent, or name it 
differently. 
These looks similar, at least on the surface. I wonder if the feedback we’ve 
got so far (for-each is confusing because it brings wrong expectations) is 
applicable to Heat, too. 

Another observation on naming consistency - mistral uses dash, like `for-each`. 
Heat uses _underscores when naming YAML keys. 
So does TOSCA standard. We should have thought about this earlier but it may be 
not late to fix it while v2 spec is still forming. 

DZ. 


On Dec 18, 2014, at 9:07 PM, Angus Salkeld  wrote:

> On Mon, Dec 15, 2014 at 8:00 PM, Nikolay Makhotkin  
> wrote:
> Hi,
> 
> Here is the doc with suggestions on specification for for-each feature.
> 
> You are free to comment and ask questions.
> 
> https://docs.google.com/document/d/1iw0OgQcU0LV_i3Lnbax9NqAJ397zSYA3PMvl6F_uqm0/edit?usp=sharing
> 
> 
> 
> Just as a drive by comment, there is a Heat spec for a "for-each": 
> https://review.openstack.org/#/c/140849/
> (there hasn't been a lot of feedback for it yet tho')
> 
> Nice to have these somewhat consistent.
> 
> -Angus
>  
> 
> -- 
> Best Regards,Nikolay
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [TripleO] CI/CD report - 2014-12-12 - 2014-12-19

[Gregory Haynes]

Excerpts from James Polley's message of 2014-12-19 17:10:41 +:
> Two major CI outages this week
> 
> 2014-12-12 - 2014-12-15 - pip install MySQL-python failing on fedora
> - There was an updated mariadb-devel package, which caused pip install of
> the python bindings to fail as gcc could not build using the provided
> headers.
>  - derekh put in a workaround on the 15th but we have to wait until
> upstream provides a fixed package for a permanent resolution
> 
> 2014-12-17 - failures in many projects on py33 tests
> - Caused by an unexpected interaction between new features in pbr and the
> way docutils handles python3 compatibility
> - derekh resolved this by tweaking the build process to not build pbr -
> just download the latest pbr from upstream

I am a bad person and forgot to update our CI outage etherpad, but we
had another outage that was caused by the setuptools PEP440 breakage:

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

We might be able to revert this now if the world is fixed

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

Re: [openstack-dev] [libvirt][vpnaas] IRC Meeting Clash

[Nati Ueno]

Hi folks

I'm from vpnaas team.
Sorry, we didn't know that slot was already booked.
We will use another irc channel.

> Paul
let's find another available slot.


2014-12-19 2:12 GMT-08:00 Daniel P. Berrange :
> On Fri, Dec 19, 2014 at 10:05:44AM +, Matthew Gilliard wrote:
>> Hello,
>>
>>   At the moment, both Libvirt [1] and VPNaaS [2] are down as having
>> meetings in #openstack-meeting-3 at 1500UTC on Tuesdays. Of course,
>> there can be only one - and it looks as if the VPN meeting is the one
>> that actually takes place there.
>>
>>   What's the status of the libvirt meetings? Have they moved, or are
>> they not happening any more?
>
> They happen, but when there are no agenda items that need discussing
> they're done pretty quickly.
>
> Given that VPN meeting was only added ot the wiki a week ago, I think
> it should be the meeting that changes time or place.
>
> NB identifying free slots from the wiki is a total PITA. It is easier to
> install the iCal calendar feed, which gives you a visual representation
> of what the free/busy slots are during the week.
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Nachi Ueno
email:nati.u...@gmail.com
twitter:http://twitter.com/nati

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

[openstack-dev] [Ironic] maintaining our stable branches

[Devananda van der Veen]

Hi folks!

We now have control over our own stable branch maintenance, which is good,
because the stable maintenance team is not responsible for non-integrated
releases of projects (eg, both of our previous releases).

Also, to note, with the Big Tent changes starting to occur, such
responsibilities will be more distributed in the future. [0] For the
remainder of this cycle, we'll reuse the ironic-milestone group for stable
branch maintenance [1]; when Kilo is released, we'll need to create an
ironic-stable-maint gerrit group and move to that, or generally do what
ever the process looks like at that point.

In any case, for now I've seeded the group with Adam Gandelman and myself
(since we were already tracking Ironic's stable branches). If any other
cores would like to help with this, please ping me, I'm happy to add folks
but don't want to assume that all cores want the responsibility.

We should also decide and document, explicitly, what support we're giving
to the Icehouse and Juno releases. My sense is that we should drop support
for Icehouse, but I'll put that on the weekly meeting agenda for after the
holidays.

-Devananda

[0]
http://lists.openstack.org/pipermail/openstack-dev/2014-November/050390.html

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

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

[Asselin, Ramy]

Eduard,

If you run this command, you can see which jobs are registered:
>telnet localhost 4730

>status

There are 3 numbers per job: queued, running and workers that can run job. Make 
sure the job is listed & last ‘workers’ is non-zero.

To run the job again without submitting a patch set, leave a “recheck” comment 
on the patch & make sure your zuul layout.yaml is configured to trigger off 
that comment. For example [1].
Be sure to use the sandbox repository. [2]
I’m not aware of other ways.

Ramy

[1] 
https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L20
[2] https://github.com/openstack-dev/sandbox




From: Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
Sent: Friday, December 19, 2014 3:36 AM
To: Asselin, Ramy
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting 
up CI

Hi all,
After a little struggle with the config scripts i managed to get a working 
setup that is able to process openstack-dev/sandbox and run 
noop-check-comunication.

Then, i tried enabling dsvm-tempest-full job but it keeps returning 
"NOT_REGISTERED"

2014-12-19 12:07:14,683 INFO zuul.IndependentPipelineManager: Change  depends on changes []
2014-12-19 12:07:14,683 INFO zuul.Gearman: Launch job noop-check-communication 
for change  with dependent changes []
2014-12-19 12:07:14,693 INFO zuul.Gearman: Launch job dsvm-tempest-full for 
change  with dependent changes []
2014-12-19 12:07:14,694 ERROR zuul.Gearman: Job  is not registered with Gearman
2014-12-19 12:07:14,694 INFO zuul.Gearman: Build  complete, result NOT_REGISTERED
2014-12-19 12:07:14,765 INFO zuul.Gearman: Build http://127.0.0.1:2> name: build:noop-check-communication 
unique: 333c6ea077324a788e3c37a313d872c5> started
2014-12-19 12:07:14,910 INFO zuul.Gearman: Build http://127.0.0.1:2> name: build:noop-check-communication 
unique: 333c6ea077324a788e3c37a313d872c5> complete, result SUCCESS
2014-12-19 12:07:14,916 INFO zuul.IndependentPipelineManager: Reporting change 
, actions: [, {'verified': -1}>]

Nodepoold's log show no reference to dsvm-tempest-full and neither jenkins' 
logs.

Any idea how to enable this job?

Also, i got the "Cloud provider" setup and i can access it from the jenkins 
master.
Any idea how i can manually trigger dsvm-tempest-full job to run and test the 
cloud provider without having to push a review to Gerrit?

Thanks,
Eduard

On Thu, Dec 18, 2014 at 7:52 PM, Eduard Matei 
mailto:eduard.ma...@cloudfounders.com>> wrote:
Thanks for the input.

I managed to get another master working (on Ubuntu 13.10), again with some 
issues since it was already setup.
I'm now working towards setting up the slave.

Will add comments to those reviews.

Thanks,
Eduard

On Thu, Dec 18, 2014 at 7:42 PM, Asselin, Ramy 
mailto:ramy.asse...@hp.com>> wrote:
Yes, Ubuntu 12.04 is tested as mentioned in the readme [1]. Note that the 
referenced script is just a wrapper that pulls all the latest from various 
locations in openstack-infra, e.g. [2].
Ubuntu 14.04 support is WIP [3]
FYI, there’s a spec to get an in-tree 3rd party ci solution [4]. Please add 
your comments if this interests you.

[1] https://github.com/rasselin/os-ext-testing/blob/master/README.md
[2] 
https://github.com/rasselin/os-ext-testing/blob/master/puppet/install_master.sh#L29
[3] https://review.openstack.org/#/c/141518/
[4] https://review.openstack.org/#/c/139745/


From: Punith S [mailto:punit...@cloudbyte.com]
Sent: Thursday, December 18, 2014 3:12 AM
To: OpenStack Development Mailing List (not for usage questions); Eduard Matei

Subject: Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting 
up CI

Hi Eduard

we tried running 
https://raw.githubusercontent.com/rasselin/os-ext-testing/master/puppet/install_master.sh
on ubuntu master 12.04, and it appears to be working fine on 12.04.

thanks

On Thu, Dec 18, 2014 at 1:57 PM, Eduard Matei 
mailto:eduard.ma...@cloudfounders.com>> wrote:
Hi,
Seems i can't install using puppet on the jenkins master using 
install_master.sh from 
https://raw.githubusercontent.com/rasselin/os-ext-testing/master/puppet/install_master.sh
 because it's running Ubuntu 11.10 and it appears unsupported.
I managed to install puppet manually on master and everything else fails
So i'm trying to manually install zuul and nodepool and jenkins job builder, 
see where i end up.

The slave looks complete, got some errors on running install_slave so i ran 
parts of the script manually, changing some params and it appears installed but 
no way to test it without the master.

Any ideas welcome.

Thanks,

Eduard

On Wed, Dec 17, 2014 at 3:37 AM, Asselin, Ramy 
mailto:ramy.asse...@hp.com>> wrote:
Manually running the script requires a few environment settings. Take a look at 
the README here:
https://github.com/openstack-infra/devstack-gate

Regarding cinder, I’m using this repo to run our cinder jobs (fork from 
jaypipe

Re: [openstack-dev] [cinder] [driver] DB operations

[Mike Perez]

On 01:20 Fri 19 Dec , Duncan Thomas wrote:
> So our general advice has historical been 'drivers should not be accessing
> the db directly'. I haven't had chance to look at your driver code yet,
> I've been on vacation, but my suggestion is that if you absolutely must
> store something in the admin metadata rather than somewhere that is covered
> by the model update (generally provider location and provider auth) then
> writing some helper methods that wrap the context bump and db call would be
> better than accessing it directly from the driver.
> 
> Duncan Thomas
> On Dec 18, 2014 11:41 PM, "Amit Das"  wrote:
> 

> > So what is the proper way to run these DB operations from within a driver ?

Drivers not doing db changes is also documented in the "How to contribute
a driver" wiki page.

https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver

-- 
Mike Perez

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

Re: [openstack-dev] [api] Analysis of current API design

[Dean Troyer]

On Fri, Dec 19, 2014 at 10:17 AM, Amit Gandhi 
wrote:
>
>
> How do the allocation of the service types in the service catalog get
> created.
>

Officially these are deployer-defined.  And is why some clients allow you
to configure the service name used.  The service types are supposed to be
consistent, but are also not in practice.


> How do new openstack related projects (that are not incubated/graduated)
> appear in the service catalog with a consistent service type name that can
> be used across providers with the confidence it refers to the same set of
> api's?  Is it just an assumption, or do we need a catalogue somewhere
> listing what each service type is associated with?  Does adding it to
> Devstack pretty much stake claim to the service type?


DevStack has become a de facto source for defaults for a lot of things, and
this is not a good thing.  The DevStack defaults are chosen for developer
and CI testing use and do not necessarily take in to consideration any
actual deployment considerations.

dt

-- 

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

[openstack-dev] [neutron][vpnaas] Sub-team meetings on Dec 20th and 27th?

[Paul Michali (pcm)]

Does anyone have agenda items to discuss for the next two meetings during the 
holidays?

If so, please let me know (and add them to the Wiki page), and we’ll hold the 
meeting. Otherwise, we can continue on Jan 6th, and any pop-up items can be 
addressed on the mailing list or Neutron IRC.

Please let me know by Monday, if you’d like us to meet.


Regards,

PCM (Paul Michali)

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






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

Re: [openstack-dev] [api] Analysis of current API design

[Everett Toews]

I thought the analysis on service catalogs might attract some attention. ;)

More inline

On Dec 19, 2014, at 10:17 AM, Amit Gandhi  wrote:

> How do the allocation of the service types in the service catalog get created.

AFAICT it’s arbitrary. Provider picks the string used in the service type.

> For example, looking at the link provided below for service catalogs [1], you 
> have with Rackspace a service type of rax:queues (which is running zaqar).  
> However in devstack, zaqar is listed as “messaging”.  FWIW i think the 
> rackspace entry came before the devstack entry, but there is now an 
> inconsistency.
> 
> How do new openstack related projects (that are not incubated/graduated) 
> appear in the service catalog with a consistent service type name that can be 
> used across providers with the confidence it refers to the same set of api's? 
>  

That’s what we’re hoping to achieve with guidelines around the service catalog. 
So when the provider goes to pick the strings used in the service catalog, 
there’s consistency.

> Is it just an assumption, or do we need a catalogue somewhere listing what 
> each service type is associated with?  

Yes. This is what would be part of the guideline.

> Does adding it to Devstack pretty much stake claim to the service type?

To date, this has been the case. The DevStack version of the service catalog 
sort of became a de facto standard. But not de facto enough and hence the 
inconsistency.

It’d be great to hear thoughts from Adam Y, Dolph M, and Dean T on the subject. 
I don’t think I have the full picture.

Thanks,
Everett


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

[openstack-dev] [neutron][lbaas] meetings during holidays

[Doug Wiegley]

Hi all,

Anyone have big agenda items for the 12/23 or 12/30 meeting? If not, I’d
suggest we cancel those two meetings, and bring up anything small during
the on-demand portion of the neutron meetings.

If I don’t hear anything by Monday, we will cancel those two meetings.

Thanks,
Doug

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

Re: [openstack-dev] [python-*client] py33 jobs seem to be failing

[Jeremy Stanley]

On 2014-12-19 11:32:02 -0500 (-0500), Steve Martinelli wrote:
> Seems like https://review.openstack.org/#/c/142561/ fixed the issue.
> 
> As there haven't been any hits in logstash in roughly 24hrs, and
> we're getting clean builds in python-keystoneclient and
> openstackclient.
[...]

Apparently there are some PBR-based projects still using nose which
is failing Python 3.x jobs for similar reasons as docutils was. We
just discovered this a few minutes ago and are trying to figure out
a similar solution.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration

[Kyle Mestery]

On Fri, Dec 19, 2014 at 10:59 AM, Anita Kuno  wrote:
>
> Rather than waste your time making excuses let me state where we are and
> where I would like to get to, also sharing my thoughts about how you can
> get involved if you want to see this happen as badly as I have been told
> you do.
>
> Where we are:
> * a great deal of foundation work has been accomplished to achieve
> parity with nova-network and neutron to the extent that those involved
> are ready for migration plans to be formulated and be put in place
> * a summit session happened with notes and intentions[0]
> * people took responsibility and promptly got swamped with other
> responsibilities
> * spec deadlines arose and in neutron's case have passed
> * currently a neutron spec [1] is a work in progress (and it needs
> significant work still) and a nova spec is required and doesn't have a
> first draft or a champion
>
> Where I would like to get to:
> * I need people in addition to Oleg Bondarev to be available to help
> come up with ideas and words to describe them to create the specs in a
> very short amount of time (Oleg is doing great work and is a fabulous
> person, yay Oleg, he just can't do this alone)
> * specifically I need a contact on the nova side of this complex
> problem, similar to Oleg on the neutron side
> * we need to have a way for people involved with this effort to find
> each other, talk to each other and track progress
> * we need to have representation at both nova and neutron weekly
> meetings to communicate status and needs
>
> We are at K-2 and our current status is insufficient to expect this work
> will be accomplished by the end of K-3. I will be championing this work,
> in whatever state, so at least it doesn't fall off the map. If you would
> like to help this effort please get in contact. I will be thinking of
> ways to further this work and will be communicating to those who
> identify as affected by these decisions in the most effective methods of
> which I am capable.
>
> Thank you to all who have gotten us as far as well have gotten in this
> effort, it has been a long haul and you have all done great work. Let's
> keep going and finish this.
>
> Thank you,
> Anita.
>
> Thank you for volunteering to drive this effort Anita, I am very happy
about this. I support you 100%.

I'd like to point out that we really need a point of contact on the nova
side, similar to Oleg on the Neutron side. IMHO, this is step 1 here to
continue moving this forward.

Thanks,
Kyle


> [0] https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron
> [1] https://review.openstack.org/#/c/142456/
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?

[Randall Burt]

There should already be blueprints in launchpad for very similar functionality. 
For example: https://blueprints.launchpad.net/heat/+spec/lifecycle-callbacks. 
While that specifies Heat sending notifications to the outside world, there has 
been discussion around debugging that would allow the receiver to send 
notifications back. I only point this out so you can see there should be 
similar blueprints and specs that you can reference and use as examples.

On Dec 19, 2014, at 4:17 AM, Steven Hardy 
 wrote:

> On Fri, Dec 19, 2014 at 05:02:04PM +0900, Yasunori Goto wrote:
>> 
>> Hello,
>> 
>> This is the first mail at Openstack community,
> 
> Welcome! :)
> 
>> and I have a small question about how to write blueprint for Heat.
>> 
>> Currently our team would like to propose 2 interfaces
>> for users operation in HOT. 
>> (One is "Event handler" which is to notify user's defined event to heat.
>> Another is definitions of action when heat catches the above notification.)
>> So, I'm preparing the blueprint for it.
> 
> Please include details of the exact use-case, e.g the problem you're trying
> to solve (not just the proposed solution), as it's possible we can suggest
> solutions based on exiting interfaces.
> 
>> However, I can not find how I can write at the milestone section of 
>> blueprint.
>> 
>> Heat blueprint template has a section for Milestones.
>> "Milestones -- Target Milestone for completeion:"
>> 
>> But I don't think I can decide it by myself.
>> In my understanding, it should be decided by PTL.
> 
> Normally, it's decided by when the person submitting the spec expects to
> finish writing the code by.  The PTL doesn't really have much control over
> that ;)
> 
>> In addition, probably the above our request will not finish
>> by Kilo. I suppose it will be "L" version or later.
> 
> So to clarify, you want to propose the feature, but you're not planning on
> working on it (e.g implementing it) yourself?
> 
>> So, what should I write at this section?
>> "Kilo-x", "L version", or empty?
> 
> As has already been mentioned, it doesn't matter that much - I see it as a
> statement of intent from developers.  If you're just requesting a feature,
> you can even leave it blank if you want and we'll update it when an
> assignee is found (e.g during the spec review).
> 
> Thanks,
> 
> Steve
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [TripleO] CI/CD report - 2014-12-12 - 2014-12-19

[James Polley]

Two major CI outages this week

2014-12-12 - 2014-12-15 - pip install MySQL-python failing on fedora
- There was an updated mariadb-devel package, which caused pip install of
the python bindings to fail as gcc could not build using the provided
headers.
 - derekh put in a workaround on the 15th but we have to wait until
upstream provides a fixed package for a permanent resolution

2014-12-17 - failures in many projects on py33 tests
- Caused by an unexpected interaction between new features in pbr and the
way docutils handles python3 compatibility
- derekh resolved this by tweaking the build process to not build pbr -
just download the latest pbr from upstream

As always, more details can be found at
https://etherpad.openstack.org/p/tripleo-ci-breakages

The HP2 region is still struggling along trying to be built. I've created a
trello board at https://trello.com/b/MXbIP2qe/tripleo-cd to track current
roadblocks + the current outstanding patches we're using to build HP2.

If you're a CD admin and would like to help get HP2 up and running, take a
look at the board (and ping me when you hit something I've written in a way
that only makes sense if you already understand the problem). If you're not
a CD admin, a few of the patches need some simple tidyups.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] The state of nova-network to neutron migration

[Anita Kuno]

Rather than waste your time making excuses let me state where we are and
where I would like to get to, also sharing my thoughts about how you can
get involved if you want to see this happen as badly as I have been told
you do.

Where we are:
* a great deal of foundation work has been accomplished to achieve
parity with nova-network and neutron to the extent that those involved
are ready for migration plans to be formulated and be put in place
* a summit session happened with notes and intentions[0]
* people took responsibility and promptly got swamped with other
responsibilities
* spec deadlines arose and in neutron's case have passed
* currently a neutron spec [1] is a work in progress (and it needs
significant work still) and a nova spec is required and doesn't have a
first draft or a champion

Where I would like to get to:
* I need people in addition to Oleg Bondarev to be available to help
come up with ideas and words to describe them to create the specs in a
very short amount of time (Oleg is doing great work and is a fabulous
person, yay Oleg, he just can't do this alone)
* specifically I need a contact on the nova side of this complex
problem, similar to Oleg on the neutron side
* we need to have a way for people involved with this effort to find
each other, talk to each other and track progress
* we need to have representation at both nova and neutron weekly
meetings to communicate status and needs

We are at K-2 and our current status is insufficient to expect this work
will be accomplished by the end of K-3. I will be championing this work,
in whatever state, so at least it doesn't fall off the map. If you would
like to help this effort please get in contact. I will be thinking of
ways to further this work and will be communicating to those who
identify as affected by these decisions in the most effective methods of
which I am capable.

Thank you to all who have gotten us as far as well have gotten in this
effort, it has been a long haul and you have all done great work. Let's
keep going and finish this.

Thank you,
Anita.

[0] https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron
[1] https://review.openstack.org/#/c/142456/

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

Re: [openstack-dev] Git client vulnerability

[Jeremy Stanley]

On 2014-12-19 13:34:06 + (+), Louis Taylor wrote:
> On Fri, Dec 19, 2014 at 01:19:48PM +, Jeremy Stanley wrote:
> > Please re-read that advisory[1]. GitHub's _servers_ were not
> > affected as this is a client-side vulnerability. What GitHub did was
> > release fixed versions of their "GitHub for Windows" and "GitHub for
> > Mac" _client_ tools.
> 
> Github's servers were patched such that is is now not possible to host a
> malicious repository on github servers, and attempts to push one will be
> rejected. This is mentioned in the advisory.

Yes, thanks, I phrased that poorly. GitHub's servers were not
vulnerable, but you are correct that they have added some mitigation
within their service to help shield as-of-yet unpatched clients from
the announced vulnerability.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [python-*client] py33 jobs seem to be failing

[Steve Martinelli]

Seems like https://review.openstack.org/#/c/142561/ fixed the issue.

As there haven't been any hits in logstash in roughly 24hrs, and we're 
getting clean builds in python-keystoneclient and openstackclient.

http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiTmFtZUVycm9yOiBuYW1lICdTdGFuZGFyZEVycm9yJyBpcyBub3QgZGVmaW5lZFwiIGJ1aWxkX3N0YXR1czonRkFJTFVSRSciLCJmaWVsZHMiOlsibWVzc2FnZSIsImJ1aWxkX25hbWUiLCJidWlsZF9zdGF0dXMiXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiIxNzI4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDE5MDA2NjI4MjM5fQ==

Steve

Amit Gandhi  wrote on 12/19/2014 11:19:46 AM:

> From: Amit Gandhi 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 12/19/2014 11:28 AM
> Subject: Re: [openstack-dev] [python-*client] py33 jobs seem to be 
failing
> 
> Is there an ETA for this fix?
> 
> Thanks
> Amit.
> 
> 
> > On Dec 17, 2014, at 3:38 PM, Jeremy Stanley  wrote:
> > 
> > On 2014-12-17 11:09:59 -0500 (-0500), Steve Martinelli wrote:
> > [...]
> >> The stack trace leads me to believe that docutils or sphinx is the
> >> culprit, but neither has released a new version in the time the
> >> bug has been around, so I'm not sure what the root cause of the
> >> problem is.
> > 
> > It's an unforeseen interaction between new PBR changes to support
> > Setuptools 8 and the way docutils supports Py3K by running 2to3
> > during installation (entrypoint scanning causes pre-translated
> > docutils to be loaded into the execution space through the egg-info
> > writer PBR grew to be able to record Git SHA details outside of
> > version strings). A solution is currently being developed.
> > -- 
> > Jeremy Stanley
> > 
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python-*client] py33 jobs seem to be failing

[Davanum Srinivas]

Amit,

from chatter on infra irc,. should be almost done if not already done.
if you see any jobs fail recheck, you may want to hop onto irc.

thanks,
dims

On Fri, Dec 19, 2014 at 11:19 AM, Amit Gandhi  wrote:
> Is there an ETA for this fix?
>
> Thanks
> Amit.
>
>
>> On Dec 17, 2014, at 3:38 PM, Jeremy Stanley  wrote:
>>
>> On 2014-12-17 11:09:59 -0500 (-0500), Steve Martinelli wrote:
>> [...]
>>> The stack trace leads me to believe that docutils or sphinx is the
>>> culprit, but neither has released a new version in the time the
>>> bug has been around, so I'm not sure what the root cause of the
>>> problem is.
>>
>> It's an unforeseen interaction between new PBR changes to support
>> Setuptools 8 and the way docutils supports Py3K by running 2to3
>> during installation (entrypoint scanning causes pre-translated
>> docutils to be loaded into the execution space through the egg-info
>> writer PBR grew to be able to record Git SHA details outside of
>> version strings). A solution is currently being developed.
>> --
>> Jeremy Stanley
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

[openstack-dev] Swift 2.2.1 released

[John Dickinson]

I'm happy to announce the release of Swift 2.2.1. The work of 28 contributors 
(including 8 first-time contributors), this release is definitely 
operator-centric. I recommend that you upgrade; as always you can upgrade to 
this release with no customer downtime.

Get the release: https://launchpad.net/swift/kilo/2.2.1
Full change log: https://github.com/openstack/swift/blob/master/CHANGELOG

Below I've highlighted a few of the more significant updates in this release.

* Swift now rejects object names with unicode surrogates. These unicode code 
points are not able to be encoded as UTF-8, so they are now formally rejected.

* Storage node error limits now survive a ring reload. Each Swift proxy server 
tracks errors when talking to a storage node. If a storage node sends too many 
errors, no further requests are sent to that node for a time. However, 
previously this error tracking was cleared with a ring reload, and a ring 
reload could happen frequently if some servers were being gradually added to 
the cluster. Now, the error tracking is not lost on ring reload, and error 
tracking is aggregated across storage polices. Basically, this means that the 
proxy server has a more accurate view of the health of the cluster and your 
cluster will be less stressed when you have failures and capacity adjustments 
at the same time.

* Clean up empty account and container partitions directories if they are 
empty. This keeps the system healthy and prevents a large number of empty 
directories from (significantly) slowing down the replication process.

* Swift now includes a full translation for Simplified Chinese (zh_CN locale).

I'd like to thank all of the Swift contributors for helping with this release. 
I'd especially like to thank the first-time contributors listed below:

Cedric Dos Santos
Martin Geisler
Filippo Giunchedi
Gregory Haynes
Daisuke Morita
Hisashi Osanai
Shilla Saebi
Pearl Yajing Tan


Thank you, and have a happy holiday season.


John





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

Re: [openstack-dev] [python-*client] py33 jobs seem to be failing

[Amit Gandhi]

Is there an ETA for this fix?

Thanks
Amit.


> On Dec 17, 2014, at 3:38 PM, Jeremy Stanley  wrote:
> 
> On 2014-12-17 11:09:59 -0500 (-0500), Steve Martinelli wrote:
> [...]
>> The stack trace leads me to believe that docutils or sphinx is the
>> culprit, but neither has released a new version in the time the
>> bug has been around, so I'm not sure what the root cause of the
>> problem is.
> 
> It's an unforeseen interaction between new PBR changes to support
> Setuptools 8 and the way docutils supports Py3K by running 2to3
> during installation (entrypoint scanning causes pre-translated
> docutils to be loaded into the execution space through the egg-info
> writer PBR grew to be able to record Git SHA details outside of
> version strings). A solution is currently being developed.
> -- 
> Jeremy Stanley
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [api] Analysis of current API design

[Amit Gandhi]

How do the allocation of the service types in the service catalog get created.

For example, looking at the link provided below for service catalogs [1], you 
have with Rackspace a service type of rax:queues (which is running zaqar).  
However in devstack, zaqar is listed as “messaging”.  FWIW i think the 
rackspace entry came before the devstack entry, but there is now an 
inconsistency.

How do new openstack related projects (that are not incubated/graduated) appear 
in the service catalog with a consistent service type name that can be used 
across providers with the confidence it refers to the same set of api's?  Is it 
just an assumption, or do we need a catalogue somewhere listing what each 
service type is associated with?  Does adding it to Devstack pretty much stake 
claim to the service type?

Thanks
Amit.





[1] 
https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog

> On Dec 18, 2014, at 11:19 PM, Everett Toews  
> wrote:
> 
> Hi All,
> 
> At the recent API WG meeting [1] we discussed the need for more analysis of 
> current API design.
> 
> We need to get better at doing analysis of current API design as part of our 
> guideline proposals. We are not creating these guidelines in a vacuum. The 
> current design should be analyzed and taken into account.
> 
> Naturally the type of analysis will vary from guideline to guideline but 
> backing your proposals with some kind of analysis will only make them better. 
> Let’s take some examples.
> 
> 1. Anne Gentle and I want to improve the consistency of service catalogs 
> across cloud providers both public and private. This is going to require the 
> analysis of many providers and we’ve got a start on it here [2]. Hopefully a 
> guideline for the service catalog should fall out of the analysis of the many 
> providers.
> 
> 2. There’s a guideline for metadata up for review [3]. I wasn’t aware of all 
> of the places where the concept of metadata is used in OpenStack so I did 
> some analysis [4]. I found that the representation was pretty consistent but 
> how metadata was CRUDed wasn’t as consistent. I hope that information can 
> help the review along.
> 
> 3. This Guideline for collection resources' representation structures [5] 
> basically codifies in a guideline what was found in the analysis. Good stuff 
> and it has definitely helped the review along.
> 
> For more information about analysis of current API design see #1 of How to 
> Contribute [5]
> 
> Any thoughts or feedback on the above?
> 
> Thanks,
> Everett
> 
> [1] 
> http://eavesdrop.openstack.org/meetings/api_wg/2014/api_wg.2014-12-18-16.00.log.html
> [2] 
> https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog
> [3] https://review.openstack.org/#/c/141229/
> [4] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Metadata
> [5] https://review.openstack.org/#/c/133660/
> [6] https://wiki.openstack.org/wiki/API_Working_Group#How_to_Contribute
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Cross distribution talks on Friday

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/11/14 20:26, Thomas Goirand wrote:
> On 11/01/2014 11:29 PM, Kashyap Chamarthy wrote:
>> On Sat, Nov 01, 2014 at 09:13:21PM +0800, Thomas Goirand wrote:
>>> Hi,
>>> 
>>> I was wondering if some distribution OpenStack package
>>> maintainers would be interested to have some cross-distribution
>>> discussion on Friday, during the contributors sessions.
>>> 
>>> I'll be happy to discuss with Ubuntu people, but not only. I'd
>>> like to meet also guys working with RedHat and Gentoo. I'm sure
>>> we may have some interesting things to share.
>>> 
>>> 
>>> OpenStack release management team would also be welcome.
>>> 
>>> If you are interested, please reply to this mail.
>> 
>> You might also want to start an etherpad instance with some
>> initial agenda notes and throw the URL here to guage interest.
> 
> Here's the etherpad: 
> https://etherpad.openstack.org/p/cross_distro_talks
> 
>> On a related note, a bunch of Fedora/RHEL/CentOS/Scientific
>> Linux packagers are planning[1] to meetup at the summit to
>> discuss RDO project packaging aspects, etc.
>> 
>> [1] https://etherpad.openstack.org/p/RDO_Meetup_Summit
> 
> Well, if you guys are only talking about RPM packaging, as I'm
> doing only Debian stuff [1], I'm only mildly interested. If we're
> going to talk more about packaging in general, then maybe.
> 
> On 11/02/2014 01:45 AM, Adam Young wrote:
>> Getting the whole "PBR version" issues cleared up would be huge.
> 
> I'm not sure what issue you are talking about, as I believe
> there's none. This has been discussed for about a year and a half
> before we finally had the OSLO_PACKAGE_VERSION to play with, when
> this was designed a few years ago. I'm now very happy about the way
> PBR does things, and wouldn't like it to change anything.
> Currently, what I do in Debian is (from the debian/rules file
> included from openstak-pkg-tools):
> 
> DEBVERS ?= $(shell dpkg-parsechangelog | sed -n -e 's/^Version:
> //p') VERSION ?= $(shell echo '$(DEBVERS)' | sed -e
> 's/^[[:digit:]]*://' -e 's/[-].*//') export
> OSLO_PACKAGE_VERSION=$(VERSION)

Note that OSLO_PACKAGE_VERSION is not public. Instead, we should use
PBR_VERSION:

http://docs.openstack.org/developer/pbr/packagers.html#versioning

> 
> You may not be familiar with dpkg-parsechangelog, so let me
> explain. Basically, if my debian/changelog has on top 2014.2~rc2,
> the debian/rules file will exports 2014.2~rc2 into the
> OSLO_PACKAGE_VERSION shell variable before doing "python setup.py
> install", and then PBR is smart enough to use that.
> 
> I am not at all a RedHat packaging specialist, but from the old
> time when I did some RPM porting from my Debian packages, I believe
> that in your .spec file, this should translate into something like
> this:
> 
> %install export OSLO_PACKAGE_VERSION=%{version} %{__python}
> setup.py install -O1 --skip-build --root %{buildroot}
> 
> Then everything should be ok and PBR will become your friend. I
> hope this helps and that I'm not writing any RPM packaging mistake!
> :)
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> [1] Here's the list of packages I maintain in Debian (only for
> OpenStack): 
> https://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org
>
> 
> 
> ___ OpenStack-dev
> mailing list OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUlEp/AAoJEC5aWaUY1u57f7cH+wVU4GQ324bfHp01kp8aG1fh
wIN6NoXnn9zuxtu1DcU+x+UhkPa9/nW61EPMJlHva+HVtmW4dY5obNSnMSP1l1cY
cTgY660nwxZByheGCv97FfzFQnetuNZpJ4E7k05EzrwsyOuW8IBPYyPhaRKj18Je
E5wVh6LqMQEYdrz0dWQ2YmuEkHHeOL4aNi/LCmNWP1vc5uaRTuXIIFIOz7dcvm/x
tW/s4fAlBBWEsjiat/WYzbKSNyVYcJYXwpPTBaNAMGygRJwRp5gAYBHqgD6FpuEN
i36hLQ6+dkDEMg0h3uHMU/UJ4qARhlZmRC/Hj9GMdDD9YGLLsDo/lzllm/iODWs=
=TGl4
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Mistral] Plans to load and performance testing

[Anastasia Kuznetsova]

Boris,

Thanks for feedback!

> But I belive that you should put bigger load here:
https://etherpad.openstack.org/p/mistral-rally-testing-results

As I said it is only beginning and  I will increase the load and change its
type.

>As well concurrency should be at least 2-3 times bigger than times
otherwise it won't generate proper load and you won't collect >enough data
for statistical analyze.
>
>As well use  "rps" runner that generates more real life load.
>Plus it will be nice to share as well output of "rally task report"
command.

Thanks for the advice, I will consider it in further testing and reporting.

Answering to your question about using Rally for integration testing, as I
mentioned in our load testing plan published on wiki page,  one of our
final goals is to have a Rally gate in one of Mistral repositories, so we
are interested in it and I already prepare first commits to Rally.

Thanks,
Anastasia Kuznetsova

On Fri, Dec 19, 2014 at 4:51 PM, Boris Pavlovic 
wrote:
>
> Anastasia,
>
> Nice work on this. But I belive that you should put bigger load here:
> https://etherpad.openstack.org/p/mistral-rally-testing-results
>
> As well concurrency should be at least 2-3 times bigger than times
> otherwise it won't generate proper load and you won't collect enough data
> for statistical analyze.
>
> As well use  "rps" runner that generates more real life load.
> Plus it will be nice to share as well output of "rally task report"
> command.
>
>
> By the way what do you think about using Rally scenarios (that you already
> wrote) for integration testing as well?
>
>
> Best regards,
> Boris Pavlovic
>
> On Fri, Dec 19, 2014 at 2:39 PM, Anastasia Kuznetsova <
> akuznets...@mirantis.com> wrote:
>>
>> Hello everyone,
>>
>> I want to announce that Mistral team has started work on load and
>> performance testing in this release cycle.
>>
>> Brief information about scope of our work can be found here:
>>
>> https://wiki.openstack.org/wiki/Mistral/Testing#Load_and_Performance_Testing
>>
>> First results are published here:
>> https://etherpad.openstack.org/p/mistral-rally-testing-results
>>
>> Thanks,
>> Anastasia Kuznetsova
>> @ Mirantis Inc.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Providing instance's guest OS with data (ssh keys, root password, hostname)

[Dmitry Guryanov]

On Friday 19 December 2014 14:38:29 Daniel P. Berrange wrote:
> On Fri, Dec 19, 2014 at 05:34:19PM +0300, Dmitry Guryanov wrote:
> > On Friday 19 December 2014 14:17:34 Daniel P. Berrange wrote:
> > > On Fri, Dec 19, 2014 at 05:11:57PM +0300, Dmitry Guryanov wrote:
> > > > Hello,
> > > > 
> > > > If I understood correctly, there are 3 ways to provide guest OS with
> > > > some
> > > > data (SSH keys, for example):
> > > > 
> > > > 1. mount guest root fs on host (with libguestfs) and copy data there.
> > > > 2. config drive and cloud-init
> > > > 3. nova metadata service and cloud-init
> > > > 
> > > > 
> > > > All 3 methods do almost the same thing and can be enabled or disabled
> > > > in
> > > > nova config file. So which one is preferred? How do people usually
> > > > configure their openstack clusters?
> > > > 
> > > > I'm asking, because we are going to extend nova/libvirt driver to
> > > > support
> > > > our virtualization solution (parallels driver in libvirt) and it seems
> > > > it
> > > > will not work as is and requires some development. Which method is
> > > > first-priority and used by most people?
> > > 
> > > I'd probably prioritize in this order:
> > >   1. config drive and cloud-init
> > >   2. nova metadata service and cloud-init
> > >   3. mount guest root fs on host (with libguestfs) and copy data there.
> > > 
> > > but there's not much to choose between 1 & 2.
> > 
> > Thanks! Config drive already works for VMs, need to check how it will work
> > with containers, since we can't add cdrom there.
> 
> There are currently two variables wrt config drive
> 
>  - device type - cdrom vs disk
>  - filesystem  - vfat vs iso9660
> 
> For your fully virt machines I'd probably just stick with the default
> that ibvirt already supports.
> 
> When we discussed this for LXC, we came to the conclusion that for
> containers we shouldn't try to expose a block device at all. Instead
> just mount the contents of the config drive at the directory location
> that cloud-init wants the data (it was somewhere under /var/ but I
> can't remember where right now).  I think the same makes sense for
> parallels' container based guests.

That's good news, we have functions to mount host dir to container
in PCS, so we just need to add it to libvirt driver.

> 
> Regards,
> Daniel

-- 
Dmitry Guryanov

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

[openstack-dev] [OpenStack-dev][nova-net]Floating ip assigned as /32 from the start of the range

[Eduard Matei]

Hi,
I'm trying to create a vm and assign it an ip in range 10.100.130.0/16.
On the host, the ip is assigned to br100 as  inet 10.100.0.3/32 scope
global br100
instead of 10.100.130.X/16, so it's not reachable from the outside.

The localrc.conf :
FLOATING_RANGE=10.100.130.0/16

Any idea what to change?

Thanks,
Eduard


-- 

*Eduard Biceri Matei, Senior Software Developer*
www.cloudfounders.com
 | eduard.ma...@cloudfounders.com



*CloudFounders, The Private Cloud Software Company*

Disclaimer:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed.
If you are not the named addressee or an employee or agent responsible
for delivering this message to the named addressee, you are hereby
notified that you are not authorized to read, print, retain, copy or
disseminate this message or any part of it. If you have received this
email in error we request you to notify us by reply e-mail and to
delete all electronic files of the message. If you are not the
intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the content of this
message, and shall have no liability for any loss or damage suffered
by the user, which arise as a result of e-mail transmission.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Lets not assume everyone is using the global `CONF` object (zaqar broken by latest keystoneclient release 1.0)

[Flavio Percoco]

On 19/12/14 09:07 -0500, Doug Hellmann wrote:


On Dec 19, 2014, at 7:17 AM, Flavio Percoco  wrote:


Greetings,

DISCLAIMER: The following comments are neither finger pointing the
author of this work nor the keystone team.

RANT: We should really stop assuming everyone is using a global `CONF`
object. Moreover, we should really stop using it, especially in
libraries.

That said, here's a gentle note for all of us:

If I understood the flow of changes correctly, keystoneclient recently
introduced a auth_section[0] option, which needs to be registered in
order for it to work properly. In keystoneclient, it's been correctly
added a function[1] to register this option in a conf object.

keystonemiddleware was then updated to support the above and a call to
the register function[1] was then added to the `auth_token` module[2].

The above, unfortunately, broke Zaqar's auth because Zaqar is not
using the global `CONF` object which means it has to register
keystonemiddleware's options itself. Since the option was registered
in the global conf instead of the conf object passed to
`AuthProtocol`, the new `auth_section` option is not bein registered
as keystoneclient excepts.

So, as a gentle reminder to everyone, please, lets not assume all
projects are using the global `CONF` object and make sure all libraries
provide a good way to register the required options. I think either
secretly registering options or exposing a function to let consumers
do so is fine.

I hate complaining without helping to solve the problem so, here's[3] a
workaround to provide a, hopefully, better way to do this. Note that
this shouldn't be the definitive fix and that we also implemented a
workaround in zaqar as well.


That change will fix the issue, but a better solution is to have the code in 
keystoneclient that wants the options handle the registration at runtime. It 
looks like keystoneclient/auth/conf.py:load_from_conf_options() is at least one 
place that’s needed, there may be others.


Fully agree!

--
@flaper87
Flavio Percoco


pgpYoDTaszEE1.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][sriov] SRIOV related specs pending for approval

[Robert Li (baoli)]

Hi Joe,

See this thread on the SR-IOV CI from Irena and Sandhya:

http://lists.openstack.org/pipermail/openstack-dev/2014-November/050658.html

http://lists.openstack.org/pipermail/openstack-dev/2014-November/050755.html

I believe that Intel is building a CI system to test SR-IOV as well.

Thanks,
Robert


On 12/18/14, 9:13 PM, "Joe Gordon" 
mailto:joe.gord...@gmail.com>> wrote:



On Thu, Dec 18, 2014 at 2:18 PM, Robert Li (baoli) 
mailto:ba...@cisco.com>> wrote:
Hi,

During the Kilo summit, the folks in the pci passthrough and SR-IOV groups 
discussed what we’d like to achieve in this cycle, and the result was 
documented in this Etherpad:
https://etherpad.openstack.org/p/kilo_sriov_pci_passthrough

To get the work going, we’ve submitted a few design specs:

Nova: Live migration with macvtap SR-IOV
https://blueprints.launchpad.net/nova/+spec/sriov-live-migration

Nova: sriov interface attach/detach
https://blueprints.launchpad.net/nova/+spec/sriov-interface-attach-detach

 Nova: Api specify vnic_type
https://blueprints.launchpad.net/neutron/+spec/api-specify-vnic-type

Neutron-Network settings support for vnic-type
https://blueprints.launchpad.net/neutron/+spec/network-settings-support-vnic-type

Nova: SRIOV scheduling with stateless offloads
https://blueprints.launchpad.net/nova/+spec/sriov-sched-with-stateless-offloads

Now that the specs deadline is approaching, I’d like to bring them up in here 
for exception considerations. A lot of works have been put into them. And we’d 
like to see them get through for Kilo.

We haven't started the spec exception process yet.


Regarding CI for PCI passthrough and SR-IOV, see the attached thread.

Can you share this via a link to something on 
http://lists.openstack.org/pipermail/openstack-dev/


thanks,
Robert


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


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

Re: [openstack-dev] [Nova] Providing instance's guest OS with data (ssh keys, root password, hostname)

[Daniel P. Berrange]

On Fri, Dec 19, 2014 at 05:34:19PM +0300, Dmitry Guryanov wrote:
> On Friday 19 December 2014 14:17:34 Daniel P. Berrange wrote:
> > On Fri, Dec 19, 2014 at 05:11:57PM +0300, Dmitry Guryanov wrote:
> > > Hello,
> > > 
> > > If I understood correctly, there are 3 ways to provide guest OS with some
> > > data (SSH keys, for example):
> > > 
> > > 1. mount guest root fs on host (with libguestfs) and copy data there.
> > > 2. config drive and cloud-init
> > > 3. nova metadata service and cloud-init
> > > 
> > > 
> > > All 3 methods do almost the same thing and can be enabled or disabled in
> > > nova config file. So which one is preferred? How do people usually
> > > configure their openstack clusters?
> > > 
> > > I'm asking, because we are going to extend nova/libvirt driver to support
> > > our virtualization solution (parallels driver in libvirt) and it seems it
> > > will not work as is and requires some development. Which method is
> > > first-priority and used by most people?
> > 
> > I'd probably prioritize in this order:
> > 
> >   1. config drive and cloud-init
> >   2. nova metadata service and cloud-init
> >   3. mount guest root fs on host (with libguestfs) and copy data there.
> > 
> > but there's not much to choose between 1 & 2.
> 
> Thanks! Config drive already works for VMs, need to check how it will work 
> with containers, since we can't add cdrom there.

There are currently two variables wrt config drive

 - device type - cdrom vs disk
 - filesystem  - vfat vs iso9660

For your fully virt machines I'd probably just stick with the default
that ibvirt already supports.

When we discussed this for LXC, we came to the conclusion that for
containers we shouldn't try to expose a block device at all. Instead
just mount the contents of the config drive at the directory location
that cloud-init wants the data (it was somewhere under /var/ but I
can't remember where right now).  I think the same makes sense for
parallels' container based guests.

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

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

Re: [openstack-dev] Fwd: Re: [Nova] Providing instance's guest OS with data (ssh keys, root password, hostname)

[Dmitry Guryanov]

On Friday 19 December 2014 17:27:18 Dmitry Guryanov wrote:

Sorry, forwarded to wrong list


> --  Forwarded Message  --
> 
> Subject: Re: [openstack-dev] [Nova] Providing instance's guest OS with data
> (ssh keys, root password, hostname)
> Date: Friday 19 December 2014, 14:17:34
> From: Daniel P. Berrange 
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> 
> Dmitry GuryanovOn Fri, Dec 19, 2014 at 05:11:57PM +0300,  wrote:
> > Hello,
> > 
> > If I understood correctly, there are 3 ways to provide guest OS with some
> 
> data
> 
> > (SSH keys, for example):
> > 
> > 1. mount guest root fs on host (with libguestfs) and copy data there.
> > 2. config drive and cloud-init
> > 3. nova metadata service and cloud-init
> > 
> > 
> > All 3 methods do almost the same thing and can be enabled or disabled in
> 
> nova
> 
> > config file. So which one is preferred? How do people usually configure
> 
> their
> 
> > openstack clusters?
> > 
> > I'm asking, because we are going to extend nova/libvirt driver to support
> 
> our
> 
> > virtualization solution (parallels driver in libvirt) and it seems it will
> 
> not
> 
> > work as is and requires some development. Which method is first-priority
> > and used by most people?
> 
> I'd probably prioritize in this order:
> 
>   1. config drive and cloud-init
>   2. nova metadata service and cloud-init
>   3. mount guest root fs on host (with libguestfs) and copy data there.
> 
> but there's not much to choose between 1 & 2.
> 
> NB, option 3 isn't actually hardcoded to use libguestfs - it falls back
> to using loop devices / local mounts, albeit less secure, so not really
> recommended. At some point option 3 may be removed from Nova entirely
> since the first two options are preferred & more reliable in general.
> 
> Regards,
> Daniel

-- 
Dmitry Guryanov

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

Re: [openstack-dev] [Nova] Providing instance's guest OS with data (ssh keys, root password, hostname)

[Dmitry Guryanov]

On Friday 19 December 2014 14:17:34 Daniel P. Berrange wrote:
> On Fri, Dec 19, 2014 at 05:11:57PM +0300, Dmitry Guryanov wrote:
> > Hello,
> > 
> > If I understood correctly, there are 3 ways to provide guest OS with some
> > data (SSH keys, for example):
> > 
> > 1. mount guest root fs on host (with libguestfs) and copy data there.
> > 2. config drive and cloud-init
> > 3. nova metadata service and cloud-init
> > 
> > 
> > All 3 methods do almost the same thing and can be enabled or disabled in
> > nova config file. So which one is preferred? How do people usually
> > configure their openstack clusters?
> > 
> > I'm asking, because we are going to extend nova/libvirt driver to support
> > our virtualization solution (parallels driver in libvirt) and it seems it
> > will not work as is and requires some development. Which method is
> > first-priority and used by most people?
> 
> I'd probably prioritize in this order:
> 
>   1. config drive and cloud-init
>   2. nova metadata service and cloud-init
>   3. mount guest root fs on host (with libguestfs) and copy data there.
> 
> but there's not much to choose between 1 & 2.

Thanks! Config drive already works for VMs, need to check how it will work 
with containers, since we can't add cdrom there.

> 
> NB, option 3 isn't actually hardcoded to use libguestfs - it falls back
> to using loop devices / local mounts, albeit less secure, so not really
> recommended. At some point option 3 may be removed from Nova entirely
> since the first two options are preferred & more reliable in general.

I see!

I actually know that libguestfs is optional, just provided it as an example 
how nova mounts disks. BTW it will not reduce security level for containers, 
because we mount root fs on host to start it.

> 
> Regards,
> Daniel

-- 
Dmitry Guryanov

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

[openstack-dev] Fwd: Re: [Nova] Providing instance's guest OS with data (ssh keys, root password, hostname)

[Dmitry Guryanov]

--  Forwarded Message  --

Subject: Re: [openstack-dev] [Nova] Providing instance's guest OS with data 
(ssh keys, root password, hostname)
Date: Friday 19 December 2014, 14:17:34
From: Daniel P. Berrange 
To: OpenStack Development Mailing List (not for usage questions) 

Dmitry GuryanovOn Fri, Dec 19, 2014 at 05:11:57PM +0300,  wrote:
> Hello,
> 
> If I understood correctly, there are 3 ways to provide guest OS with some 
data 
> (SSH keys, for example):
> 
> 1. mount guest root fs on host (with libguestfs) and copy data there.
> 2. config drive and cloud-init
> 3. nova metadata service and cloud-init
> 
> 
> All 3 methods do almost the same thing and can be enabled or disabled in 
nova 
> config file. So which one is preferred? How do people usually configure 
their 
> openstack clusters?
> 
> I'm asking, because we are going to extend nova/libvirt driver to support 
our 
> virtualization solution (parallels driver in libvirt) and it seems it will 
not 
> work as is and requires some development. Which method is first-priority and 
> used by most people?

I'd probably prioritize in this order:

  1. config drive and cloud-init
  2. nova metadata service and cloud-init
  3. mount guest root fs on host (with libguestfs) and copy data there.

but there's not much to choose between 1 & 2.

NB, option 3 isn't actually hardcoded to use libguestfs - it falls back
to using loop devices / local mounts, albeit less secure, so not really
recommended. At some point option 3 may be removed from Nova entirely
since the first two options are preferred & more reliable in general.

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

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

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

Re: [openstack-dev] [Nova] Providing instance's guest OS with data (ssh keys, root password, hostname)

[Daniel P. Berrange]

On Fri, Dec 19, 2014 at 05:11:57PM +0300, Dmitry Guryanov wrote:
> Hello,
> 
> If I understood correctly, there are 3 ways to provide guest OS with some 
> data 
> (SSH keys, for example):
> 
> 1. mount guest root fs on host (with libguestfs) and copy data there.
> 2. config drive and cloud-init
> 3. nova metadata service and cloud-init
> 
> 
> All 3 methods do almost the same thing and can be enabled or disabled in nova 
> config file. So which one is preferred? How do people usually configure their 
> openstack clusters?
> 
> I'm asking, because we are going to extend nova/libvirt driver to support our 
> virtualization solution (parallels driver in libvirt) and it seems it will 
> not 
> work as is and requires some development. Which method is first-priority and 
> used by most people?

I'd probably prioritize in this order:

  1. config drive and cloud-init
  2. nova metadata service and cloud-init
  3. mount guest root fs on host (with libguestfs) and copy data there.

but there's not much to choose between 1 & 2.

NB, option 3 isn't actually hardcoded to use libguestfs - it falls back
to using loop devices / local mounts, albeit less secure, so not really
recommended. At some point option 3 may be removed from Nova entirely
since the first two options are preferred & more reliable in general.

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

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

[openstack-dev] [Nova] Providing instance's guest OS with data (ssh keys, root password, hostname)

[Dmitry Guryanov]

Hello,

If I understood correctly, there are 3 ways to provide guest OS with some data 
(SSH keys, for example):

1. mount guest root fs on host (with libguestfs) and copy data there.
2. config drive and cloud-init
3. nova metadata service and cloud-init


All 3 methods do almost the same thing and can be enabled or disabled in nova 
config file. So which one is preferred? How do people usually configure their 
openstack clusters?

I'm asking, because we are going to extend nova/libvirt driver to support our 
virtualization solution (parallels driver in libvirt) and it seems it will not 
work as is and requires some development. Which method is first-priority and 
used by most people? 

-- 
Dmitry Guryanov

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

Re: [openstack-dev] [all] Lets not assume everyone is using the global `CONF` object (zaqar broken by latest keystoneclient release 1.0)

[Doug Hellmann]

On Dec 19, 2014, at 7:17 AM, Flavio Percoco  wrote:

> Greetings,
> 
> DISCLAIMER: The following comments are neither finger pointing the
> author of this work nor the keystone team.
> 
> RANT: We should really stop assuming everyone is using a global `CONF`
> object. Moreover, we should really stop using it, especially in
> libraries.
> 
> That said, here's a gentle note for all of us:
> 
> If I understood the flow of changes correctly, keystoneclient recently
> introduced a auth_section[0] option, which needs to be registered in
> order for it to work properly. In keystoneclient, it's been correctly
> added a function[1] to register this option in a conf object.
> 
> keystonemiddleware was then updated to support the above and a call to
> the register function[1] was then added to the `auth_token` module[2].
> 
> The above, unfortunately, broke Zaqar's auth because Zaqar is not
> using the global `CONF` object which means it has to register
> keystonemiddleware's options itself. Since the option was registered
> in the global conf instead of the conf object passed to
> `AuthProtocol`, the new `auth_section` option is not bein registered
> as keystoneclient excepts.
> 
> So, as a gentle reminder to everyone, please, lets not assume all
> projects are using the global `CONF` object and make sure all libraries
> provide a good way to register the required options. I think either
> secretly registering options or exposing a function to let consumers
> do so is fine.
> 
> I hate complaining without helping to solve the problem so, here's[3] a
> workaround to provide a, hopefully, better way to do this. Note that
> this shouldn't be the definitive fix and that we also implemented a
> workaround in zaqar as well.

That change will fix the issue, but a better solution is to have the code in 
keystoneclient that wants the options handle the registration at runtime. It 
looks like keystoneclient/auth/conf.py:load_from_conf_options() is at least one 
place that’s needed, there may be others.

Doug

> 
> Cheers,
> Flavio
> 
> [0] 
> https://github.com/openstack/python-keystoneclient/blob/41afe3c963fa01f61b67c44e572eee34b0972382/keystoneclient/auth/conf.py#L20
> [1] 
> https://github.com/openstack/python-keystoneclient/blob/41afe3c963fa01f61b67c44e572eee34b0972382/keystoneclient/auth/conf.py#L49
> [2] 
> https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L356
> [3] https://review.openstack.org/143063
> 
> -- 
> @flaper87
> Flavio Percoco
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [qa] neutron "client returns one value" has finally merged

[David Kranz]

Neutron patches can resume as  normal. Thanks for the patience.

 -David

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

Re: [openstack-dev] [Mistral] Plans to load and performance testing

[Boris Pavlovic]

Anastasia,

Nice work on this. But I belive that you should put bigger load here:
https://etherpad.openstack.org/p/mistral-rally-testing-results

As well concurrency should be at least 2-3 times bigger than times
otherwise it won't generate proper load and you won't collect enough data
for statistical analyze.

As well use  "rps" runner that generates more real life load.
Plus it will be nice to share as well output of "rally task report" command.


By the way what do you think about using Rally scenarios (that you already
wrote) for integration testing as well?


Best regards,
Boris Pavlovic

On Fri, Dec 19, 2014 at 2:39 PM, Anastasia Kuznetsova <
akuznets...@mirantis.com> wrote:
>
> Hello everyone,
>
> I want to announce that Mistral team has started work on load and
> performance testing in this release cycle.
>
> Brief information about scope of our work can be found here:
>
> https://wiki.openstack.org/wiki/Mistral/Testing#Load_and_Performance_Testing
>
> First results are published here:
> https://etherpad.openstack.org/p/mistral-rally-testing-results
>
> Thanks,
> Anastasia Kuznetsova
> @ Mirantis Inc.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Git client vulnerability

[Louis Taylor]

On Fri, Dec 19, 2014 at 01:19:48PM +, Jeremy Stanley wrote:
> Please re-read that advisory[1]. GitHub's _servers_ were not
> affected as this is a client-side vulnerability. What GitHub did was
> release fixed versions of their "GitHub for Windows" and "GitHub for
> Mac" _client_ tools.

Github's servers were patched such that is is now not possible to host a
malicious repository on github servers, and attempts to push one will be
rejected. This is mentioned in the advisory.


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

Re: [openstack-dev] Git client vulnerability

[Jeremy Stanley]

On 2014-12-19 13:35:06 +0100 (+0100), Dr. Jens Rosenboom wrote:
[...]
> While github.com claim to have patched their servers, people using
> other repos may want to be extra cautious.

Please re-read that advisory[1]. GitHub's _servers_ were not
affected as this is a client-side vulnerability. What GitHub did was
release fixed versions of their "GitHub for Windows" and "GitHub for
Mac" _client_ tools.

That said, people using Git (and apparently Mercurial[2]?) clients
on non-case-sensitive filesystems (that's mainly Windows and Mac,
not typical Linux/BSD) are at risk if they haven't upgraded their
client applications accordingly.

[1] https://github.com/blog/1938-vulnerability-announced-update-your-git-clients
[2] http://www.openwall.com/lists/oss-security/2014/12/19/1
-- 
Jeremy Stanley

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

[openstack-dev] Git client vulnerability

[Dr. Jens Rosenboom]

As this may affect a reasonable percentage of the target audience, I 
would like to make everyone aware of


https://github.com/blog/1938-vulnerability-announced-update-your-git-clients

While github.com claim to have patched their servers, people using other 
repos may want to be extra cautious.


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

[openstack-dev] [cinder] Grouping Multiple Backend provider

[Chhavi Agarwal]

To be more clear let me explain it with the help of a use case :-
Consider I have 4 registered storage providers SVC, LVM, EMC, HDS
I want to use to 2  ( SVC, LVM )  providers for Task1
other 2 ( EMC, HDS ) providers for Task2.

Is it possible to have a filter which can be used for a set of volume
drivers.

I tried below multi-backend providers but it by default calls the
CapacityFilter and tries to process all the registered providers.

Thanks & Regards,
Chhavi Agarwal
Cloud System Software Group.




From:   Chhavi Agarwal/India/IBM@IBMIN
To: openstack-dev@lists.openstack.org
Cc: Shyama Venugopal/India/IBM@IBMIN, Monica O
Joshi/India/IBM@IBMIN, Imranuddin W Kazi/India/IBM@IBMIN
Date:   12/18/2014 09:25 PM
Subject:[openstack-dev] [cinder] Multiple Backend for different
volume_types




Hi All,

As per the below link multi-backend support :-
https://wiki.openstack.org/wiki/Cinder-multi-backend

Its mentioned that we currently only support passing a multi backend
provider per volume_type. "There can be > 1 backend per volume_type, and
the capacity scheduler kicks in and keeps the backends of a particular
volume_type "

Is there a way to support multi backend provider across different
volume_type. For eg if I want my volume_type to have both SVC and LVM
drivers to be passed as my backend provider.

Thanks & Regards,
Chhavi Agarwal
Cloud System Software Group.



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




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

[openstack-dev] [all] Lets not assume everyone is using the global `CONF` object (zaqar broken by latest keystoneclient release 1.0)

[Flavio Percoco]

Greetings,

DISCLAIMER: The following comments are neither finger pointing the
author of this work nor the keystone team.

RANT: We should really stop assuming everyone is using a global `CONF`
object. Moreover, we should really stop using it, especially in
libraries.

That said, here's a gentle note for all of us:

If I understood the flow of changes correctly, keystoneclient recently
introduced a auth_section[0] option, which needs to be registered in
order for it to work properly. In keystoneclient, it's been correctly
added a function[1] to register this option in a conf object.

keystonemiddleware was then updated to support the above and a call to
the register function[1] was then added to the `auth_token` module[2].

The above, unfortunately, broke Zaqar's auth because Zaqar is not
using the global `CONF` object which means it has to register
keystonemiddleware's options itself. Since the option was registered
in the global conf instead of the conf object passed to
`AuthProtocol`, the new `auth_section` option is not bein registered
as keystoneclient excepts.

So, as a gentle reminder to everyone, please, lets not assume all
projects are using the global `CONF` object and make sure all libraries
provide a good way to register the required options. I think either
secretly registering options or exposing a function to let consumers
do so is fine.

I hate complaining without helping to solve the problem so, here's[3] a
workaround to provide a, hopefully, better way to do this. Note that
this shouldn't be the definitive fix and that we also implemented a
workaround in zaqar as well.

Cheers,
Flavio

[0] 
https://github.com/openstack/python-keystoneclient/blob/41afe3c963fa01f61b67c44e572eee34b0972382/keystoneclient/auth/conf.py#L20
[1] 
https://github.com/openstack/python-keystoneclient/blob/41afe3c963fa01f61b67c44e572eee34b0972382/keystoneclient/auth/conf.py#L49
[2] 
https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L356
[3] https://review.openstack.org/143063

--
@flaper87
Flavio Percoco


pgpZwjK8HSrg1.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] Bootstrap NTP sync.

[Stanislaw Bogatkin]

Hi Tomasz,
External NTP is good, but we should be able to deploy w/o internet access
(but slaves should be in sync with master node), so sync with master node
is better. I understand that it's slightly against standards - but at that
moment we just obligatoriness to be in sync with master node, cause some of
followed tasks depends on synced time.

On Fri, Dec 19, 2014 at 2:12 PM, Tomasz Napierala 
wrote:
>
>
> > On 19 Dec 2014, at 10:00, Stanislaw Bogatkin 
> wrote:
> >
> > Hi guys,
> >
> > We have a little concern related to Fuel bootstrap node NTP sync.
> Currently we trying to sync time on bootstrap node with master node, but
> problem is that NTP protocol has long convergence time, so if we just
> install master node and right after that try to start some bootstrap node -
> bootstrap fails to sync time with master due to that fact that master
> doesn't appear as "trust time source" at that moment.
> > How we can solve that problem:
> >
> > 1. We can start bootstrap long time after master (when master will
> convergence it's time) - seems that it's a bad idea, cause master node
> convergence time depends on upstream NTP servers and may be quite long -
> user shouldn't wait so long time to just start bootstrap node.
> >
> > 2. We can use master local time as "trust" forcibly - actually, we
> already do that for case when master is a bare metal node. We can do it for
> virtual node too, it is not such bad idea as many can say, especially when
> master node stratum will low (10-12).
> >
> > 3. We can mask return value for bootstrap node ntpdate service such way
> that it always will return success - it's a dirty hack, it will calm down
> customers, but it doesn't solve problem - time will be unsynced.
> >
> > As for me - second option is best. What do you think about it?
>
> Second option looks best, although it’s still against standards. I guess
> that if we provide possibility to deifne external NTP server as an
> alternative, we are hsfa here and can live with that.
>
> Regards,
> --
> Tomasz 'Zen' Napierala
> Sr. OpenStack Engineer
> tnapier...@mirantis.com
>
>
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Mistral] ActionProvider

[Renat Akhmerov]

Yeah,

We had a very productive discussion with Winson today and he’s going to prepare 
more formal specification on what he’s suggesting. I’d like to say in advance 
though that I really really like it in terms of what it will allow to do.

Renat Akhmerov
@ Mirantis Inc.



> On 19 Dec 2014, at 17:11, Anastasia Kuznetsova  
> wrote:
> 
> Winson, Renat,
> 
> I think that it is a good idea. Moreover, it is relevant, because about a 
> month ago there was a question from one guy in our IRC channel about what if 
> some of other 3rd party systems which provide their own client bindings (in 
> python) want to integrate with Mistral, how it will work. For that moment we 
> just thought about it, but hadn't any blueprints or discussions.
> 
> Thanks,
> Anastasia Kuznetsova
> @ Mirantis Inc.
> 
> 
> On Thu, Dec 18, 2014 at 9:33 AM, Renat Akhmerov  > wrote:
> Winson,
> 
> The idea itself makes a lot of sense to me because we’ve had a number of 
> discussions about how we could make action subsystem even more pluggable and 
> flexible. One of the questions that we’d like to solve is to be able to add 
> actions “on the fly” and at the same time stay safe. I think this whole thing 
> is about specific technical details so I would like to see more of them. 
> Generally speaking, you’re right about actions residing in a database, about 
> 3 months ago we made this refactoring and put all actions into db but it may 
> not be 100% necessary. Btw, we already have a concept of action generator 
> that we use to automatically build OpenStack actions so you can take a look 
> at how they work. Long story short… We’ve already made some steps towards 
> being more flexible and have some facilities that could be further improved.
> 
> Again, the idea is very interesting to me (and not only to me). Please share 
> the details.
> 
> Thanks
> 
> Renat Akhmerov
> @ Mirantis Inc.
> 
> 
> 
> > On 17 Dec 2014, at 13:22, W Chan  > > wrote:
> >
> > Renat,
> >
> > We want to introduce the concept of an ActionProvider to Mistral.  We are 
> > thinking that with an ActionProvider, a third party system can extend 
> > Mistral with it's own action catalog and set of dedicated and specialized 
> > action executors.  The ActionProvider will return it's own list of actions 
> > via an abstract interface.  This minimizes the complexity and latency in 
> > managing and sync'ing the Action table.  In the DSL, we can define provider 
> > specific context/configuration separately and apply to all provider 
> > specific actions without explicitly passing as inputs.  WDYT?
> >
> > Winson
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [mistral] Mistral Kilo-1 development milestone released

[Renat Akhmerov]

Hi,

Mistral Kilo-1 (tagged as 2015.1.0b1) has been released.

In this release we completed 10 blueprints and fixed 18 bugs.  The most 
noticeable achievements are:

Fully completed direct workflow “join” control which remarkably enriches 
variety of ways that user can build workflows. “join" allows to synchronize 
multiple routes running in parallel in a workflow and merge their results their 
results for further processing. Two examples of that have been added into 
mistral-extra project (see “send_tenant_stat_join” workflow in 
tenant_statistics.yaml workbook and workflow create_vm_and_volume.yaml)
Any workflow now finally can be correctly resumed if it was previously paused.
Partially completed “for-each” task execution pattern that allows processing 
multiple items passed as a collection to a task. This feature is now 
experimental and the team is actively working on stabilizing it: both design 
and implementation.
“pause-before” task policy which in conjunction with workflow resume can be 
used to run workflows in what can be called “debug mode” or step by step. This, 
however, is not all that the Team is planning to do on that topic. Even more 
exciting capabilities like running workflows in “dry run” mode and allowing 
"human interventions in case of errors and resuming workflows" are on the 
roadmap.
Task-executor affinity with using “target” task property. Tasks can be 
configured to be running only on a certain group of executors.
Fixed a number bugs with authentication and multitenancy support.
Significantly improved integration testing.
And finally we started HA testing & Benchmarking with Rally and got first 
results. This work will be consistently going on. All ideas and results on 
testing will be shared and everyone is welcome to contribute their vision and 
experience.

Mistral Server and Mistral Client release launchpad pages:
https://launchpad.net/mistral/kilo/kilo-1 
 
https://launchpad.net/python-mistralclient/kilo/kilo-1 
 

Thanks

P.S.: We’ve made a decision to follow all the release procedures adopted for 
official OpenStack projects to simplify future incubation and integration and 
from now on all terms, principles and versioning will be corresponding.

Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

[Eduard Matei]

Hi all,
After a little struggle with the config scripts i managed to get a working
setup that is able to process openstack-dev/sandbox and run
noop-check-comunication.

Then, i tried enabling dsvm-tempest-full job but it keeps returning
"NOT_REGISTERED"

2014-12-19 12:07:14,683 INFO zuul.IndependentPipelineManager: Change
 depends on changes []
2014-12-19 12:07:14,683 INFO zuul.Gearman: Launch job
noop-check-communication for change  with
dependent changes []
2014-12-19 12:07:14,693 INFO zuul.Gearman: Launch job dsvm-tempest-full for
change  with dependent changes []
2014-12-19 12:07:14,694 ERROR zuul.Gearman: Job  is not registered with Gearman
2014-12-19 12:07:14,694 INFO zuul.Gearman: Build  complete, result NOT_REGISTERED
2014-12-19 12:07:14,765 INFO zuul.Gearman: Build  started
2014-12-19 12:07:14,910 INFO zuul.Gearman: Build  complete, result SUCCESS
2014-12-19 12:07:14,916 INFO zuul.IndependentPipelineManager: Reporting
change , actions: [, {'verified': -1}>]

Nodepoold's log show no reference to dsvm-tempest-full and neither jenkins'
logs.

Any idea how to enable this job?

Also, i got the "Cloud provider" setup and i can access it from the jenkins
master.
Any idea how i can manually trigger dsvm-tempest-full job to run and test
the cloud provider without having to push a review to Gerrit?

Thanks,
Eduard

On Thu, Dec 18, 2014 at 7:52 PM, Eduard Matei <
eduard.ma...@cloudfounders.com> wrote:
>
> Thanks for the input.
>
> I managed to get another master working (on Ubuntu 13.10), again with some
> issues since it was already setup.
> I'm now working towards setting up the slave.
>
> Will add comments to those reviews.
>
> Thanks,
> Eduard
>
> On Thu, Dec 18, 2014 at 7:42 PM, Asselin, Ramy 
> wrote:
>
>>  Yes, Ubuntu 12.04 is tested as mentioned in the readme [1]. Note that
>> the referenced script is just a wrapper that pulls all the latest from
>> various locations in openstack-infra, e.g. [2].
>>
>> Ubuntu 14.04 support is WIP [3]
>>
>> FYI, there’s a spec to get an in-tree 3rd party ci solution [4]. Please
>> add your comments if this interests you.
>>
>>
>>
>> [1] https://github.com/rasselin/os-ext-testing/blob/master/README.md
>>
>> [2]
>> https://github.com/rasselin/os-ext-testing/blob/master/puppet/install_master.sh#L29
>>
>> [3] https://review.openstack.org/#/c/141518/
>>
>> [4] https://review.openstack.org/#/c/139745/
>>
>>
>>
>>
>>
>> *From:* Punith S [mailto:punit...@cloudbyte.com]
>> *Sent:* Thursday, December 18, 2014 3:12 AM
>> *To:* OpenStack Development Mailing List (not for usage questions);
>> Eduard Matei
>>
>> *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
>> help setting up CI
>>
>>
>>
>> Hi Eduard
>>
>>
>>
>> we tried running
>> https://raw.githubusercontent.com/rasselin/os-ext-testing/master/puppet/install_master.sh
>>
>> on ubuntu master 12.04, and it appears to be working fine on 12.04.
>>
>>
>>
>> thanks
>>
>>
>>
>> On Thu, Dec 18, 2014 at 1:57 PM, Eduard Matei <
>> eduard.ma...@cloudfounders.com> wrote:
>>
>>  Hi,
>>
>> Seems i can't install using puppet on the jenkins master using
>> install_master.sh from
>> https://raw.githubusercontent.com/rasselin/os-ext-testing/master/puppet/install_master.sh
>> because it's running Ubuntu 11.10 and it appears unsupported.
>>
>> I managed to install puppet manually on master and everything else fails
>>
>> So i'm trying to manually install zuul and nodepool and jenkins job
>> builder, see where i end up.
>>
>>
>>
>> The slave looks complete, got some errors on running install_slave so i
>> ran parts of the script manually, changing some params and it appears
>> installed but no way to test it without the master.
>>
>>
>>
>> Any ideas welcome.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Eduard
>>
>>
>>
>> On Wed, Dec 17, 2014 at 3:37 AM, Asselin, Ramy 
>> wrote:
>>
>>   Manually running the script requires a few environment settings. Take
>> a look at the README here:
>>
>> https://github.com/openstack-infra/devstack-gate
>>
>>
>>
>> Regarding cinder, I’m using this repo to run our cinder jobs (fork from
>> jaypipes).
>>
>> https://github.com/rasselin/os-ext-testing
>>
>>
>>
>> Note that this solution doesn’t use the Jenkins gerrit trigger pluggin,
>> but zuul.
>>
>>
>>
>> There’s a sample job for cinder here. It’s in Jenkins Job Builder format.
>>
>>
>> https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample
>>
>>
>>
>> You can ask more questions in IRC freenode #openstack-cinder. (irc#
>> asselin)
>>
>>
>>
>> Ramy
>>
>>
>>
>> *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
>> *Sent:* Tuesday, December 16, 2014 12:41 AM
>> *To:* Bailey, Darragh
>> *Cc:* OpenStack Development Mailing List (not for usage questions);
>> OpenStack
>> *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
>> help setting up CI
>>
>>
>>
>> Hi,
>>
>>
>>
>> Can someone point me to some working documentation on how to setup third
>> party CI? (joinfu's instructions

Re: [openstack-dev] [FUEL] Bootstrap NTP sync.

[Tomasz Napierala]

> On 19 Dec 2014, at 10:00, Stanislaw Bogatkin  wrote:
> 
> Hi guys,
> 
> We have a little concern related to Fuel bootstrap node NTP sync. Currently 
> we trying to sync time on bootstrap node with master node, but problem is 
> that NTP protocol has long convergence time, so if we just install master 
> node and right after that try to start some bootstrap node - bootstrap fails 
> to sync time with master due to that fact that master doesn't appear as 
> "trust time source" at that moment.
> How we can solve that problem:
> 
> 1. We can start bootstrap long time after master (when master will 
> convergence it's time) - seems that it's a bad idea, cause master node 
> convergence time depends on upstream NTP servers and may be quite long - user 
> shouldn't wait so long time to just start bootstrap node.
> 
> 2. We can use master local time as "trust" forcibly - actually, we already do 
> that for case when master is a bare metal node. We can do it for virtual node 
> too, it is not such bad idea as many can say, especially when master node 
> stratum will low (10-12).
> 
> 3. We can mask return value for bootstrap node ntpdate service such way that 
> it always will return success - it's a dirty hack, it will calm down 
> customers, but it doesn't solve problem - time will be unsynced.
> 
> As for me - second option is best. What do you think about it?

Second option looks best, although it’s still against standards. I guess that 
if we provide possibility to deifne external NTP server as an alternative, we 
are hsfa here and can live with that.

Regards,
-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







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

Re: [openstack-dev] [Mistral] ActionProvider

[Anastasia Kuznetsova]

Winson, Renat,

I think that it is a good idea. Moreover, it is relevant, because about a
month ago there was a question from one guy in our IRC channel about what
if some of other 3rd party systems which provide their own client bindings
(in python) want to integrate with Mistral, how it will work. For that
moment we just thought about it, but hadn't any blueprints or discussions.

Thanks,
Anastasia Kuznetsova
@ Mirantis Inc.


On Thu, Dec 18, 2014 at 9:33 AM, Renat Akhmerov 
wrote:
>
> Winson,
>
> The idea itself makes a lot of sense to me because we’ve had a number of
> discussions about how we could make action subsystem even more pluggable
> and flexible. One of the questions that we’d like to solve is to be able to
> add actions “on the fly” and at the same time stay safe. I think this whole
> thing is about specific technical details so I would like to see more of
> them. Generally speaking, you’re right about actions residing in a
> database, about 3 months ago we made this refactoring and put all actions
> into db but it may not be 100% necessary. Btw, we already have a concept of
> action generator that we use to automatically build OpenStack actions so
> you can take a look at how they work. Long story short… We’ve already made
> some steps towards being more flexible and have some facilities that could
> be further improved.
>
> Again, the idea is very interesting to me (and not only to me). Please
> share the details.
>
> Thanks
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> > On 17 Dec 2014, at 13:22, W Chan  wrote:
> >
> > Renat,
> >
> > We want to introduce the concept of an ActionProvider to Mistral.  We
> are thinking that with an ActionProvider, a third party system can extend
> Mistral with it's own action catalog and set of dedicated and specialized
> action executors.  The ActionProvider will return it's own list of actions
> via an abstract interface.  This minimizes the complexity and latency in
> managing and sync'ing the Action table.  In the DSL, we can define provider
> specific context/configuration separately and apply to all provider
> specific actions without explicitly passing as inputs.  WDYT?
> >
> > Winson
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Mistral] Plans to load and performance testing

[Anastasia Kuznetsova]

Hello everyone,

I want to announce that Mistral team has started work on load and
performance testing in this release cycle.

Brief information about scope of our work can be found here:
https://wiki.openstack.org/wiki/Mistral/Testing#Load_and_Performance_Testing

First results are published here:
https://etherpad.openstack.org/p/mistral-rally-testing-results

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

Re: [openstack-dev] [Neutron][L2Pop][HA Routers] Request for comments for a possible solution

[Mathieu Rohon]

Mike,

I'm not even sure that your solution works without being able to bind
a router HA port to several hosts.
What's happening currently is that you :

1.create the router on two l3agent.
2. those l3agent trigger the sync_router() on the l3plugin.
3. l3plugin.sync_routers() will trigger l2plugin.update_port(host=l3agent).
4. ML2 will bind the port to the host mentioned in the last update_port().

>From a l2pop perspective, this will result in creating only one tunnel
to the host lastly specified.
I can't find any code that forces that only the master router binds
its router port. So we don't even know if the host which binds the
router port is hosting the master router or the slave one, and so if
l2pop is creating the tunnel to the master or to the slave.

Can you confirm that the above sequence is correct? or am I missing something?

Without the capacity to bind a port to several hosts, l2pop won't be
able to create tunnel correctly, that's the reason why I was saying
that a prerequisite for a smart solution would be to first fix the bug
:
https://bugs.launchpad.net/neutron/+bug/1367391

DVR Had the same issue. Their workaround was to create a new
port_binding tables, that manages the capacity for one DVR port to be
bound to several host.
As mentioned in the bug 1367391, this adding a technical debt in ML2,
which has to be tackle down in priority from my POV.


On Thu, Dec 18, 2014 at 6:28 PM, Mike Kolesnik  wrote:
> Hi Mathieu,
>
> Thanks for the quick reply, some comments inline..
>
> Regards,
> Mike
>
> - Original Message -
>> Hi mike,
>>
>> thanks for working on this bug :
>>
>> On Thu, Dec 18, 2014 at 1:47 PM, Gary Kotton  wrote:
>> >
>> >
>> > On 12/18/14, 2:06 PM, "Mike Kolesnik"  wrote:
>> >
>> >>Hi Neutron community members.
>> >>
>> >>I wanted to query the community about a proposal of how to fix HA routers
>> >>not
>> >>working with L2Population (bug 1365476[1]).
>> >>This bug is important to fix especially if we want to have HA routers and
>> >>DVR
>> >>routers working together.
>> >>
>> >>[1] https://bugs.launchpad.net/neutron/+bug/1365476
>> >>
>> >>What's happening now?
>> >>* HA routers use distributed ports, i.e. the port with the same IP & MAC
>> >>  details is applied on all nodes where an L3 agent is hosting this
>> >>router.
>> >>* Currently, the port details have a binding pointing to an arbitrary node
>> >>  and this is not updated.
>> >>* L2pop takes this "potentially stale" information and uses it to create:
>> >>  1. A tunnel to the node.
>> >>  2. An FDB entry that directs traffic for that port to that node.
>> >>  3. If ARP responder is on, ARP requests will not traverse the network.
>> >>* Problem is, the master router wouldn't necessarily be running on the
>> >>  reported agent.
>> >>  This means that traffic would not reach the master node but some
>> >>arbitrary
>> >>  node where the router master might be running, but might be in another
>> >>  state (standby, fail).
>> >>
>> >>What is proposed?
>> >>Basically the idea is not to do L2Pop for HA router ports that reside on
>> >>the
>> >>tenant network.
>> >>Instead, we would create a tunnel to each node hosting the HA router so
>> >>that
>> >>the normal learning switch functionality would take care of switching the
>> >>traffic to the master router.
>> >
>> > In Neutron we just ensure that the MAC address is unique per network.
>> > Could a duplicate MAC address cause problems here?
>>
>> gary, AFAIU, from a Neutron POV, there is only one port, which is the
>> router Port, which is plugged twice. One time per port.
>> I think that the capacity to bind a port to several host is also a
>> prerequisite for a clean solution here. This will be provided by
>> patches to this bug :
>> https://bugs.launchpad.net/neutron/+bug/1367391
>>
>>
>> >>This way no matter where the master router is currently running, the data
>> >>plane would know how to forward traffic to it.
>> >>This solution requires changes on the controller only.
>> >>
>> >>What's to gain?
>> >>* Data plane only solution, independent of the control plane.
>> >>* Lowest failover time (same as HA routers today).
>> >>* High backport potential:
>> >>  * No APIs changed/added.
>> >>  * No configuration changes.
>> >>  * No DB changes.
>> >>  * Changes localized to a single file and limited in scope.
>> >>
>> >>What's the alternative?
>> >>An alternative solution would be to have the controller update the port
>> >>binding
>> >>on the single port so that the plain old L2Pop happens and notifies about
>> >>the
>> >>location of the master router.
>> >>This basically negates all the benefits of the proposed solution, but is
>> >>wider.
>> >>This solution depends on the report-ha-router-master spec which is
>> >>currently in
>> >>the implementation phase.
>> >>
>> >>It's important to note that these two solutions don't collide and could
>> >>be done
>> >>independently. The one I'm proposing just makes more sense from an HA
>> >>viewpoint
>> >>because of it's benefits 

Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?

[Steven Hardy]

On Fri, Dec 19, 2014 at 05:02:04PM +0900, Yasunori Goto wrote:
> 
> Hello,
> 
> This is the first mail at Openstack community,

Welcome! :)

> and I have a small question about how to write blueprint for Heat.
> 
> Currently our team would like to propose 2 interfaces
> for users operation in HOT. 
> (One is "Event handler" which is to notify user's defined event to heat.
>  Another is definitions of action when heat catches the above notification.)
> So, I'm preparing the blueprint for it.

Please include details of the exact use-case, e.g the problem you're trying
to solve (not just the proposed solution), as it's possible we can suggest
solutions based on exiting interfaces.

> However, I can not find how I can write at the milestone section of blueprint.
> 
> Heat blueprint template has a section for Milestones.
> "Milestones -- Target Milestone for completeion:"
> 
> But I don't think I can decide it by myself.
> In my understanding, it should be decided by PTL.

Normally, it's decided by when the person submitting the spec expects to
finish writing the code by.  The PTL doesn't really have much control over
that ;)

> In addition, probably the above our request will not finish
> by Kilo. I suppose it will be "L" version or later.

So to clarify, you want to propose the feature, but you're not planning on
working on it (e.g implementing it) yourself?

> So, what should I write at this section?
> "Kilo-x", "L version", or empty?

As has already been mentioned, it doesn't matter that much - I see it as a
statement of intent from developers.  If you're just requesting a feature,
you can even leave it blank if you want and we'll update it when an
assignee is found (e.g during the spec review).

Thanks,

Steve

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

Re: [openstack-dev] [openstack-announce] [keystonemiddleware] keystonemiddlware release 1.3.0

[Chmouel Boudjnah]

On Thu, Dec 18, 2014 at 8:25 PM, Morgan Fainberg 
wrote:
>
> * http_connect_timeout option is now an integer instead of a boolean.
> * The service user for auth_token middlware can now be in a domain other
> than the default domain.
>


fyi it has a fix in there as well so you can now use it in your py3 based
wsgi service.

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

Re: [openstack-dev] [libvirt][vpnaas] IRC Meeting Clash

[Daniel P. Berrange]

On Fri, Dec 19, 2014 at 10:05:44AM +, Matthew Gilliard wrote:
> Hello,
> 
>   At the moment, both Libvirt [1] and VPNaaS [2] are down as having
> meetings in #openstack-meeting-3 at 1500UTC on Tuesdays. Of course,
> there can be only one - and it looks as if the VPN meeting is the one
> that actually takes place there.
> 
>   What's the status of the libvirt meetings? Have they moved, or are
> they not happening any more?

They happen, but when there are no agenda items that need discussing
they're done pretty quickly.

Given that VPN meeting was only added ot the wiki a week ago, I think
it should be the meeting that changes time or place.

NB identifying free slots from the wiki is a total PITA. It is easier to
install the iCal calendar feed, which gives you a visual representation
of what the free/busy slots are during the week.

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

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

[openstack-dev] [libvirt][vpnaas] IRC Meeting Clash

[Matthew Gilliard]

Hello,

  At the moment, both Libvirt [1] and VPNaaS [2] are down as having
meetings in #openstack-meeting-3 at 1500UTC on Tuesdays. Of course,
there can be only one - and it looks as if the VPN meeting is the one
that actually takes place there.

  What's the status of the libvirt meetings? Have they moved, or are
they not happening any more?

  Thanks,

Matthew

[1] https://wiki.openstack.org/wiki/Meetings#Libvirt_Meeting
[2] 
https://wiki.openstack.org/wiki/Meetings#VPN_as_a_Service_.28VPNaaS.29_team_meeting

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

Re: [openstack-dev] [TripleO] Weekly meeting roundup - midcycle confirmation, nomergepy blockage

[Steven Hardy]

On Fri, Dec 19, 2014 at 10:21:17AM +0100, James Polley wrote:
>We had a few topics come up in this week's meeting which we thought are
>worth drawing everyone's attention to
>You can see the full meeting logs
>atA 
> http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-12-16-19.01.log.html
>(the shorter meeting notes don't have much information)
>No mergepy - blocked by bug 1401929
>As part of our plans to move away from needing merge.py, Tomas Sedovic
>raisedA https://review.openstack.org/#/c/140375/ to make the f20 job use
>the no-mergepy options.
> 
>Unfortunately this has run into a roadblock, discussed
>inA https://bugs.launchpad.net/heat/+bug/1401929 (Overzealous validation
>of images in empty ResourceGroups).
>Steve Hardy is (I believe) working on a fix, targeted at kilo-2. In the
>meantime it'd be nice if we could find a workaround...

The obvious workaround is just passing image parameters in to images which
exist in glance (e.g any image, just so the validation passes).

Not sure it's worth spending time on that though, as I have a fix for it in
heat, just working on tests then this will be ready for review today:

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

Apologies for the inconvenience, hopefully we can get this unblocked today.

Steve

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

Re: [openstack-dev] Request for comments for a possible solution

[Mathieu Rohon]

Hi vivek,

On Fri, Dec 19, 2014 at 10:44 AM, Narasimhan, Vivekanandan
 wrote:
> Hi Mike,
>
> Few clarifications inline [Vivek]
>
> -Original Message-
> From: Mike Kolesnik [mailto:mkole...@redhat.com]
> Sent: Thursday, December 18, 2014 10:58 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][L2Pop][HA Routers] Request for 
> comments for a possible solution
>
> Hi Mathieu,
>
> Thanks for the quick reply, some comments inline..
>
> Regards,
> Mike
>
> - Original Message -
>> Hi mike,
>>
>> thanks for working on this bug :
>>
>> On Thu, Dec 18, 2014 at 1:47 PM, Gary Kotton  wrote:
>> >
>> >
>> > On 12/18/14, 2:06 PM, "Mike Kolesnik"  wrote:
>> >
>> >>Hi Neutron community members.
>> >>
>> >>I wanted to query the community about a proposal of how to fix HA
>> >>routers not working with L2Population (bug 1365476[1]).
>> >>This bug is important to fix especially if we want to have HA
>> >>routers and DVR routers working together.
>> >>
>> >>[1] https://bugs.launchpad.net/neutron/+bug/1365476
>> >>
>> >>What's happening now?
>> >>* HA routers use distributed ports, i.e. the port with the same IP &
>> >>MAC
>> >>  details is applied on all nodes where an L3 agent is hosting this
>> >>router.
>> >>* Currently, the port details have a binding pointing to an
>> >>arbitrary node
>> >>  and this is not updated.
>> >>* L2pop takes this "potentially stale" information and uses it to create:
>> >>  1. A tunnel to the node.
>> >>  2. An FDB entry that directs traffic for that port to that node.
>> >>  3. If ARP responder is on, ARP requests will not traverse the network.
>> >>* Problem is, the master router wouldn't necessarily be running on
>> >>the
>> >>  reported agent.
>> >>  This means that traffic would not reach the master node but some
>> >>arbitrary
>> >>  node where the router master might be running, but might be in
>> >>another
>> >>  state (standby, fail).
>> >>
>> >>What is proposed?
>> >>Basically the idea is not to do L2Pop for HA router ports that
>> >>reside on the tenant network.
>> >>Instead, we would create a tunnel to each node hosting the HA router
>> >>so that the normal learning switch functionality would take care of
>> >>switching the traffic to the master router.
>> >
>> > In Neutron we just ensure that the MAC address is unique per network.
>> > Could a duplicate MAC address cause problems here?
>>
>> gary, AFAIU, from a Neutron POV, there is only one port, which is the
>> router Port, which is plugged twice. One time per port.
>> I think that the capacity to bind a port to several host is also a
>> prerequisite for a clean solution here. This will be provided by
>> patches to this bug :
>> https://bugs.launchpad.net/neutron/+bug/1367391
>>
>>
>> >>This way no matter where the master router is currently running, the
>> >>data plane would know how to forward traffic to it.
>> >>This solution requires changes on the controller only.
>> >>
>> >>What's to gain?
>> >>* Data plane only solution, independent of the control plane.
>> >>* Lowest failover time (same as HA routers today).
>> >>* High backport potential:
>> >>  * No APIs changed/added.
>> >>  * No configuration changes.
>> >>  * No DB changes.
>> >>  * Changes localized to a single file and limited in scope.
>> >>
>> >>What's the alternative?
>> >>An alternative solution would be to have the controller update the
>> >>port binding on the single port so that the plain old L2Pop happens
>> >>and notifies about the location of the master router.
>> >>This basically negates all the benefits of the proposed solution,
>> >>but is wider.
>> >>This solution depends on the report-ha-router-master spec which is
>> >>currently in the implementation phase.
>> >>
>> >>It's important to note that these two solutions don't collide and
>> >>could be done independently. The one I'm proposing just makes more
>> >>sense from an HA viewpoint because of it's benefits which fit the HA
>> >>methodology of being fast & having as little outside dependency as
>> >>possible.
>> >>It could be done as an initial solution which solves the bug for
>> >>mechanism drivers that support normal learning switch (OVS), and
>> >>later kept as an optimization to the more general, controller based,
>> >>solution which will solve the issue for any mechanism driver working
>> >>with L2Pop (Linux Bridge, possibly others).
>> >>
>> >>Would love to hear your thoughts on the subject.
>>
>> You will have to clearly update the doc to mention that deployment
>> with Linuxbridge+l2pop are not compatible with HA.
>
> Yes this should be added and this is already the situation right now.
> However if anyone would like to work on a LB fix (the general one or some 
> specific one) I would gladly help with reviewing it.
>
>>
>> Moreover, this solution is downgrading the l2pop solution, by
>> disabling the ARP-responder when VMs want to talk to a HA router.
>> This means that ARP requests will be duplicated to every ove

Re: [openstack-dev] Request for comments for a possible solution

[Narasimhan, Vivekanandan]

Hi Mike,

Few clarifications inline [Vivek]

-Original Message-
From: Mike Kolesnik [mailto:mkole...@redhat.com]
Sent: Thursday, December 18, 2014 10:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L2Pop][HA Routers] Request for comments 
for a possible solution

Hi Mathieu,

Thanks for the quick reply, some comments inline..

Regards,
Mike

- Original Message -
> Hi mike,
>
> thanks for working on this bug :
>
> On Thu, Dec 18, 2014 at 1:47 PM, Gary Kotton  wrote:
> >
> >
> > On 12/18/14, 2:06 PM, "Mike Kolesnik"  wrote:
> >
> >>Hi Neutron community members.
> >>
> >>I wanted to query the community about a proposal of how to fix HA
> >>routers not working with L2Population (bug 1365476[1]).
> >>This bug is important to fix especially if we want to have HA
> >>routers and DVR routers working together.
> >>
> >>[1] https://bugs.launchpad.net/neutron/+bug/1365476
> >>
> >>What's happening now?
> >>* HA routers use distributed ports, i.e. the port with the same IP &
> >>MAC
> >>  details is applied on all nodes where an L3 agent is hosting this
> >>router.
> >>* Currently, the port details have a binding pointing to an
> >>arbitrary node
> >>  and this is not updated.
> >>* L2pop takes this "potentially stale" information and uses it to create:
> >>  1. A tunnel to the node.
> >>  2. An FDB entry that directs traffic for that port to that node.
> >>  3. If ARP responder is on, ARP requests will not traverse the network.
> >>* Problem is, the master router wouldn't necessarily be running on
> >>the
> >>  reported agent.
> >>  This means that traffic would not reach the master node but some
> >>arbitrary
> >>  node where the router master might be running, but might be in
> >>another
> >>  state (standby, fail).
> >>
> >>What is proposed?
> >>Basically the idea is not to do L2Pop for HA router ports that
> >>reside on the tenant network.
> >>Instead, we would create a tunnel to each node hosting the HA router
> >>so that the normal learning switch functionality would take care of
> >>switching the traffic to the master router.
> >
> > In Neutron we just ensure that the MAC address is unique per network.
> > Could a duplicate MAC address cause problems here?
>
> gary, AFAIU, from a Neutron POV, there is only one port, which is the
> router Port, which is plugged twice. One time per port.
> I think that the capacity to bind a port to several host is also a
> prerequisite for a clean solution here. This will be provided by
> patches to this bug :
> https://bugs.launchpad.net/neutron/+bug/1367391
>
>
> >>This way no matter where the master router is currently running, the
> >>data plane would know how to forward traffic to it.
> >>This solution requires changes on the controller only.
> >>
> >>What's to gain?
> >>* Data plane only solution, independent of the control plane.
> >>* Lowest failover time (same as HA routers today).
> >>* High backport potential:
> >>  * No APIs changed/added.
> >>  * No configuration changes.
> >>  * No DB changes.
> >>  * Changes localized to a single file and limited in scope.
> >>
> >>What's the alternative?
> >>An alternative solution would be to have the controller update the
> >>port binding on the single port so that the plain old L2Pop happens
> >>and notifies about the location of the master router.
> >>This basically negates all the benefits of the proposed solution,
> >>but is wider.
> >>This solution depends on the report-ha-router-master spec which is
> >>currently in the implementation phase.
> >>
> >>It's important to note that these two solutions don't collide and
> >>could be done independently. The one I'm proposing just makes more
> >>sense from an HA viewpoint because of it's benefits which fit the HA
> >>methodology of being fast & having as little outside dependency as
> >>possible.
> >>It could be done as an initial solution which solves the bug for
> >>mechanism drivers that support normal learning switch (OVS), and
> >>later kept as an optimization to the more general, controller based,
> >>solution which will solve the issue for any mechanism driver working
> >>with L2Pop (Linux Bridge, possibly others).
> >>
> >>Would love to hear your thoughts on the subject.
>
> You will have to clearly update the doc to mention that deployment
> with Linuxbridge+l2pop are not compatible with HA.

Yes this should be added and this is already the situation right now.
However if anyone would like to work on a LB fix (the general one or some 
specific one) I would gladly help with reviewing it.

>
> Moreover, this solution is downgrading the l2pop solution, by
> disabling the ARP-responder when VMs want to talk to a HA router.
> This means that ARP requests will be duplicated to every overlay
> tunnel to feed the OVS Mac learning table.
> This is something that we were trying to avoid with l2pop. But may be
> this is acceptable.

Yes basically you're correct, however this would be only limited to tho

[openstack-dev] [nova] Evacuate instance which in server group with affinity policy

[Alex Xu]

Hi,

There is problem when evacuate instance. If the instance is in the server
group with affinity policy, the instance can't evacuate out the failed
compute node.

I know there is soft affinity policy under development, but think of if the
instance in server group with hard affinity means no way to get it back
when compute node failed, it's really confuse.

I guess there should be some people concern that will violate the affinity
policy. But I think the compute node already down, all the instance in that
server group are down also, so I think we needn't care about the policy
anymore.

I wrote up a patch can fix this problem:
https://review.openstack.org/#/c/135607/


We have some discussion on the gerrit (Thanks Sylvain for discuss with me),
but we still not sure we are on the right direction. So I bring this up at
here.

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

Re: [openstack-dev] [cinder] [driver] DB operations

[Duncan Thomas]

So our general advice has historical been 'drivers should not be accessing
the db directly'. I haven't had chance to look at your driver code yet,
I've been on vacation, but my suggestion is that if you absolutely must
store something in the admin metadata rather than somewhere that is covered
by the model update (generally provider location and provider auth) then
writing some helper methods that wrap the context bump and db call would be
better than accessing it directly from the driver.

Duncan Thomas
On Dec 18, 2014 11:41 PM, "Amit Das"  wrote:

> Hi Stackers,
>
> I have been developing a Cinder driver for CloudByte storage and have come
> across some scenarios where the driver needs to do create, read & update
> operations on cinder database (volume_admin_metadata table). This is
> required to establish a mapping between OpenStack IDs with the backend
> storage IDs.
>
> Now, I have got some review comments w.r.t the usage of DB related
> operations esp. w.r.t raising the context to admin.
>
> In short, it has been advised not to use "*context.get_admin_context()*".
>
>
> https://review.openstack.org/#/c/102511/15/cinder/volume/drivers/cloudbyte/cloudbyte.py
>
> However, i get errors trying to use the default context as shown below:
>
> *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher   File
> "/opt/stack/cinder/cinder/db/sqlalchemy/api.py", line 103, in
> is_admin_context*
> *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher return
> context.is_admin*
> *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher
> AttributeError: 'module' object has no attribute 'is_admin'*
>
> So what is the proper way to run these DB operations from within a driver ?
>
>
> Regards,
> Amit
> *CloudByte Inc.* 
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Weekly meeting roundup - midcycle confirmation, nomergepy blockage

[James Polley]

We had a few topics come up in this week's meeting which we thought are
worth drawing everyone's attention to

You can see the full meeting logs at
http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-12-16-19.01.log.html
(the shorter meeting notes don't have much information)

*No mergepy - blocked by bug 1401929*
As part of our plans to move away from needing merge.py, Tomas Sedovic
raised https://review.openstack.org/#/c/140375/ to make the f20 job use the
no-mergepy options.

Unfortunately this has run into a roadblock, discussed in
https://bugs.launchpad.net/heat/+bug/1401929 (Overzealous validation of
images in empty ResourceGroups).

Steve Hardy is (I believe) working on a fix, targeted at kilo-2. In the
meantime it'd be nice if we could find a workaround...

*Mid-cycle dates confirmed - please RSVP*
Clint has confirmed that we have the Seattle office booked for Feb 18-20.
We have limisted space, so if you're planning to attend, *please
visit https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup
 and add
your name to the confirmed list, even if you previously indicated you were
coming. *Currently we only have 8 confirmed attendees

The etherpad also has a draft schedule and venue details. We aren't
planning to arrange a group rate for the hotel, but there are many good
hotels in a short distance from the HP office.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?

[Yasunori Goto]

Hi, Pavlo-san


> Hi Yasunori,
> 
> that's the point of using code review for specs - you make your the best
> bet / effort, and we then as a community decide if it should be changed ;)
> 
> So feel free submitting it with e.g. K-3 target, we'll figure out the
> correct thing during review.

Ok, I got it.

Thanks,

-- 
Yasunori Goto 



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

Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?

[Pavlo Shchelokovskyy]

Hi Yasunori,

that's the point of using code review for specs - you make your the best
bet / effort, and we then as a community decide if it should be changed ;)

So feel free submitting it with e.g. K-3 target, we'll figure out the
correct thing during review.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Fri, Dec 19, 2014 at 10:57 AM, Yasunori Goto 
wrote:
>
> Hi, Thomas-san,
>
> Thank you for your response.
>
> > you can submit a blueprint spec as a gerrit review to the heat-specs
> > repository [1].
> > I would suggest to have a look at some existing specs that already got
> > accepted to have an example for the format, important sections etc.
> >
> > All kilo related specs are in a kilo sub-directory in the repo, and the
> > proposed milestone is mentioned in the spec itself.
> >
> > [1] https://github.com/openstack/heat-specs
>
> Hmm.
> However, "Kilo-1", "Kilo-2", or "Kilo-3" is written at the section of
> "Target Milestone for completion:" in these blueprint.
>
> I don't find I can decide such concrete Milestone for my new blueprint.
> It is why I asked...
>
> Thanks,
>
>
> >
> > Regards,
> > Thomas
> >
> >
> > > From: Yasunori Goto 
> > > To: Openstack-Dev-ML 
> > > Date: 19/12/2014 09:05
> > > Subject: [openstack-dev] [Heat] How can I write at milestone section
> > > of blueprint?
> > >
> > >
> > > Hello,
> > >
> > > This is the first mail at Openstack community,
> > > and I have a small question about how to write blueprint for Heat.
> > >
> > > Currently our team would like to propose 2 interfaces
> > > for users operation in HOT.
> > > (One is "Event handler" which is to notify user's defined event to
> heat.
> > >  Another is definitions of action when heat catches the above
> > notification.)
> > > So, I'm preparing the blueprint for it.
> > >
> > > However, I can not find how I can write at the milestone section of
> > blueprint.
> > >
> > > Heat blueprint template has a section for Milestones.
> > > "Milestones -- Target Milestone for completeion:"
> > >
> > > But I don't think I can decide it by myself.
> > > In my understanding, it should be decided by PTL.
> > >
> > > In addition, probably the above our request will not finish
> > > by Kilo. I suppose it will be "L" version or later.
> > >
> > > So, what should I write at this section?
> > > "Kilo-x", "L version", or empty?
> > >
> > > Thanks,
> > >
> > > --
> > > Yasunori Goto 
> > >
> > >
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Yasunori Goto 
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] #PERSONAL# : Git checkout command for Blueprints submission

[Pasquale Porreca]

I think you meant git checkout -b bp/ :)

@Swati: when you commit, add the message:

Implements: blueprint 

For more info you can give a look at gerrit workflow wiki:
https://wiki.openstack.org/wiki/Gerrit_Workflow


On 12/18/14 18:17, Edgar Magana wrote:
> It is git checkout -b bp/
>
> Edgar
>
> From: Swati Shukla1 mailto:swati.shuk...@tcs.com>>
> Reply-To: "openstack-dev@lists.openstack.org
> "
>  >
> Date: Tuesday, December 16, 2014 at 10:53 PM
> To: "openstack-dev@lists.openstack.org
> "
>  >
> Subject: [openstack-dev] #PERSONAL# : Git checkout command for
> Blueprints submission
>
>
> Hi All,
>
> Generally, for bug submissions, we use ""git checkout -b
> bug/""
>
> What is the similar 'git checkout' command for blueprints submission?
>
> Swati Shukla
> Tata Consultancy Services
> Mailto: swati.shuk...@tcs.com 
> Website: http://www.tcs.com
> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
>
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

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

Re: [openstack-dev] [Congress] Re: Placement and Scheduling via Policy

[Khanh-Toan Tran]

Hi all,

I've made an analyse a while a go how to use SolverScheduler with a policy 
engine:

https://docs.google.com/document/d/1RfP7jRsw1mXMjd7in72ARjK0fTrsQv1bqolOriIQB2Y

Basically there should be a plugin that translates the policy into constraints 
for
solver to solve. This was made using Policy-Based Engine [1], but it works well
with Congress.

[1] https://blueprints.launchpad.net/nova/+spec/policy-based-scheduler


- Mail original -
> De: "Tim Hinrichs" 
> À: "ruby krishnaswamy" 
> Cc: "Prabhakar Kudva" , "openstack-dev" 
> , "Gokul B Kandiraju"
> 
> Envoyé: Jeudi 18 Décembre 2014 18:24:59
> Objet: Re: [openstack-dev] [Congress] Re: Placement and Scheduling via
> Policy
> 
> Hi all,
> 
> Responses inline.
> 
> On Dec 16, 2014, at 10:57 PM,
> mailto:ruby.krishnasw...@orange.com>>
> mailto:ruby.krishnasw...@orange.com>> wrote:
> 
> Hi Tim & All
> 
> @Tim: I did not reply to openstack-dev. Do you think we could have an
> openstack list specific for “congress” to which anybody may subscribe?
> 
> Sending to openstack-dev is the right thing, as long as we put [Congress] in
> the subject.  Everyone I know sets up filters on openstack-dev so they only
> get the mail they care about.  I think you’re the only one in the group who
> isn’t subscribed to that list.
> 
> 
> 
> 1) Enforcement:
>By this we mean “how will the actions computed by the policy
>engine be executed by the concerned OpenStack functional module”.
> 
> 
>   In this case, it is better to first work this out for a “simpler” case,
>   e.g. your running example concerning the network/groups.
> Note: some actions concern only some data base (e.g. insert the
> user within some group).
> 
> 
> 
> 2)  From Prabhakar’s mail
> 
> “Enforcement. That is with a large number of constraints in place for
> placement and
> scheduling, how does the policy engine communicate and enforce the placement
> constraints to nova scheduler. “
> 
> Nova scheduler (current): It assigns VMs to servers based on the
> policy set by the administrator (through filters and host
> aggregates).
> 
>   The administrator also configures a scheduling heuristic (implemented as a
>   driver), for example “round-robin” driver.
>  Then the computed assignment
>  is sent back to the
>  requestor (API server) that
>  interacts with nova-compute
>  to provision the VM.
>  The current nova-scheduler
>  has another function: It
>  updates the allocation
>  status of each compute node
>  on the DB (through another
>  indirection called
>  nova-conductor)
> 
> So it is correct to re-interpret your statement as follows:
> 
> -   What is the entity with which the policy engine interacts for either
> proactive or reactive placement management?
> 
> -   How will the output from the policy engine (for example the placement
> matrix) be communicated back?
> 
> oProactive: this gives the mapping of VM to host
> 
> oReactive: this gives the new mapping of running VMs to hosts
> 
> -   How starting from the placement matrix, the correct migration plan
> will be executed? (for reactive case)
> 
> 
> 
> 3) Currently openstack does not have “automated management of reactive
> placement”:  Hence if the policy engine is used for reactive placement, then
> there is a need for another “orchestrator” that can interpret the new
> proposed placement configuration (mapping of VM to servers) and execute the
> reconfiguration workflow.
> 
> 
> 4) So with a policy-based “placement engine” that is integrated with
> external solvers, then this engine will replace nova-scheduler?
> 
> Could we converge on this?
> 
> 
> 
> The notes from Yathiraj say that there is already a policy-based Nova
> scheduler we can use.  I suggest we look into that.  It could potentially
> simplify our problem to the point where we need only figure out how to
> convert a fragment of the Congress policy language into their policy
> language.  But those of you who are experts in placement will know better.
> 
>
> https://github.com/stackforge/nova-solver-scheduler

Re: [openstack-dev] [nova] Volunteer for BP 'Improve Nova KVM IO support'

[Rui Chen]

Thank @Sahid, I will help to review this patch :)

2014-12-19 16:01 GMT+08:00 Sahid Orentino Ferdjaoui <
sahid.ferdja...@redhat.com>:
>
> On Fri, Dec 19, 2014 at 11:36:03AM +0800, Rui Chen wrote:
> > Hi,
> >
> > Is Anybody still working on this nova BP 'Improve Nova KVM IO support'?
> > https://blueprints.launchpad.net/nova/+spec/improve-nova-kvm-io-support
>
> This feature is already in review, since it is only to add an option
> to libvirt I guess we can consider to do not address a spec but I
> may be wrong.
>
> https://review.openstack.org/#/c/117442/
>
> s.
>
> > I willing to complement nova-spec and implement this feature in kilo or
> > subsequent versions.
> >
> > Feel free to assign this BP to me, thanks:)
> >
> > Best Regards.
>
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [FUEL] Bootstrap NTP sync.

[Stanislaw Bogatkin]

Hi guys,

We have a little concern related to Fuel bootstrap node NTP sync. Currently
we trying to sync time on bootstrap node with master node, but problem is
that NTP protocol has long convergence time, so if we just install master
node and right after that try to start some bootstrap node - bootstrap
fails to sync time with master due to that fact that master doesn't appear
as "trust time source" at that moment.
How we can solve that problem:

1. We can start bootstrap long time after master (when master will
convergence it's time) - seems that it's a bad idea, cause master node
convergence time depends on upstream NTP servers and may be quite long -
user shouldn't wait so long time to just start bootstrap node.

2. We can use master local time as "trust" forcibly - actually, we already
do that for case when master is a bare metal node. We can do it for virtual
node too, it is not such bad idea as many can say, especially when master
node stratum will low (10-12).

3. We can mask return value for bootstrap node ntpdate service such way
that it always will return success - it's a dirty hack, it will calm down
customers, but it doesn't solve problem - time will be unsynced.

As for me - second option is best. What do you think about it?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?

[Yasunori Goto]

Hi, Thomas-san,

Thank you for your response.

> you can submit a blueprint spec as a gerrit review to the heat-specs
> repository [1].
> I would suggest to have a look at some existing specs that already got
> accepted to have an example for the format, important sections etc.
> 
> All kilo related specs are in a kilo sub-directory in the repo, and the
> proposed milestone is mentioned in the spec itself.
> 
> [1] https://github.com/openstack/heat-specs

Hmm.
However, "Kilo-1", "Kilo-2", or "Kilo-3" is written at the section of 
"Target Milestone for completion:" in these blueprint. 

I don't find I can decide such concrete Milestone for my new blueprint.
It is why I asked...

Thanks,


> 
> Regards,
> Thomas
> 
> 
> > From: Yasunori Goto 
> > To: Openstack-Dev-ML 
> > Date: 19/12/2014 09:05
> > Subject: [openstack-dev] [Heat] How can I write at milestone section
> > of blueprint?
> >
> >
> > Hello,
> >
> > This is the first mail at Openstack community,
> > and I have a small question about how to write blueprint for Heat.
> >
> > Currently our team would like to propose 2 interfaces
> > for users operation in HOT.
> > (One is "Event handler" which is to notify user's defined event to heat.
> >  Another is definitions of action when heat catches the above
> notification.)
> > So, I'm preparing the blueprint for it.
> >
> > However, I can not find how I can write at the milestone section of
> blueprint.
> >
> > Heat blueprint template has a section for Milestones.
> > "Milestones -- Target Milestone for completeion:"
> >
> > But I don't think I can decide it by myself.
> > In my understanding, it should be decided by PTL.
> >
> > In addition, probably the above our request will not finish
> > by Kilo. I suppose it will be "L" version or later.
> >
> > So, what should I write at this section?
> > "Kilo-x", "L version", or empty?
> >
> > Thanks,
> >
> > --
> > Yasunori Goto 
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Yasunori Goto 



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

Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?

[Thomas Spatzier]

Hi Yasunori,

you can submit a blueprint spec as a gerrit review to the heat-specs
repository [1].
I would suggest to have a look at some existing specs that already got
accepted to have an example for the format, important sections etc.

All kilo related specs are in a kilo sub-directory in the repo, and the
proposed milestone is mentioned in the spec itself.

[1] https://github.com/openstack/heat-specs

Regards,
Thomas


> From: Yasunori Goto 
> To: Openstack-Dev-ML 
> Date: 19/12/2014 09:05
> Subject: [openstack-dev] [Heat] How can I write at milestone section
> of blueprint?
>
>
> Hello,
>
> This is the first mail at Openstack community,
> and I have a small question about how to write blueprint for Heat.
>
> Currently our team would like to propose 2 interfaces
> for users operation in HOT.
> (One is "Event handler" which is to notify user's defined event to heat.
>  Another is definitions of action when heat catches the above
notification.)
> So, I'm preparing the blueprint for it.
>
> However, I can not find how I can write at the milestone section of
blueprint.
>
> Heat blueprint template has a section for Milestones.
> "Milestones -- Target Milestone for completeion:"
>
> But I don't think I can decide it by myself.
> In my understanding, it should be decided by PTL.
>
> In addition, probably the above our request will not finish
> by Kilo. I suppose it will be "L" version or later.
>
> So, what should I write at this section?
> "Kilo-x", "L version", or empty?
>
> Thanks,
>
> --
> Yasunori Goto 
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

[openstack-dev] Kilo-1 development milestone available

[Thierry Carrez]

Hi everyone,

The first milestone of the Kilo development cycle, "kilo-1" is now
reached for Keystone, Glance, Nova, Horizon, Neutron, Cinder,
Ceilometer, Heat, Trove, Sahara, and Ironic ! It contains all the new
features and bugfixes that have been added since the Juno Feature Freeze
in September.

You can find the full list of new features and fixed bugs, as well as
tarball downloads, at:

https://launchpad.net/keystone/kilo/kilo-1
https://launchpad.net/glance/kilo/kilo-1
https://launchpad.net/nova/kilo/kilo-1
https://launchpad.net/horizon/kilo/kilo-1
https://launchpad.net/neutron/kilo/kilo-1
https://launchpad.net/cinder/kilo/kilo-1
https://launchpad.net/ceilometer/kilo/kilo-1
https://launchpad.net/heat/kilo/kilo-1
https://launchpad.net/trove/kilo/kilo-1
https://launchpad.net/sahara/kilo/kilo-1
https://launchpad.net/ironic/kilo/kilo-1

91 blueprints were implemented and no less than 1056 bugs were fixed
during this milestone. And that is not even counting all the features
and bugfixes that were pushed to Oslo libraries in the same timeframe.

The next development milestone, kilo-2, is scheduled for February 5th.
You can further track upcoming features and Kilo release cycle status
at: http://status.openstack.org/release/

Enjoy your local end-of-year holidays !

-- 
Thierry Carrez (ttx)




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

Re: [openstack-dev] [oslo.messaging][devstack] ZeroMQ driver maintenance next steps

[Li Ma]

On 2014/12/9 22:07, Doug Hellmann wrote:

On Dec 8, 2014, at 11:25 PM, Li Ma  wrote:


Hi all, I tried to deploy zeromq by devstack and it definitely failed with lots 
of problems, like dependencies, topics, matchmaker setup, etc. I've already 
registered a blueprint for devstack-zeromq [1].

I added the [devstack] tag to the subject of this message so that team will see 
the thread.


Besides, I suggest to build a wiki page in order to trace all the workitems related 
with ZeroMQ. The general sections may be [Why ZeroMQ], [Current Bugs & Reviews], 
[Future Plan & Blueprints], [Discussions], [Resources], etc.

Coordinating the work on this via a wiki page makes sense. Please post the link 
when you’re ready.

Doug

Hi all, I collected the current status of ZeroMQ driver and posted a 
wiki link [1] for them.


For those bugs that marked as Critical & High, as far as I know, some 
developers are working on them.  Patches are coming soon. BTW, I'm also 
working on the devstack support. Hope to land everything in the kilo cycle.


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


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

[openstack-dev] [Heat] How can I write at milestone section of blueprint?

[Yasunori Goto]

Hello,

This is the first mail at Openstack community,
and I have a small question about how to write blueprint for Heat.

Currently our team would like to propose 2 interfaces
for users operation in HOT. 
(One is "Event handler" which is to notify user's defined event to heat.
 Another is definitions of action when heat catches the above notification.)
So, I'm preparing the blueprint for it.

However, I can not find how I can write at the milestone section of blueprint.

Heat blueprint template has a section for Milestones.
"Milestones -- Target Milestone for completeion:"

But I don't think I can decide it by myself.
In my understanding, it should be decided by PTL.

In addition, probably the above our request will not finish
by Kilo. I suppose it will be "L" version or later.

So, what should I write at this section?
"Kilo-x", "L version", or empty?

Thanks,

-- 
Yasunori Goto 



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

Re: [openstack-dev] [nova] Volunteer for BP 'Improve Nova KVM IO support'

[Sahid Orentino Ferdjaoui]

On Fri, Dec 19, 2014 at 11:36:03AM +0800, Rui Chen wrote:
> Hi,
> 
> Is Anybody still working on this nova BP 'Improve Nova KVM IO support'?
> https://blueprints.launchpad.net/nova/+spec/improve-nova-kvm-io-support

This feature is already in review, since it is only to add an option
to libvirt I guess we can consider to do not address a spec but I
may be wrong.

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

s.

> I willing to complement nova-spec and implement this feature in kilo or
> subsequent versions.
> 
> Feel free to assign this BP to me, thanks:)
> 
> Best Regards.

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


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