Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download
There have been a number of comments regarding this in IRC in the last week. I think we should at least straighten out how to do this even if it's by hand. On Mon, Jun 1, 2015 at 7:15 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, Are we going to add this feature to 7.0? There are some customers who tried Fuel from nightly or technical previews builds. However, they don't want to install fuel master node once again. There are several reasons for that. As a sample it's dev environment, though production environment should be done with GA code and packages. Though, the customers want to upgrade Fuel master node to GA. That will allow them to create new environments with GA code and package base. Also, they will be able to reset environment to install GA code. How are we going to support such clients? Thanks, On Wed, Sep 3, 2014 at 5:37 PM Dmitry Pyzhov dpyz...@mirantis.com wrote: Dmitry, I totally agree that we should support nightly builds in upgrades. I've created a blueprint for this: https://blueprints.launchpad.net/fuel/+spec/upgrade-nightly On Tue, Sep 2, 2014 at 3:24 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: We should not confuse beta and rc builds, normally betas predate RCs and serve a different purpose. In that sense, the nightlies we currently publish are closest to what beta builds should be. As discussed earlier in the thread, we already have full versioning and provenance information in each build, so there is not a lot of value in inventing a parallel versioning scheme just for the time period when our builds are feature complete but not yet stable enough to declare an RC. The only benefit is to explicitly indicate the beta status of these builds, and we can achieve that without messing with versions. For example, by generating a summary table of all community builds that have passed the tests (using same build numbers we already have). Not supporting upgrades from/to intermediate builds is a limitation that we should not discard as inevitable, overcoming it should be in our backlog. Image based provisioning should make it much easier to support. My 2c, -Dmitry I would not use beta word anywhere at all. These are nightly builds, pre-5.1. So it will become 5.1 eventually, but for the moment - it is just master branch. We've not even reached HCF. After we reach HCF, we will start calling builds as Release Candidates (RC1, RC2, etc.) - and QA team runs acceptance testing against them. This can be considered as another name instead of beta-1, etc. Anyone can go to fuel-master-IP:8000/api/version to get sha commits of git repos a particular build was created of. Yes, these are development builds, and there will be no upgrade path provided from development build to 5.1 release or any other release. We might want to think about it though, if we could do it in theory, but I confirm what Evgeny says - we do not support it now. On Wed, Aug 27, 2014 at 1:11 PM, Evgeniy L e...@mirantis.com wrote: Hi guys, I have to say something about beta releases. As far as I know our beta release has the same version 5.1 as our final release. I think this versions should be different, because in case of some problem it will be much easier to identify what version we are trying to debug. Also from the irc channel I've heard that somebody wanted to upgrade his system to stable version, right now it's impossible because upgrade system uses this version for names of containers/images/temporary directories and we have validation which prevents the user to run upgrade to the same version. In upgrade script we use python module [1] to compare versions for validation. Let me give an example how development versions can look like 5.1a1 # alpha 5.1b1 # beta 1 5.1b1 # beta 2 5.1b1 # beta 3 5.1# final release [1] http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html Thanks, On Tue, Aug 26, 2014 at 11:15 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Igor, thanks a lot for improving UX over it - this table allows me to see which ISO passed verification tests. On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: I would also like to add that you can use our library called devops along with system tests we use for QA and CI. These tests use libvirt and kvm so that you can easily fire up an environment with specific configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the documentation how to use this library is here: http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or gaps in documentation, please feel free to file bugs to https://launchpad.net/fuel. On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin ishish...@mirantis.com wrote: Hi all, along with building your own ISO following instructions [1], you can always download nightly build [2] and run it, by using virtualbox
Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download
Hi, Are we going to add this feature to 7.0? There are some customers who tried Fuel from nightly or technical previews builds. However, they don't want to install fuel master node once again. There are several reasons for that. As a sample it's dev environment, though production environment should be done with GA code and packages. Though, the customers want to upgrade Fuel master node to GA. That will allow them to create new environments with GA code and package base. Also, they will be able to reset environment to install GA code. How are we going to support such clients? Thanks, On Wed, Sep 3, 2014 at 5:37 PM Dmitry Pyzhov dpyz...@mirantis.com wrote: Dmitry, I totally agree that we should support nightly builds in upgrades. I've created a blueprint for this: https://blueprints.launchpad.net/fuel/+spec/upgrade-nightly On Tue, Sep 2, 2014 at 3:24 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: We should not confuse beta and rc builds, normally betas predate RCs and serve a different purpose. In that sense, the nightlies we currently publish are closest to what beta builds should be. As discussed earlier in the thread, we already have full versioning and provenance information in each build, so there is not a lot of value in inventing a parallel versioning scheme just for the time period when our builds are feature complete but not yet stable enough to declare an RC. The only benefit is to explicitly indicate the beta status of these builds, and we can achieve that without messing with versions. For example, by generating a summary table of all community builds that have passed the tests (using same build numbers we already have). Not supporting upgrades from/to intermediate builds is a limitation that we should not discard as inevitable, overcoming it should be in our backlog. Image based provisioning should make it much easier to support. My 2c, -Dmitry I would not use beta word anywhere at all. These are nightly builds, pre-5.1. So it will become 5.1 eventually, but for the moment - it is just master branch. We've not even reached HCF. After we reach HCF, we will start calling builds as Release Candidates (RC1, RC2, etc.) - and QA team runs acceptance testing against them. This can be considered as another name instead of beta-1, etc. Anyone can go to fuel-master-IP:8000/api/version to get sha commits of git repos a particular build was created of. Yes, these are development builds, and there will be no upgrade path provided from development build to 5.1 release or any other release. We might want to think about it though, if we could do it in theory, but I confirm what Evgeny says - we do not support it now. On Wed, Aug 27, 2014 at 1:11 PM, Evgeniy L e...@mirantis.com wrote: Hi guys, I have to say something about beta releases. As far as I know our beta release has the same version 5.1 as our final release. I think this versions should be different, because in case of some problem it will be much easier to identify what version we are trying to debug. Also from the irc channel I've heard that somebody wanted to upgrade his system to stable version, right now it's impossible because upgrade system uses this version for names of containers/images/temporary directories and we have validation which prevents the user to run upgrade to the same version. In upgrade script we use python module [1] to compare versions for validation. Let me give an example how development versions can look like 5.1a1 # alpha 5.1b1 # beta 1 5.1b1 # beta 2 5.1b1 # beta 3 5.1# final release [1] http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html Thanks, On Tue, Aug 26, 2014 at 11:15 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Igor, thanks a lot for improving UX over it - this table allows me to see which ISO passed verification tests. On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: I would also like to add that you can use our library called devops along with system tests we use for QA and CI. These tests use libvirt and kvm so that you can easily fire up an environment with specific configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the documentation how to use this library is here: http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or gaps in documentation, please feel free to file bugs to https://launchpad.net/fuel. On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin ishish...@mirantis.com wrote: Hi all, along with building your own ISO following instructions [1], you can always download nightly build [2] and run it, by using virtualbox scripts [3], for example. For your conveniency, you can see a build status table on CI [4]. First tab now refers to pre-5.1 builds, and second - to master builds. BVT columns stands for Build Verification Test, which is essentially full HA deploy
Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download
Dmitry, I totally agree that we should support nightly builds in upgrades. I've created a blueprint for this: https://blueprints.launchpad.net/fuel/+spec/upgrade-nightly On Tue, Sep 2, 2014 at 3:24 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: We should not confuse beta and rc builds, normally betas predate RCs and serve a different purpose. In that sense, the nightlies we currently publish are closest to what beta builds should be. As discussed earlier in the thread, we already have full versioning and provenance information in each build, so there is not a lot of value in inventing a parallel versioning scheme just for the time period when our builds are feature complete but not yet stable enough to declare an RC. The only benefit is to explicitly indicate the beta status of these builds, and we can achieve that without messing with versions. For example, by generating a summary table of all community builds that have passed the tests (using same build numbers we already have). Not supporting upgrades from/to intermediate builds is a limitation that we should not discard as inevitable, overcoming it should be in our backlog. Image based provisioning should make it much easier to support. My 2c, -Dmitry I would not use beta word anywhere at all. These are nightly builds, pre-5.1. So it will become 5.1 eventually, but for the moment - it is just master branch. We've not even reached HCF. After we reach HCF, we will start calling builds as Release Candidates (RC1, RC2, etc.) - and QA team runs acceptance testing against them. This can be considered as another name instead of beta-1, etc. Anyone can go to fuel-master-IP:8000/api/version to get sha commits of git repos a particular build was created of. Yes, these are development builds, and there will be no upgrade path provided from development build to 5.1 release or any other release. We might want to think about it though, if we could do it in theory, but I confirm what Evgeny says - we do not support it now. On Wed, Aug 27, 2014 at 1:11 PM, Evgeniy L e...@mirantis.com wrote: Hi guys, I have to say something about beta releases. As far as I know our beta release has the same version 5.1 as our final release. I think this versions should be different, because in case of some problem it will be much easier to identify what version we are trying to debug. Also from the irc channel I've heard that somebody wanted to upgrade his system to stable version, right now it's impossible because upgrade system uses this version for names of containers/images/temporary directories and we have validation which prevents the user to run upgrade to the same version. In upgrade script we use python module [1] to compare versions for validation. Let me give an example how development versions can look like 5.1a1 # alpha 5.1b1 # beta 1 5.1b1 # beta 2 5.1b1 # beta 3 5.1# final release [1] http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html Thanks, On Tue, Aug 26, 2014 at 11:15 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Igor, thanks a lot for improving UX over it - this table allows me to see which ISO passed verification tests. On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: I would also like to add that you can use our library called devops along with system tests we use for QA and CI. These tests use libvirt and kvm so that you can easily fire up an environment with specific configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the documentation how to use this library is here: http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or gaps in documentation, please feel free to file bugs to https://launchpad.net/fuel. On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin ishish...@mirantis.com wrote: Hi all, along with building your own ISO following instructions [1], you can always download nightly build [2] and run it, by using virtualbox scripts [3], for example. For your conveniency, you can see a build status table on CI [4]. First tab now refers to pre-5.1 builds, and second - to master builds. BVT columns stands for Build Verification Test, which is essentially full HA deploy deployment test. Currently pre-5.1 and master builds are actually built from same master branch. As soon as we call for Hard Code Freeze, pre-5.1 builds will be reconfigured to use stable/5.1 branch. Thanks, [1] http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso [2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds [3] https://github.com/stackforge/fuel-main/tree/master/virtualbox [4] https://fuel-jenkins.mirantis.com/view/ISO/ -- Igor Shishkin DevOps ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download
We should not confuse beta and rc builds, normally betas predate RCs and serve a different purpose. In that sense, the nightlies we currently publish are closest to what beta builds should be. As discussed earlier in the thread, we already have full versioning and provenance information in each build, so there is not a lot of value in inventing a parallel versioning scheme just for the time period when our builds are feature complete but not yet stable enough to declare an RC. The only benefit is to explicitly indicate the beta status of these builds, and we can achieve that without messing with versions. For example, by generating a summary table of all community builds that have passed the tests (using same build numbers we already have). Not supporting upgrades from/to intermediate builds is a limitation that we should not discard as inevitable, overcoming it should be in our backlog. Image based provisioning should make it much easier to support. My 2c, -Dmitry I would not use beta word anywhere at all. These are nightly builds, pre-5.1. So it will become 5.1 eventually, but for the moment - it is just master branch. We've not even reached HCF. After we reach HCF, we will start calling builds as Release Candidates (RC1, RC2, etc.) - and QA team runs acceptance testing against them. This can be considered as another name instead of beta-1, etc. Anyone can go to fuel-master-IP:8000/api/version to get sha commits of git repos a particular build was created of. Yes, these are development builds, and there will be no upgrade path provided from development build to 5.1 release or any other release. We might want to think about it though, if we could do it in theory, but I confirm what Evgeny says - we do not support it now. On Wed, Aug 27, 2014 at 1:11 PM, Evgeniy L e...@mirantis.com wrote: Hi guys, I have to say something about beta releases. As far as I know our beta release has the same version 5.1 as our final release. I think this versions should be different, because in case of some problem it will be much easier to identify what version we are trying to debug. Also from the irc channel I've heard that somebody wanted to upgrade his system to stable version, right now it's impossible because upgrade system uses this version for names of containers/images/temporary directories and we have validation which prevents the user to run upgrade to the same version. In upgrade script we use python module [1] to compare versions for validation. Let me give an example how development versions can look like 5.1a1 # alpha 5.1b1 # beta 1 5.1b1 # beta 2 5.1b1 # beta 3 5.1# final release [1] http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html Thanks, On Tue, Aug 26, 2014 at 11:15 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Igor, thanks a lot for improving UX over it - this table allows me to see which ISO passed verification tests. On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: I would also like to add that you can use our library called devops along with system tests we use for QA and CI. These tests use libvirt and kvm so that you can easily fire up an environment with specific configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the documentation how to use this library is here: http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or gaps in documentation, please feel free to file bugs to https://launchpad.net/fuel. On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin ishish...@mirantis.com wrote: Hi all, along with building your own ISO following instructions [1], you can always download nightly build [2] and run it, by using virtualbox scripts [3], for example. For your conveniency, you can see a build status table on CI [4]. First tab now refers to pre-5.1 builds, and second - to master builds. BVT columns stands for Build Verification Test, which is essentially full HA deploy deployment test. Currently pre-5.1 and master builds are actually built from same master branch. As soon as we call for Hard Code Freeze, pre-5.1 builds will be reconfigured to use stable/5.1 branch. Thanks, [1] http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso [2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds [3] https://github.com/stackforge/fuel-main/tree/master/virtualbox [4] https://fuel-jenkins.mirantis.com/view/ISO/ -- Igor Shishkin DevOps ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com
Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download
Hi guys, I have to say something about beta releases. As far as I know our beta release has the same version 5.1 as our final release. I think this versions should be different, because in case of some problem it will be much easier to identify what version we are trying to debug. Also from the irc channel I've heard that somebody wanted to upgrade his system to stable version, right now it's impossible because upgrade system uses this version for names of containers/images/temporary directories and we have validation which prevents the user to run upgrade to the same version. In upgrade script we use python module [1] to compare versions for validation. Let me give an example how development versions can look like 5.1a1 # alpha 5.1b1 # beta 1 5.1b1 # beta 2 5.1b1 # beta 3 5.1# final release [1] http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html Thanks, On Tue, Aug 26, 2014 at 11:15 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Igor, thanks a lot for improving UX over it - this table allows me to see which ISO passed verification tests. On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: I would also like to add that you can use our library called devops along with system tests we use for QA and CI. These tests use libvirt and kvm so that you can easily fire up an environment with specific configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the documentation how to use this library is here: http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or gaps in documentation, please feel free to file bugs to https://launchpad.net/fuel. On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin ishish...@mirantis.com wrote: Hi all, along with building your own ISO following instructions [1], you can always download nightly build [2] and run it, by using virtualbox scripts [3], for example. For your conveniency, you can see a build status table on CI [4]. First tab now refers to pre-5.1 builds, and second - to master builds. BVT columns stands for Build Verification Test, which is essentially full HA deploy deployment test. Currently pre-5.1 and master builds are actually built from same master branch. As soon as we call for Hard Code Freeze, pre-5.1 builds will be reconfigured to use stable/5.1 branch. Thanks, [1] http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso [2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds [3] https://github.com/stackforge/fuel-main/tree/master/virtualbox [4] https://fuel-jenkins.mirantis.com/view/ISO/ -- Igor Shishkin DevOps ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download
I would not use beta word anywhere at all. These are nightly builds, pre-5.1. So it will become 5.1 eventually, but for the moment - it is just master branch. We've not even reached HCF. After we reach HCF, we will start calling builds as Release Candidates (RC1, RC2, etc.) - and QA team runs acceptance testing against them. This can be considered as another name instead of beta-1, etc. Anyone can go to fuel-master-IP:8000/api/version to get sha commits of git repos a particular build was created of. Yes, these are development builds, and there will be no upgrade path provided from development build to 5.1 release or any other release. We might want to think about it though, if we could do it in theory, but I confirm what Evgeny says - we do not support it now. On Wed, Aug 27, 2014 at 1:11 PM, Evgeniy L e...@mirantis.com wrote: Hi guys, I have to say something about beta releases. As far as I know our beta release has the same version 5.1 as our final release. I think this versions should be different, because in case of some problem it will be much easier to identify what version we are trying to debug. Also from the irc channel I've heard that somebody wanted to upgrade his system to stable version, right now it's impossible because upgrade system uses this version for names of containers/images/temporary directories and we have validation which prevents the user to run upgrade to the same version. In upgrade script we use python module [1] to compare versions for validation. Let me give an example how development versions can look like 5.1a1 # alpha 5.1b1 # beta 1 5.1b1 # beta 2 5.1b1 # beta 3 5.1# final release [1] http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html Thanks, On Tue, Aug 26, 2014 at 11:15 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Igor, thanks a lot for improving UX over it - this table allows me to see which ISO passed verification tests. On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: I would also like to add that you can use our library called devops along with system tests we use for QA and CI. These tests use libvirt and kvm so that you can easily fire up an environment with specific configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the documentation how to use this library is here: http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or gaps in documentation, please feel free to file bugs to https://launchpad.net/fuel. On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin ishish...@mirantis.com wrote: Hi all, along with building your own ISO following instructions [1], you can always download nightly build [2] and run it, by using virtualbox scripts [3], for example. For your conveniency, you can see a build status table on CI [4]. First tab now refers to pre-5.1 builds, and second - to master builds. BVT columns stands for Build Verification Test, which is essentially full HA deploy deployment test. Currently pre-5.1 and master builds are actually built from same master branch. As soon as we call for Hard Code Freeze, pre-5.1 builds will be reconfigured to use stable/5.1 branch. Thanks, [1] http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso [2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds [3] https://github.com/stackforge/fuel-main/tree/master/virtualbox [4] https://fuel-jenkins.mirantis.com/view/ISO/ -- Igor Shishkin DevOps ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download
Igor, thanks a lot for improving UX over it - this table allows me to see which ISO passed verification tests. On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: I would also like to add that you can use our library called devops along with system tests we use for QA and CI. These tests use libvirt and kvm so that you can easily fire up an environment with specific configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the documentation how to use this library is here: http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or gaps in documentation, please feel free to file bugs to https://launchpad.net/fuel. On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin ishish...@mirantis.com wrote: Hi all, along with building your own ISO following instructions [1], you can always download nightly build [2] and run it, by using virtualbox scripts [3], for example. For your conveniency, you can see a build status table on CI [4]. First tab now refers to pre-5.1 builds, and second - to master builds. BVT columns stands for Build Verification Test, which is essentially full HA deploy deployment test. Currently pre-5.1 and master builds are actually built from same master branch. As soon as we call for Hard Code Freeze, pre-5.1 builds will be reconfigured to use stable/5.1 branch. Thanks, [1] http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso [2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds [3] https://github.com/stackforge/fuel-main/tree/master/virtualbox [4] https://fuel-jenkins.mirantis.com/view/ISO/ -- Igor Shishkin DevOps ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download
I would also like to add that you can use our library called devops along with system tests we use for QA and CI. These tests use libvirt and kvm so that you can easily fire up an environment with specific configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the documentation how to use this library is here: http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or gaps in documentation, please feel free to file bugs to https://launchpad.net/fuel. On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin ishish...@mirantis.com wrote: Hi all, along with building your own ISO following instructions [1], you can always download nightly build [2] and run it, by using virtualbox scripts [3], for example. For your conveniency, you can see a build status table on CI [4]. First tab now refers to pre-5.1 builds, and second - to master builds. BVT columns stands for Build Verification Test, which is essentially full HA deploy deployment test. Currently pre-5.1 and master builds are actually built from same master branch. As soon as we call for Hard Code Freeze, pre-5.1 builds will be reconfigured to use stable/5.1 branch. Thanks, [1] http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso [2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds [3] https://github.com/stackforge/fuel-main/tree/master/virtualbox [4] https://fuel-jenkins.mirantis.com/view/ISO/ -- Igor Shishkin DevOps ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
